Some suggestions for future improvements

[OleUrgast]

Hello,

thanks for your great work.

I just got some mechanical keyboard PCBs (designed by Adam Eberbach (aerberbach here on github) for the A600 from pcbway, as I want do make an Amiga emulator (Rasperry Pi, mechanical keyboard, DrawBridge with floppy, Slot-In CD-Drive).

Also I thought about how to make a keyboard controller and ordered some parts (Arduino Nano and CD74HC154EN). Than I found your project.

While I like your project a lot, I have a few questions:

• You use the two „blank“ keys for extra functions. As I am German, the two keycaps are not blank. How hard is it to change the function back to original keycode?

• I actually like extra keys. In the keyboard matrix the crosspoints 1/16, 1/22 and 1/24 are not used (the row with the function keys). I consider to glue the 3 LEDs onto little switches and let the LEDs become extra buttons, and wire them to 1/16, 1/22 and 1/24. So the look of the A600 does not change even with this „extra“ keys. How hard would it be to implement theese extra keys on 1/16, 1/22 and 1/24 into firmware?

Some suggestions:

You use nearly all of the I/Os of the Pi Pico + one extender IC. It seems a bit wastefull to me to use so much I/Os of the Pico, as only one colum of the Matrix is used at a time. As I thought about an own solution, I thought about a 4:16 decoder (CD74HC154EN). This Chip is quite simple: you connect it to 4 IO-Ports of the microcontroller, connect both enable inputs permanently to low. The 4 inputs are the „adress“ wich output is to be set to low. So if you set the 4 IOs to 0000, output 0 goes low, 0001, output 1 goes low,..., 1111 output 15 goes low. Always the other outputs are high.
So you can adress all 15 colums of the main keyboard matrix.
Also the reason for a seperate matrix for modifier only is anti-ghosting. Using a second 4:16 decoder (or a 3:8 one) on the same IOs would not result in ghosting, as the outputs still are seperated. So you can connect both 4:16 decoders to the same 4 I/Os. Alternativly using diodes on output 0 to 6 to the main matrix and to the modifier matrix (so 14 diodes altogether) should also work instead of a second decoder IC.
So for all the 22 colums you only need 4 I/Os of the Pico.

Only for the 6 rows (5 main matrix, 1 modifier matrix) you need one I/O per row to read wich key is pressed
So with 10 I/Os on the microcontroller you can actually read the complete keyboard matrix (+1 I/O to light up caps-lock).
This gives you a lot of free I/Os on the Pi Pico and would allow aditional features.

Suggestions for additional features:

a) Joystick port. Actually Kerath v2 maps joysticks to the keymap. There are two methods most emulators support. Individual Computers (icomp.com) describes them on their website http://wiki.icomp.de/wiki/Keyrah_V2#Joystick_mapping. Method 2 seems best for emulation, as it emulates keypresses on numkeys. As there is no numpad on A600 there would be no conflict...

b) A1200 keyboard support (extra 31 or 32 pin FCC connector (like used on aeberbachs A1200 mechanical keyboard))

c) Jumpers.

• Change configuration between maping extra functions to blank keys or send original keycode (international users) (mapping to 1/16, 1/22 and 1/24 can be always active in parallel, it does not hurt)
• Change between A600 and A1200 keyboard

d) extra output: Clock + Data for Amiga 1000/500/2000/3000/4000/CDTV/CD32 - so you can use your A600 Keyboard as an external keyboard for theese. Esp. if you add support for A1200 keyboards, this would allow mechanical keyboards using aeberbachs mechanical keyboards with your controller inside the original (keyboard-)case (exept on the A1000 of course). Of course level shifter is to be added due to Amiga using 5V

e) extra 4-pin connector for lines 1,16,22,24 to connect an external 3-key „keyboard“ (LEDs mounted on switches or extra keys hidden on the back of the Amiga case)

Just some ideas for further improvements in the future.

As I neither have skils in KiCad nor Python programing, I do not now if theese suggestions are possible to do or how hard it would be to implement them.

[OleUrgast]

Actually even without Python knowlage your well written code seems to be easy to adapt to my needs.

