Code: Select all
EXTRA_BACKSLASH BACKSLASH
Code: Select all
EXTRA_BACKSLASH BACKSLASH
I was intending to put it through a USB->PS/2 converter first. My other USB keyboards are Scorpius and WASD...I have some extenuating circumstances which have slowed/prevented actual physical experimentation while still allowing me time to think and ask questions...but we discussed this in another thread:Soarer wrote:Not sure what you mean... QuickFire TK is a USB-only keyboard, so this converter can't convert it.
But now I see that Scorpius and WASD include an adapter, and WASD is very clear that USB is limited to 6KRO, and CM TK advertises >6KRO and says nothing about PS/2. I guess I had my suspicions for good reason. Thanks for saving me $200.Soarer wrote:My converter works just fine like that (as long as the keyboard supports PS/2).Hubbert wrote:Forgive me for being dense, but does this mean that the Soarer Converter will not work when connected to a typical USB keyboard connected through a simple USB to PS/2 adapter?
http://www.cyberguys.com/product-detail ... uctid=4202
This project's slow progress is mostly explained by its limited applicability. On the one hand most simple 6KRO USB keyboards also work fine over PS/2, so a PS/2 converter can be used instead. On the other, supporting fancier USB keyboards which have >6KRO (or even media keys etc) requires a lot of work. So this just fills a small niche, for now.
Thanks.I don't know exactly how they do their NKRO. So although with USB 2.0 full speed it could be a good implementation, it seems unlikely since they felt the need to state that only the 6KRO mode will work on Macs. It should work on Linux fine anyway; it's usually only the Mac which has issues.
Sadly, namenlos' posting seems to have disappeared from GeekHack when it got, well, hacked. That's actually kind of disappointing, since 30 ms is only 400 wpm assuming 5 characters per word, which is less than 2x the TypeRacer record...which is an Internet site so that adds tons of latency too. Good thing I'm not a 250 wpm typist, I guessI've written various things about delays, and the breakdown of the total delay into the four components (scan, debounce, buffer, transmit). It was namenlos who actually measured some... he found total delays of more like 30 to 50 ms. I can't recall where 13ms came in, although it was perhaps an ideal, hypothetical scenario with 1ms scan, 10ms debounce, 1ms buffer and 1ms transmit. In existing keyboards, the debounce appears to take much longer than required, although the latest 1000Hz keyboards might have improved.
You're welcome! There's nothing technical that prevents someone making a keyboard that supports both >6KRO USB and PS/2, but there's just not much commercial reason to. Even with standard 6KRO USB, the only reason PS/2 is still supported on many of them, is simply because they are still using pretty old chips!Hubbert wrote:Thanks for saving me $200.
Latency isn't directly related to bandwidth, since at least some of the time can overlap with other events. But even so, things must be getting pretty tight for those very fast typists... and I guess they're very fussy about their keyboards, too!Hubbert wrote:Sadly, namenlos' posting seems to have disappeared from GeekHack when it got, well, hacked. That's actually kind of disappointing, since 30 ms is only 400 wpm assuming 5 characters per word, which is less than 2x the TypeRacer record...which is an Internet site so that adds tons of latency too. Good thing I'm not a 250 wpm typist, I guess
Strangely, Sean Wrona admits to not being able to afford premium keyboards, and that his mother accidentally destroyed the Das that he won.Soarer wrote: Latency isn't directly related to bandwidth, since at least some of the time can overlap with other events. But even so, things must be getting pretty tight for those very fast typists... and I guess they're very fussy about their keyboards, too!
Yes, yes, and either a Teensy++ 2.0 or the cheaper Teensy 2.0. You'll almost certainly be fine with the Teensy 2.0; I don't think anyone has actually needed the extra memory on the ++ yet!Lost4468 wrote:Can I do this with an IBM Model M 1394308 made in 1989? Will all the buttons be reprogrammable? Do I just need a teensy++ 2.0 to do it? Thanks.
Thanks, too what degree are the keys reprogrammable? Could I for instance map one to "Ctrl+K, Ctrl+C" all on a single key?Soarer wrote:Yes, yes, and either a Teensy++ 2.0 or the cheaper Teensy 2.0. You'll almost certainly be fine with the Teensy 2.0; I don't think anyone has actually needed the extra memory on the ++ yet!Lost4468 wrote:Can I do this with an IBM Model M 1394308 made in 1989? Will all the buttons be reprogrammable? Do I just need a teensy++ 2.0 to do it? Thanks.
(There are a number of alternatives to the Teensy 2.0, but it's one the best for size, price, and the easy-to-use loader).
You sure could, with a macro. Here I've put it on F24, but it could be any key with any modifiers that's used to trigger the macro...Lost4468 wrote: Thanks, too what degree are the keys reprogrammable? Could I for instance map one to "Ctrl+K, Ctrl+C" all on a single key?
Code: Select all
macroblock
macro F24
PUSH_META ASSIGN_META LCTRL
PRESS k
PRESS c
POP_META
endmacro
endblock
Alright, thanks for the help. Think I'll have to go with a different board, doesn't seem to be any retailers which sell teensy here.Soarer wrote:You sure could, with a macro. Here I've put it on F24, but it could be any key with any modifiers that's used to trigger the macro...Lost4468 wrote: Thanks, too what degree are the keys reprogrammable? Could I for instance map one to "Ctrl+K, Ctrl+C" all on a single key?
Code: Select all
macroblock macro F24 PUSH_META ASSIGN_META LCTRL PRESS k PRESS c POP_META endmacro endblock
Nobody sells them here either, so I get mine direct from PJRC - even with the postage it's still as cheap as anything I've seen here. Where is your 'here'? Oh, and welcome to the forumLost4468 wrote:Alright, thanks for the help. Think I'll have to go with a different board, doesn't seem to be any retailers which sell teensy here.
The UK, PJRC wanted $72 for UPS postage or cheaper air mail at 1-3 weeks for only $10.Soarer wrote:Nobody sells them here either, so I get mine direct from PJRC - even with the postage it's still as cheap as anything I've seen here. Where is your 'here'? Oh, and welcome to the forumLost4468 wrote:Alright, thanks for the help. Think I'll have to go with a different board, doesn't seem to be any retailers which sell teensy here.
Testing it, as it seems the Numlockstate is irrelevant. But many characters are not available this way, as the "alt"+"+"+<hexcode> do not work if the menu of the running program uses "alt"+character form menu access. So only numbers work, Hexcode containing a-f often result in a menu is popping out.Soarer wrote: To send Alt+numpad codes reliably, I think maybe a test is needed for num-lock state.
I hoped so. I will make a test (but in two weeks as I have not much time now) with a simple Arduino setup, how to electrical connect a piezo-busser and place it in a keyboard to se if a simple on/off of a signal makes a noticable sound.Soarer wrote:The bleeper-out, on the other hand, well that would be easy
Full acknowledge. But to be realistic, I mostly have to write normal text in office, so a complete NEO2-Layout is not necassary. For example, diacryptic chars exept accut (which is in my middle name "André") are not used (ÄÖÜäöüß are directly supported).Soarer wrote:Oh crap, that's frustrating
I think a on/off should do, so simply set pin and clear pin can follow right after another, a piezo will make a nice short click-clack. But maybe changeing every time as you sugest is a better solution, as a simple click (without clack) may fit the sound of a mx blue (als click and clack sound the same, tongle is a good idea)Soarer wrote:The buzzer out could be a pin that just changes state each time, then passing that through a capacitor to a speaker to get clicks. Or a pulse of some width, although I might be using all the timers already which means it might be limited to being some whole number of ms (my main timebase is 1kHz).
Code: Select all
scwr v1.10
scwr: looking for Soarer's Converter: found
scwr: reading file: 1030 bytes: ok
scwr: sending info request: ok
device: ok
protocol version check: converter=1.00, scwr=1.00: ok
settings version check: converter=1.01, file=1.01: ok
settings length check: max=1018, file=1028 bytes: failed
Yes, that's the limitation at that stage. I think 4k should be enough - there are some ways to reduce the size of your macros already, but also I'm wondering about putting in macro commands for the Alt+... sequences (OEM, Windows, Unicode) which would save a lot. (Not the 'nnnn Alt-C' ones though, they're too specific).bester42 wrote:Its correct, that the limitation is from EEPROM which is 1k on Teensy 2.0 but 4k on Teensy ++ 2.0?
Of course, even a Teensy 2.0++ maybe has not enough EEPROM for complete NEO2.
As the program needs not all flash of the teensy an even in the ++2.0 the EEPROM is small, it would be nice to put the tables in the normal flash...
Code: Select all
PUSH_META CLEAR_META all
MAKE LALT
Code: Select all
PUSH_META ASSIGN_META LALT
Code: Select all
BREAK LALT
POP_ALL_META
Code: Select all
MAKE LSHIFT
MAKE LALT
Code: Select all
SET_META LSHIFT LALT
Agreed. Macro triggers conditional on lock states would be a nice feature. (Maybe even in remapping... a lock could have the same effect as a Fn layer... just a thought I'll investigate further).bester42 wrote:... numlock ...
It might work using a Fn layer... it would need to remap to otherwise unused keys: EXECUTE to LOCKING_SCROLL_LOCK, ALTERNATE_ERASE to EXSEL, any of the non-standard codes such as EXTRA_F1 that have been already remapped elsewhere, etc. I think there's enough to cover the whole main block. Then the macros would trigger on those codes.bester42 wrote:The third problem...: As the same modifier function in NEO is on two keys (one right, one left) and lock is done by pressing both, I am not totaly sure how to progam this. Because of the low numer of modifiers I had to created the layers by this design:
I agree that these can be related somehow. I'm thinking of some scheme where perhaps Fn keys can be used for different purposes, but I haven't fully worked it out yet. If the macro trigger could test for them, they could be used for modifiers. If there was a way to tag them as 'sticky', they could be used for dead keys. Those two concepts seem to fit together fairly well, to allow the most configurations. It may then be worth increasing the number of Fn keys... but it won't be to 32!bester42 wrote:I think it would be nice to have virtual modifiers not reporting to the PC. Mody01 to Mody32
It would be also a solution for DEAD_KEYS. The Deadkey is calling a macro, locking the modifier, the following keystroke is handled by a macro creating the composed sign and resetting the modifier.
Cool! So somewhat successful then, even if it could be better I'm pretty sure that's the biggest config anyone has written so far!bester42 wrote:EDIT: I removed my functionkey-macros I tried first, so 3. layer fits. The functionkeys are based on Halvar's config for Terminal Model M (No 1394312, 122 keys, German, cable with RJ45 connector) but changing f1-12 and f 13-24 row.
The keymapping and layer 1-3 are working exept some dead_keys and locking a layer.
As Sum and pi are in advanced Layers I cannot support without Teensy++2.0, I put them on AltGr +s /+p.
This config should be enough for normal office work, so it make it possible to use NEO there if you can change keyboard/adapter (maybe simply telling your finger hurt after work, so you had to take a mechanical and optimised keyboard for medical reasons - which is basicly true)
Code: Select all
# $
macro 6 LSHIFT
PUSH_META CLEAR_META all
MAKE LSHIFT
PRESS 4
BREAK LSHIFT
endmacro
Code: Select all
# $
macro 6 LSHIFT
PRESS 4
endmacro