well if you want a light... then scroll-lock is the only option
other unused game in DOS is the PrintScreen one, I can't recall a game using it (just like scroll lock but I also do not know of a KVM using it)

keropi wrote on 2020-06-13, 20:30:

well if you want a light... then scroll-lock is the only option
other unused game in DOS is the PrintScreen one, I can't recall a game using it (just like scroll lock but I also do not know of a KVM using it)

Thanks! I'll consider it as some kind of alternative enablable mode. Though looking at the code - I've pretty much hard-coded Scroll Lock into it (device does not spoof for pressed keys when the light is not lit - only for Scroll Lock byte).

Also Scroll Lock is one-byte code and Print Screen is four-byte code, which may be easily mistaken for "Keypad *"or Left Shift. So I can't "just" spoof for the byte - I have to invent a routine for it.

I'll look into it, but if an extra routine breaks the code or ruins timing, I'll have to drop this feature.

my advice would be to stick to scroll lock, but add a physical learn button on the device itself for edge cases

maxtherabbit wrote on 2020-06-14, 15:03:

my advice would be to stick to scroll lock, but add a physical learn button on the device itself for edge cases

I tried! really, I did! There is just no space for the button! Have to resort to software solution.

Look at the pic, the button just does not fit:

does the pcb need to have those inwards round edges? without them there is much space to spare

keropi wrote on 2020-06-15, 21:21:

does the pcb need to have those inwards round edges? without them there is much space to spare

Cutouts absolutely must for this case.
All alternatives are either too expensive or nasty. This case is fun to fondle - just the right size for the arm.

Just in case this isn't clear and/or could lead to problems: The key next left of the "1" key on a German layout keyboard is labeled with ^ and °. Pressing the key in combination with shift will print ° immediately. Just pressing the key alone will do nothing visible. Only when you press the spacebar afterwards it will print the ^ without a space behind it. In contrast to that pressing the key and any other number, letter or symbol afterwards will print that right after the ^. So it'll print ^a for example.

Actually, it should print â. And it is called a dead-key, as it does not generate any character by itself, but only when another key is pressed. It is present on lots of European keyboards to generate accented characters.

villeneuve wrote on 2020-06-25, 00:58:

Just in case this isn't clear and/or could lead to problems: The key next left of the "1" key on a German layout keyboard is labeled with ^ and °. Pressing the key in combination with shift will print ° immediately. Just pressing the key alone will do nothing visible. Only when you press the spacebar afterwards it will print the ^ without a space behind it. In contrast to that pressing the key and any other number, letter or symbol afterwards will print that right after the ^. So it'll print ^a for example.

_Rob wrote on 2020-06-25, 06:19:

Actually, it should print â. And it is called a dead-key, as it does not generate any character by itself, but only when another key is pressed. It is present on lots of European keyboards to generate accented characters.

Please let me dispel some confusion. I don't work with keys per se, I read keycodes.
Both USB and PS/2 key codes specify a key position, not a glyph. The button to the left of "1" has scan-code of 0x0E, regardless of it's meaning for the OS (it may be "^", "â" or "Ё" for many of us Cyrillic - it does not matter!). Same as the first letter of lower letter row is usually "Z", but it's "Y" for the Germans. It is the OS that does glyph switcheroo, not the keyboard or my device! So no unexpected key-presses should be experienced.

Even Japanese keyboards should work! (Though I had to drop Korean glyph switching keys, as those are weird).

keropi wrote on 2020-06-13, 06:52:

Nice!
How about using other key than scroll-lock? KVMs do use it to change inputs, better avoid it all together

If your KVM is controlled by DOUBLE TAP of Scroll Lock - there should be no problem. All keyboard output is forwarded to the host, so both Scroll Lock taps shall be read by the KVM.
The first tap should put the device into config-state (hindering GAMEPAD functionality, not KEYBOARD communication), then second one - immediately revert it to normal.

Single taps or Scroll Lock LED tinkering by KVM may become an issue. But than again - for gamepads, not keyboard.

_Rob wrote on 2020-06-25, 06:19:

Actually, it should print â. And it is called a dead-key, as it does not generate any character by itself, but only when another key is pressed. It is present on lots of European keyboards to generate accented characters.

🤣, yes, I picked a very bad example in choosing the letter a in which case it indeed results in â like it does with all vocals.

The irony of this whole project is that the Multibay Docking Station for the Compaq LTE 5000 series has a fully functional DB-15 Joystick/MIDI port.

SITUATION REPORT
Ok. I’ve got the locally made 2 prototype boards. They are rough, but should do for the time:

I’ve made some sizing mistakes, so the board does not fall flat between those round pegs (that’s the punishment for being lazy and using the case specs PDF and not real measurements). But it’s nothing a Dremel won’t fix (also made the edges smoother).

Got the PCB assembled. Also tested the outsourced soldering service. SMD job is top-notch, through-hole is OK (should do, I guess):

There’s A HUGE problem: 4p4c connector 1.5 mm too high - the case will not close flush! I know of similar component, which is lower, but is has different footprint and is not interchangeable.

Also SNES connector seems to be a bit high. Should fit... maybe. If it doesn’t – there are ribs on top and bottom of the connector, which may be cut with a model knife offering a couple of millimeters of wiggle-room.

SO IN CONCLUSION:

1. This prototype is enough to allow the finalization of software (hopefully the pinout won’t change in the final product).
2. I’ll have to make another prototype (made in China?) with proper measurements and different 4p4c connector to make sure everything fits. Since everything is REALLY SLOW with all that lockdown, extra prototype stage shall add like 3 weeks to the project (and normally prototyping should take only 1 week).

UPDATE.
Connecting a slave PS/2 keyboard made a fuse blow. DAMN!
Now I am confused.

Trying to bypass the fuse now shows huge current draw. I think first prototype is blown. Double damn!

Thankfully I have a second one.

New design looking good, hope you can find the fault soon Volo!

keropi wrote on 2020-07-04, 05:43:

New design looking good, hope you can find the fault soon Volo!

Fault found - somebody is an idiot. If I see that somebody - I'll punch him!
PS/2 port is wired backwards.
Note to self: never incorporate parts from SnapEDA into you projects.

P.S. I wonder why all mirrors in my house are broken...

hehe an honest mistake - easily fixed!

Glad for the updates. Go easy on the idiots 😁

Pierre32 wrote on 2020-07-05, 12:59:

Glad for the updates. Go easy on the idiots 😁

I can't - I have to look at one when shaving.

any update? 😁

MK2k wrote on 2020-07-31, 10:51:

any update? 😁

I just recived a new prototype, but I'm still trying to make it work.