For getting the international keycodes I found only "KEYPAD_BACKSLASH" wich should be one of the two blank keys on us-keyboards so far (it is marked "(non-us)" on https://circuitpython.readthedocs.io/projects/hid/en/latest/api.html ). I still not know the keycode for the other key, but as a full size keyboard US is 104 keys and ISO 105 keys the other key should exist in US layout also, so I will find it by trial and error. So I am pretty sure I only have to change KC.LAYERSHIFT_1 and KC.LAYERSHIFT_2 in KEYMAP_M1[0] to "KEYPAD_BACKSLASH" and the other code I still have to find out.

Also extra keys for function layer for international users are not needed, as there is a key most users do not like and deactivate anyway: Caps Lock. >95% the time Caps Lock is active, it was by accident. It is a relict from typewriters were the only way to emphesice something was to use capitals or underline a text. I know no one actual using capslock, even retro fans. There are people who deactivate it anyways, if they can. So all to get a function key for international users would be changing KC.CAPS_LOCK to KC.LAYERSHIFT_1 in KEYMAP_M1[0] if I understand correctly.

Even joystick emulation should be no problem, as there is still one free pin on the Pico (GPIO 28). So add it as an extra row after line 148 "digitalio.DigitalInOut(board.GP28)", connect it to the gnd pin of 9 pin d-sub sockets and wire pins 15,17,19,21,23 and 25 to up, down, left, right, fire1, fire2 of first joystick connector and pin 16,18,20,22,24 and 26 to up, down, left, right, fire1, fire2 of second joystick connector. Than add a line to KEYMAP_M1[...], so the coresponding numpad keycodes for emulators are send if joystick is used.

Practicly the 5/6 switches in a joystick are treated as extra keys (numpad keys) in a seperate row.

Of course this way only passive joysticks are supported, as we do not have real "ground" and neverever 5V for autofire joysticks (at least without using extra hardware). But autofire is cheating anyway and using some good old competition pro would definitly be a benefit.

All this should work without modifying the PCB, as the colums are easy to access at the back side of the PCB at the ribbon connector. Using every second pin means it is easy to solder standard pitch 2.54 pins (1 by 7, one not soldered to the connector but bend up and batchwired to GPIO28) to the back of the flat cable connector.

As soon as my PCBs arrive and get the controller board ready, I will definitly try this hack and report. If it works out as I think, you might add it into regular firmware, as adding a row to the matrix would'nt effect normal use at all. But maybe in future revisions of your board you might add two headers 1 by 7 (or even better: two 2 by 5 with one pin removed, to directly plug a db9 cable as used in older computers for serial conectors on a slot bracket. Would be nice to reuse theese old parts for joystick ports...)

[thinghacker]

Hi, sorry for the delayed response but it is great that you are able to look at this and extend things to your liking, please let us know how it goes.

Regarding the keymapping - certainly the idea was that it should be possible adapt things to your own desires, for non-UK/US keyboards it should be possible modify things are necessary - in part I suspect it depends on how things are intended, if I understand https://usb.org/sites/default/files/hut1_21_0.pdf#page=83 correctly some of the changes should be transparent to a degree as the local USB host would determine the right re-mapping operation.

However if the adafruit library doesnt have all of the desired keycodess it still should be possible to extend things using the same kind of concept I used to include the calculator button in the consumer control code list

in "class keyboard" before "for (k,v) in self.__keycodes.items():"

 self.__additionalkeycodes = { "F24": 0x73 }
 self.__keycodes.update(self.__additionalkeycodes)

Then in your keymap you should be able to use KC.F24 (though I haven't gone so far to verify this)

Regarding the enhancements to enable joystick support at the same time - this sounds great and certainly adding a pair of 2x5 headers to attach serial DB9 connectors to me sounds like a good approach as well as it should add minimal additional board space and give flexibility to install/remove and route around to the A600 if need to do maintenance

Depending on how far you wish to go - autofire might even be something a special keyboard combination enables/disables and the keyboard/joystick controller does the work.

[OleUrgast]

Thanks for your answer.

I think it will take some weeks to start the project, because the PCBs have not left China before Chineese new year ;-(.

Thanks for the hint how to do aditional keycodes, this should be quite helpful.

Actually I got a bit more into the keyboard schematics of the A600. It seems pin 30 (row 0 matrix 2) in original A600 is permanently grounded. Actually in a 1 by 7 matrix that makes kind of sense, as there is no other row to select anyway.
I can not confirm it for an original keyboard as I have none, but on Adam Eberbach's mechanical keyboard the keyboard itself do not make the connection to ground. So it is to be done by the controller. As you conected pin 30 to GPIO2 instead of simply putting it to ground like the A500 does, it should be possible to merge the matrixes. Just one matrix with an aditional row for function keys in software but 14 diods (two for column 0 to 6) electricly preventing ghosting. So no extender needed. As you need 2 GPIOs on the Pico for i2c, it only adds 6 IOs anyway. So if you spare 7 GPIOs by connecting the colums 0-6 of matrix 2 to the same GPIOs as column 0-6 of matrix 1 and using diods to prevent ghosting, you even get one more free GPIO.

As I got 10 of Adam's PCBs (it was just 30€ more than getting the minimum number of 5) and I will get 10 of your PCBs (same 5$ as I would have paid for 5), I have much material to experiment with. I build one mechanical keyboard last weekend. But I used two rows of 2.54 mm pinheaders instead of FCC-Conectors - this way I can use simple Dupond-cables instead of the special cables. And I also can use breadboards for testing, to try out diode solution (maybe I do that first, if China need to much time to deliver)...

If everything works out as intended, next step would be repairing my Anycubic Chiron to print a case for the keyboard and my Pi 400. My goal is to build an Pimiga 400 with mechanical A600 keyboard. Maybe by modifing an existing model of the A600 case from thingiverse and including a disk drive with drawbridge and a slot-in DVD-drive. But one step after another...

I will report on progress (or fails).

As for autofire: What I mean is we can not connect an old joystick with active circuits like autofire to the board, as gnd line is used as row and only active once a cycle for a short time - and anyway suporting the 5V for the electronic of the joystick would result in destroying the pico. So a joystick with autofire would not work at the port, as the electronic can not be powered. Only a pure passive joystick (pure switches) would work. Turned of electronics between the physical fire button and the matrix would block or disturb the signal and even can block a column completly. So if you have a favorite old joystick with autofire electronic, you can not use it (unless the autofire off switch bypass the electronic or you modify the joystick yourself to do so)
To use autofire with a passive joystick no special programming is needed. Most emulators have already autofire option implemented.

[thinghacker]

Yes I agree that there are options available to optimise the design further and possibly remove the requirement of the port-expander altogether.

I have obtained one of Adam Eberbach's A600 mechanical PCBs myself and have been meaning to assemble it but haven't quite gotten to it yet, I suspect that you will be suitably happy with it, one of the main hurdles if I recall is obtaining a full size space bar as the A600 is a little bespoke in that area (so far I have keys but not the keycaps)

Certainly I would like to be kept updated as to how things progress, if you haven't already, perhaps you may wish to fork this project and document the enhancements you develop.

I'm not sure if this directly helps you but another option is to use the GPIO ports on the Pi itself for controller Input - this is described here https://retropie.org.uk/docs/GPIO-Modules/#db9_gpio_rpi. From this info I made a small PCB that connected directly to the back of the Pi400 and was what I had used with Sega Genesis/Megadrive Controllers - I described it here https://github.com/thinghacker/RaspberryPi400-GPIO-DB9 and used it with an older PiMiga version.

[OleUrgast]

Actually using diodes would be most usefull if I decide to glue a Pico directly on the back side of the keyboard, without extra PCB. The diodes (with some shrink tube as insolation) would also work as wires, so a quite compact way to make an USB keyboard. This would be for an A600 like external keyboard (to use with any PC, not only for emulation) to keep it as flat as possible. For an A600 Pimiga there is enough space for a PCB, so an extender and PCB is not an issue.

For an universal solution your way using an i2c extender is definitly the better way. It should be quite easy to adapt to A1200 matrix (I have to draw the wireing myself, as there is no nice documentation as for the A600kb). It might need one GPIO more (but the ffd LED do not realy need a GPIO in my opinion - wireing leds to floppy would be nice enough). Also C64 and C128 keyboards should'nt be a problem. Using GPIOs for all lines (and not diodes) makes it quite simple to wire other keyboards to the connector (I just will solder two rows of 2.54 mm pitch pins on your PCB to try it) and mostly define the ports to optimice wireing. The matrix of the C64 Keyboard is well documented (even in german, so for me it is most easy to read https://www.c64-wiki.de/wiki/Tastatur#Schaltung ).

I have not ordered Adams A1200kb yet, as I found an error in the design on both A600kb and A1200kb: Exept for the one and only original Amiga Cherry Keyboard (from A2000(A) Rev. 4.x "Braunschweig Edition", actually it was my first Amiga) the window in the Caps Lock keycap is located top right. So with the key itself mounted normaly and LED placed in the down middle, light never will reach the window. The Caps Lock key has to be mounted 180° rotated if you want original keycap design. I opened an issue and wait for resonse. Anyway, no big deal if I use Caps Lock for shifting layer instead, as the LED will never be turned on anyway.

As it comes to keycaps: There are different keycap generators for OEM-profile at thingiverse. I recently got a resin 3d printer (anycubic mono x 4 k). But at the moment the ambient temperature to print with open windows is not optimal for 3d printing. But in summer I will definitly try to print resin keycaps myself. 9u spacebar should be no problem at all this way.

Labeling them can be done with DyeSub (some nice videos on youtube if you search for DyeSub and Keycaps).

Of course, standard resin might not like the heat involved with DyeSubbing. But there are high temp resins available at a resonable price. Also there are not-so-cheap-but-fantastic resins with look and feel of ceramic. But thats something I might try later.

An alternative way to make keycaps for mechanical boards is simply to use original keycaps, cut the inside of the cap away and glue a cherry repair stem inside. I have some defect A2000 keyboards, so I might do one or two A1200 keyboards this way. But the pad-printed labels do not like multiple retrobrighting.

I might do it also for a C64 mechboard, as old C64 keyboards are quite cheap and the old keycaps are doubleshot (anyway only the function keys tend to yellow). While there are 3d printable "adapters" to put C64 caps to cherry keys, replacing the inside of the cap would not add extra hight.

Of course there are other methods to produce keycaps - like building two of the $200 do-it-yourself injection molding maschines and construct molds for doubleshot keycaps (as you can make molds yourself with high temp resins like the ceramic one I found - actually making molds is exactly what is promoted for). But thats more a project for retirement than a normal hobby... So maybe in 15 years...

Thanks for the link to Rasperry Pi's GPIO-joystick adapter. While it is a nice project, I still hope someone will develop an exact Amiga parallelport adaptor for the Pi, so I want to keep the Pi GPIO´s free. I have some historic Fischertechnik Computing construction toys (like a plotter). While I can use them on modern PCs with arduinos as adaptors, I still hope to find a solution to use Amiga emulators to use them with the historical software from 1985…

[OleUrgast]

I made some progress - Not for the controller, as I still wait for the PCBs, but for the mechanical keyboard and the keycaps.

As I have a lot of plate-mounted switches flying around I got into problems to align them on the PCB. Without the two extra plasitic pins the 5-pin keys have, it is hard to solder them straight.
So I designed a mounting plate for the A600kb PCB. It also has holes to mount standard chery-style stabilzers; as the keycap generator I use always place the mounting points same as on an 6.25u spacebars even if you make an 8.25u spacebar, this is quite usefull.

I added two photos, one from my first try with plate printed in two parts in my mk3s, the other improved one (more stiffness) printed on an Anycubic Predator in one piece.

Also I printed a (nearly) complete set of OEM Style keycaps. Only ISO-Enter in OEM Profile I am still looking for. As I am still learning how to print with resin, not all keycaps are perfect yet. But the last keycaps worked out quite well.
For the test I used green transparent resin, just because I got two liter with the printer. Sadly the A600kb from Adam has no backlightning, else I would bei tempted to use it for a Final Version (but using red transparent resin for the gray keycaps...). But maybe later I might do a version with handwired LEDs ...
I already have white and gray resin, but before using this, I will do some improvement on the spacebar, functionkeys and hopefully find an ISO-OEM enter. Also I will test dyesubbing in Resin first.

I will publish the mounting plate as soon as I fixed some minor issues in thingiverse. As I do not have an original Amiga 600 I so not know what changes might be needed to mount the keyboard with the plate inside.

[OleUrgast]

Some progress:

• yesterday the PCBs for the controller arrived, so I will start my experiments this weekend
• Also reprinted some keycaps with 0.01mm layerhight. Great look, I also improved washing (prewasch in 1st tank, 10 min in wash&cure in a 2nd tank, and 20min in a 3d tank)
• I tryed finesanding (1000+2500+5000 paper) and polishing keycaps. Only the top, not the sides. It looks fantastic, but at the moment I need at least 5 minutes per normal key (about 25 min. if doing it on the sides also. Definitly nothing you want do for every keycap...). So a lot of work to do.
• tryed DyeSub for printing on keycaps. While I just improvised on tools (I used a simple iRon(TM)) and also I could only try with some old testprints (the waste ink container of the printer is full) on normal paper (not transfer paper) I saved from the bin, I can definitly tell: it works. The resin withstands the 200°C for the time needed. Just make sure to be careful with preasure (I cracked one key). On the green resin (it is more green and darker than on the picture) the contrast is less than optimal, esp. when keycap is polished. But as it definitly works, I will build a special tool to transfer on keycaps. On white and light gray resin keycaps it should definitly be a perfect solution to make cherry compatible Amiga 600 keycaps.
• I also made a Mechboard64 now. So I will try to adapt your controler for the 64keyboard also.
• Also I ordered the A1200kb (beside CapsLock LED being on the bottom instead of the top).
• As CapsLock will be used as FN, I think I will simply change Ctrl to become CapsLock in second layer. So CapsLock-Key + CTRL-Key pressed together will activate/deactivate CapsLock.

[thinghacker]

Wow @OleUrgast , you have been making really good progress here, Thanks again for keeping us updated with what you have been doing.

I am interested in your key printing technique, and from what I can see with your keycaps - it seems quite impressive and makes me want get a resin printer myself.

Nice work!

[OleUrgast]

I use https://www.thingiverse.com/thing:2783650 to create the keycaps. You can even "engrave" the labels directly in the design, but at the moment I do not use this, as dyesub printing will result in more contrast on original coloured keycaps (white and light gray). Also much more usefull for others, as legends differ from country to country. But maybe in the future I might try to make a complete black keyboard (black keys with black labels in a black case. Just need black LEDs and its perfect for Disaster Area's Show Spaceship...).

So most of the keycaps are not a problem at all. Just install OpenSCAD (Developer Snapshot!), choose Profile (I use OEM), row (both bottom rows are "1", both top rows are "4", do not get confused by the options 0 and 5, these are only for special designs), width of the key and render and export to stl.

Space bar is also quite simple, just enter the correct width and set "$invert dish". I also had to set $stabilizer_type = "cherry_stabilizer" in line 185 of the code, as this option is hidden in customizer and normaly set to costar_stabilizer. But if you have costar stabilizers, no change needed there. I just had cherry stabilizers I wanted to use.

There are so many options you can set (hidden features even allow to emboss front legends) some are hard to find. Just 1h ago I found the way how to make the ISO-Enter (still I have not found the way to create the stabilizer stems for it, but if nothing else work I might simply add them after generating the stl).

Making the keycaps was my first step into resin printing. The Anycubic Mono X 4k works quite well. But any small resin printer should do - even the old Photon. Just takes more time for printing (but I recommend a mono screen). Of course with a small printer you might have to rotate the space bar to fit it inside the build volume. Anyway, development is fast in resin printing and price falls quite fast - Just some days after I bought the 4k the 6k was released.

It might take a few weeks to make the final tweeks on space bar and ISO-Enter, but when it is finished I will put the stl's on thingiverse.

[thinghacker]

@OleUrgast, you have started to inspire me to revisit this project, I suspect the introduction of a 31pin connector to support Amiga 1200 keyboards as well as A600 would be pretty straight forward from a hardware standpoint (and the difference would mainly be the associated keymatrix), however I have been thinking a bit about legacy DB9 joystick/mouse connectivity you mentioned awhile back and have put something together as a starting point to understand creating gamepads using the Pi Pico - https://github.com/thinghacker/PiPicoUSBSegaController.