 I have this amazing keyboard, this is actually the keyboard from my IBM 6780 quiet writer typewriter that is currently sitting on the desk over there because it is far too big to appear on camera. This keyboard is epic, it's incredibly heavy, it feels beautiful, it's incredibly loud, it's a very early IBM buckling spring model of about the same vintage as the original model M's. This is apparently a bit of a crossover between the model F and the model M and is moderately rare. The key feel is gorgeous and I very much want to use this as a daily driver for my desktop PC. Not least of which is that as you can see it's got this really cool screen. Now because I do not want to actually damage or modify this in any way in order to do this I am going to have to reverse engineer the keyboard protocol and build an interface. I have a suspicion that this is actually PS2 which is nice because my desktop computer actually still has a PS2 interface but I won't know this for sure until I hook up a logic analyzer and actually try it and see. Now because the plug at the end of the cable is extremely bizarre and I don't want to cut the cable the first thing we're going to have to do is take the lid off and unplug the cable so that I can plug my logic analyzer in instead. So that is the first thing to do. Okay what do we have here? Well I am cheating certainly I have taken this apart before so I know that this plugs on with a seven pin Dupont connector. So now I think I have something that will fit that. I'm very glad I have this crimper but this does still take a while so we should have now a pin header that will push on here. There we go. And that should break out the pins in the right order with pin one being the blue one and the other end of this wire. So now we reassemble it carefully like so. So now we need to plug this into a piece of breadboard which is going to mean more crimping. Yay well that was annoying but hopefully it's done. We now have a seven pin connector here connected to the keyboard that we should just be able to plug in here. Okay and we are going to put our the real connector here and let's try to remember how it plugs in. This goes on this way around with, hang on there's me six wires here. Excellent. Pin four here has nothing in it. Good. So it plugs on this way around with pin one at the top. So with this wiring we should now have the machine fully functional again once I plug the screen back in like so with the wires brought out here where I can show them to the logic analyzer. So let's get that set up and give it a try just to make sure it still works which it might not. It works. I was worried for a moment because from my angle the screen is flat black. Well it's a relief to know that this is actually correct and works. So the next job is to simply plug the logic analyzer in here and then play with the keyboard and see what comes out. So I have the logic analyzer all wired up. This is connected to the breakout board so that it can see all the traffic that's going between the keyboard and the main unit. I've also taken the opportunity to do a bit of wire chasing and pin chasing and I've managed to identify what I believe to be the ground wire which is very useful for the logic analyzer. So the only thing that's left to do is to fire up the logic analyzer like so and power on. Okay continue, type some random stuff and we should be done. Stop. Okay what have we got? We have lots of activity on D3, a little activity on D4, D1 is 5 volts throughout, nothing on D2 which is interesting. Okay so D3 is the green wire here which turns into the black wire here which is the yellow wire here. So I think that must be data. D4 which is the orange wire here which is the red wire here which is the orange wire here, not red, brown, that's eight. Given the way that this goes high at the beginning and then remains low I think this is reset. D1 here is clearly power and D1 is purple wire goes to D2 red wire. Okay so 2 I think is power. This leaves the other wires unknown. There's nothing happening here at all which is interesting. Also the actual traffic is very strange. I would have expected to see at least a clock and a data line. This is clearly not PS2. We do get little bursts, might be bites. So we've got something fast happening here followed by what look like bits but you can see clearly that every transfer does start with one of these sequences. A prologue for the transfer. This one's different. It could be, there's also too many bits there. It could be that the shape of these things signifies whether it's a transfer from the keyboard to the computer or back again. It's interesting there's almost constant, oh there's a gap there, but yeah there is almost constant traffic. Good news. With the help of someone on Reddit I did actually manage to figure out what the transfer protocol is. After spending lots of time trying to figure out why there's high frequency pulses followed by a bunch of low frequency stuff it was eventually pointed out to me that the simplest solution is that it's all just UART data, which it is. So this is one to two followed by zero followed by zero followed by 180 followed by zero followed by zero. This is a command packet. Actually building a microcontroller to poke the keyboard revealed that every time the microcontroller pokes the keyboard the keyboard replies for the byte, which in this case is zero which is why there are no bits there. So what this is actually doing is computer sends one to two, keyboard responds with zero, computer sends zero, keyboard responds with 180, computer sends zero, keyboard responds with a zero. And from there actually figuring out enough of the command protocol to do this is fairly straightforward. What you're looking at here is the output from the microcontroller which is now the only thing plugged into the keyboard. The base station is not plugged in at all and there's enough there for to actually use it as a keyboard. What you're seeing here are individual keyboard events and you can see that if I hold down a key I get a low value, ignore the initial zero or one. So we're looking at one E for the scan code. When I let go we get the same value with a zero order. So that gives me keyboard up and keyboard down scan codes. So there's enough here to actually make it work as a keyboard. Now you may not be able to hear but every time I press a key the keyboard does make a bit of noise. It's slightly hidden under the incredibly loud keys but there'll be a command somewhere to turn this off which I'm hopefully going to find out. Now there is bad news which is that in the process of rigging all this up I managed to touch something with the wrong thing and now the screen doesn't work. I believe that what I've managed to do is to blow the negative voltage generator used by the LCD which is supplied from the base station. Without it nothing appears on the screen. Also the typewriter now no longer works at all because the typewriter has noticed something's gone wrong and refuses to start up. I think I haven't tried this yet but I think that with the screen unplugged as it is now the typewriter should be happy but I will need to look into that and fix it later which is irritating. Apart from anything else I need to know what that voltage is so that I can replicate it on the breadboard to make the screen work. Other good news is that I managed to identify the CPU in the keyboard which is a venerable Intel 8051 no great surprise to anybody and I've managed to extract all the ROM code for it. So the next step is to reverse engineer that because that will tell me all the secrets of the keyboard protocol. We are making progress so I loaded the dump into the Ghidra reverse engineering tool here and it has revealed many secrets. For example if I follow the reset vector to the main program Ghidra has done its level best to turn it into C code here. It's not very good 8051 code so it's missing a few things but it does make it way more readable. We can see useful things like this piece of code is initializing the stack so everything from 7F to 67 is going to be blank. Here we're initializing all kinds of flags and variables. These names by the way I figured out from looking through the code. I don't know what that one does yet but down here is some of the really interesting stuff. This is configuring the serial port so from seeing this I now know the precise board rate and protocol of the serial system. From seeing this this is sending a byte. I know that it's using even parity when sending bytes and stuff like that. I probed the PCB and I figured out which port on the microcontroller the speaker is connected to which is here. Port 3 bit 5 so that I can then follow back and see what is reading and writing that port. Here's some code that is in the timer handler. This for example you can see here it is toggling the speaker bit which on the 8051 is a very neat 2 byte. There's a reason why the 8051 has survived so long since the 70s when it was first developed. So this is obviously generating the tone so from here I can follow back and this counter and this initialization value will control the frequency of the sound. Tick counter here and this flag seems to control whether the tone is being generated or not. This seems to be inverted for some reason. There's a question mark there is because I'm not quite sure why that does yet. Up here there's some more code that controls sound playing. This seems to control the overall tone length while this controls the actual oscillation of the waveform. Not quite sure why it's using both at once but there we go. So we can find the key click stuff by searching for code that sets it up to actually play a sound. So we want something that will program sound length seconds. It's not seconds but it's sort of seconds. So let's just see here is where it is in memory. Here are all the places where it's referenced. We can see it's written at this address and here is a piece of code that is setting a very short blip noise at the highest pitch possible. That sounds like a speaker click and if we scroll right this complicated conditional that Gidra has made a dog's dinner of actually decompiling references a bit variable 2B.6 which is easier to see in the disassembly. So as you can see I've decided that this is controlling the key click. So where is this actually set? Again we follow Gidra's cross referencing. It's in bit variable 5e. It's set in the main code initialization. This function that I see that I've actually misspelled. Let me just correct that like so and go back to the cross reference and a routine here. I previously identified this routine as processing a particular command in this case it was command 88 and what it seems to be doing is taking a single parameter which ends up being stored at this address and then it does things to the sound variables and we can see that if it takes parameters 0x40 or 0x41 it turns the key click flag on and off and the other values seem to play sounds. This flag appears to trigger the actual sound generation and these configure the pitch and the length and this is just boilerplate for actually returning a response which is 0. So it looks very plausible that this particular command which is 88 and I'll put that back in the variable because that's useful to know is the one that allows me to turn the key click on and off. So if I then go and modify my experimental firmware let us see if it works. So here we are back at the workbench. I have reprogrammed the microcontroller with what I now know so if I hit the reset button you can see on the serial terminal here that it's done stuff. Now I can type you can see the state variables changing I now know what these mean thankfully and you can see the scan codes being received where it says one two three packet and a value so that bit works and you should be able to hear the key click beep. Now from what we figured out from this assembly if I type a capital A that's a four one like so that should turn the key click off and that has successfully stopped beeping. I'm not sure how much of that is actually coming through on the microphone. The key switches are so loud that it kind of hides the key click. Now the other things were the code three zero to three four so let's try three zero which is a ASCII zero so if I send that we get a short beep. Let's try the others so that has in fact done precisely what I thought it was going to do it has allowed us to turn key clicks on and off and we can make various beeping noises. This is all we need to make the actual keyboard work mostly we can configure the keyboard oh there is something not quite right with the state machine and the microcontroller it is occasionally dropping uh flag bits I know what's wrong I just haven't fixed it and I can get around it by doing hopefully this not that this there we go now it's come back to life again and now it's stuck again what's happening is that it lost the the flag change that tells the microcontroller that there are keyboard events pending uh so if I type slowly it's less likely to happen but anyway we now have enough to be able to write proper firmware to turn this thing into a USB keyboard except for one thing and that one thing is this you notice these keys are not producing an output this one does but these don't and there's a few more keys as well such as out but shift works code works these two on the left don't work but these two do what's happened is that a complete row or column in the keyboard matrix is dead so the microcontroller is unable to detect keys on that row or column I don't know which now this could be new damage but it's much more likely that this is actually the same issue that has stopped the screen working this would be really good news because this would be much easier to fix this is likely to be on the keyboard board itself I suspect that I've managed to blow a driver line on one of the uh the keyboard chips this is rather better than uh blowing something in the power supply of the actual base station the disassembly shows that the microcontroller simply multiplexing its ports so that they're used for all sorts of things it will set some bits that control some of the external chips that direct data to a particular part of the controller board including the screen so if on initialization it is trying to reset the screen and it's reading a value back from the screen and I can see this happening in the code if one of those driver lines is dead and it's failing to read uh one or two bits then this explains precisely what the symptoms we're seeing so the next thing is to try and figure out what is going on there all the problem was was that the membrane connector onto the PCB was dirty so cleaning that with some contact cleaner everything is now fine this is both good and bad it means that the membrane is fine and fixing the membrane would have been extraordinarily difficult due to the fact that this thing is riveted together with these heat stakes and I would have to drill them all out and replace them with bolts and getting the tension right is apparently really hard on these I'm really relieved not to do not to have to deal with that the bad news is that this means that it's the problem with the screen is a different issue so I suppose I better go and find out what's going on there here I've got the motherboard for the base station I have plugged the keyboard connector into it and I'm tracing that pin one power connector I can trace this down to the keyboard connector on the board we're looking at the back here which goes here it is routed to the expansion connector here and also to this connector this connects to the power supply and the printer mechanism proper on the typewriter now the fact that this is routed just straight through to the power connector suggests that my initial hypothesis that this is the negative voltage power supply for the lcd is more likely than it was previously the microcontroller on the keyboard doesn't use it it just passes it straight through to the screen I can't think of any other signal that we're going from the power supply to the screen so negative voltages this will be why the screen is not working the reason why I think it's this wire is because when I was setting up the microcontroller so they did diagnostic microcontroller they have too many of these things I managed to plug the power supply for the microcontroller into the keyboard's ground and negative voltage rather than the keyboard's ground and power I'm a little surprised this seems to have popped the supply but there you go so that's dead the problem whatever it is is going to be in the power supply module of the base station that is going to be really really difficult to get at luckily the power connector on the base station does actually appear to be labeled so here we are looking at the power board of the typewriter the actual power supply is this enormous box this is just the distribution board these are the wires that connect the power supply to the distribution board so the line we're concerned about is this one which is a2 according to the typewriter just numbering and see this line is labeled minus five yep that is it and when it's turned on that is not minus five volts so that is the problem okay so what do I do about this well one option is to try to repair the power supply I would rather not do that as mains voltage stuff is not my strong point ah there's other things we can do such as regenerating the minus five volts line using a modern buck regulator connected to the five volt line on the on the distribution board here there's tons of space all I would need to do is to cut the appropriate trace on the power board wire in a modular voltage inverter I've got one and you know that sorts out the problem the actual problem with the power supply is probably very simple but I do know my limitations and I don't really want to start poking around there so I think that is what I am going to do also it involves much less disassembly of the system here is the power distribution board with the negative voltage generator module soldered on this takes five volts which comes from this pad here and ground which comes from this pad here and then generates a negative five volt signal it comes out in this wire that is then patched into the appropriate pin on the edge connector and I have cut the track from the power supply here so that it's only seeing the minus five volt line that's come from the negative voltage generator so the next thing I have to do is try it and see find out actually what happens first of course the bench test I have my power supply kept up to here so if I turn it on it is on yes it is on but nothing is happening this is good we like it when nothing happens so we've got the volt meter set up there if I pick ground which is in here we should be able to see plus five volts on this pin there we go plus five volts on that pin on this one negative five volts plus negative and that's the power alarm it's used up too much current these I bet those two touched and shorted it out that's why this is why there is a current limit okay let's do that one again ground negative five volts and on this pin this pin come on this pin negative five volts well over here on the five volt line that's come from the power supply nothing that is now completely isolated okay so that looks like it was working the next thing I've got to do I suppose is reattach this to the power supply off is reattach this to the typewriter main body plug the computer board into it and hook it up and see if anything explodes the last time I used one of these modules I did end up killing a complete computer okay moment of truth time I've powered the base station up with all the electronics unplugged and checked the voltages and they all look good so the only thing to do now is to turn it on for real and see what happens I've plugged the computer into the base station I've plugged the keyboard into the computer so this is all stock so I haven't tried this before let's throw the switch looking good okay uh well the good news is the screen works bad news is producing a different error message 223 I don't know what that is but at least the screen works so I looked up error 223 in the manual and what it's complaining about is something to do with the printer ribbon not being correctly tensioned I suspect what's happened is that due to the way I've been lugging the thing around one of the 37 year old connectors has given up exactly the same thing happened with the uh the keyboard membrane here and it will just require finding the right thing and jiggling it a bit I've cleaned some of the connectors and unplugged and reconnected them and nothing's happened so I am actually going to put the base station aside and deal with that later because I want to focus on the keyboard for now we have successfully determined that the screen works as you can see however I'm going to have to alter my test bed setup because the screen clearly requires a minus five volt power supply so I am going to try and breadboard up a rather better setup for working on the keyboard here is my new improved breadboard which is much tidier everything's on the board you see here is the negative voltage converter module the debug port is still plugged into the microcontroller is running the same firmware as before so the only thing to do now is to plug it in see if it works I have checked the voltages the negative voltage is going to pin one positive and ground the other pins etc it's possible that I don't have the data and reset lines lined up but at this point I'm actually just making excuses here we go nothing on the screen I would expect to see at least some kind of garbage so I spotted one thing that could be causing a problem the voltage reported on the USB is really low see it's hovering around four volts that's partly it's the very long cable connecting the USB device to the actual desktop which is providing power if I check the voltage try that again but with the meter turned on and on camera if I check the voltage to the microcontroller like maybe three volts so I suspect there's just not enough voltage to power the thing on so we'll unplug this and instead power it from this supply here this will require a little bit of re-plumbing I only want to have one power supply on the board and currently it's the p-sock here so I've plugged in the USB power supply to the board and now if I check the voltage to the microcontroller it is a much more sensible 4.7 volts and when I turned it on the speaker on the keyboard clicked which is what it normally does when the power is attached so I will unplug this reassemble the keyboard with the screen on it and try the test again here we go plug in oh there we go is that showing up on camera at all I do see pixels the screen is working I'm not quite sure if the focus is here we go pixels if I adjust the contrast they go away again good the LCD is working hit the reset button and we see it reset on the zero terminal but we're still not getting any output from the microcontroller I've got reset and data the wrong way around here so that one goes into three and that one goes into four so now we hit the reset button again that thing is coming out of the microcontroller we have no power ah that's because I unplugged it okay there we go and we've got stuff out on the serial terminal excellent true that was mildly nerve-racking good we've got the screen working we've got the keyboard working we've got g and h we can make it go beep fantastic okay I think I now have all the pieces actually working to start reverse engineering the screen protocol I've got a bunch of dumps where I can see character and graphical data being sent to the screen so what I will do is I will add the necessary code to the microcontroller to produce some of these and then start poking it and see what happens good news everyone yes I have managed to figure out how to draw on the LCD controller in some ways it's very simple it's a 480 by 32 bitmap one bit per pixel you know set the bit pixel comes on the main oddity is that the bytes are arranged vertically rather than horizontally which is more normal this will be deliberate so that it's easy to draw a proportional text by just drawing a horizontal column of bytes it's also got a huge number of extra features such as actual flashing cursor support which I'm obviously not using here it's got some kind of character based graphics drawing which the base station is using to draw the actual editor text this appears in an overlay on top of the bitmap you'll notice that if I reset this and I get it to redraw again it's actually drawing pretty slowly I suspect that the character based graphics is faster but I haven't investigated that yet there are also a bunch of extra commands that I can see in the microcontroller firmware which I now have a more or less complete decompilation of I know pretty much what everything does in high level terms there's a lot of bit shuffling the base station doesn't actually use any of these so I haven't tried them yet it would be interesting to figure out what they do but I think it would be far more useful to look at the microcontroller firmware and try to figure out what chipset the LCD controller is using as I can see it send commands to the LCD controller if I can identify the chipset then I can get the data sheet for the LCD controller and then I can actually know what all the commands do but that's for another time I now have everything I need I have the LCD working I have the keyboard working I have mapped the scan codes of the keyboard so I know what codes each key produces all the keys work so the next thing I want to do is actually write the real firmware now this thing which I've been using to test with is a psoc 5 development board and they don't make these anymore they were a casualty of the chip shortage during lockdown I like these because they run at 5 volts which is really useful for talking to devices like this and they've also got a basically miniature FPGA connected to an ARM processor so you can do logic stuff really easily and I'm not going to waste this on the keyboard controller so instead I'm going to use one of these which is a cheap and nasty stm32 black pill this one is labeled robot dine stm32 but in the nature of these things there's no guarantee it actually is one I have about 15 to 20 of these due to ordering the wrong thing at one point these are highly capable they've got proper usb interfaces they've got proper debugger interfaces the other great thing about these is their Arduino compatible so that I don't need to use any of the nasty windows software that this thing requires so I should be able to do proper open source firmware which is nice what I'm actually going to do is implement a HID device which supports two things one of them is the perfectly normal keyboard protocol which will be used to generate keyboard events but the other is a very little known HID feature called the alternate display page which allows you to make a HID interface to small LCDs it is perfectly suited to interface to this thing the only trouble is that I cannot find any software anywhere that actually supports this interface I did find one program that talks to a slightly different version of the alternate display functionality but that's designed for alphanumeric LCDs not bitmap LCDs so I'm probably going to have to write my own HID client it would be really cool to be able to write a linux frame buffer device that talks to HID so that I can access this as a proper linux frame buffer device and possibly even extend my desktop onto it that would be amazing but we'll see so my next job is to do the breadboarding to switch from this to this get everything set up correctly and then write the firmware so I'll get on to doing that then I'm halfway through getting the stm32 set up I've done the breadboarding here it is plugged into the flash program and the logic analyzer there's no actual software here yet for doing anything more than just resetting the keyboard but while working on this I found this amazingly cool thing if you power up the keyboard without sending the initialization command and then you press a key this happens it's printing the scan codes on the screen I did not know this was a thing when I was doing all my testing earlier of course I didn't have the negative voltage for the LCD hooked up so I wasn't seeing anything that was on the screen but this is well this would have been really useful for mapping the keyboard and I don't recall seeing anything like this in the actual firmware so I'm going to have to go back and have another look I'm interested because it's scrolling the text sideways I mean this is clearly using the character map stuff in the LCD controller so there must be some kind of mechanism for scrolling the screen either that or there's some kind of fast redraw code if it's using a bitmap so I need to look into that and find out how it works but isn't that awesome also these keys are unreliable there's obviously a corroded connector and I'm going to have to come up with a proper fix for that if I actually want to you know use this thing it works at least enough for the prototype so I've programmed the stm32 here with enough usb hid stuff to operate as a keyboard controller and a hid lcd controller made somewhat more complicated by the fact that the the usb support for the arduino stm32 cause a bit iffy and I found at least one bug also the hid lcd stuff is incredibly poorly documented so that's make a whole bunch of assumptions of how it works but anyway it works so we have a keyboard and we have an LCD and if I this is the client tool which I wrote and we load this ping file it draws which is great you notice however the redraw speed is pretty bad this is because sending images to the LCD involves transferring data from the computer to them to the usb controller the usb controller to the keyboard microcontroller and the keyboard microcontroller to the lcd controller and it's the microcontroller to the lcd that's the slow bit I'm actually sending data to the stm32 here faster than it can be displayed on the screen so there's not a lot I can really do to speed things up if I hit the reset button you see the screen go black and then clear clearing the screen is done by sending a single command to the lcd controller so that is how fast the lcd controller itself can write to the bitmap memory it's not as bad as it looks I have this little print tool here what this does is it renders some text into an image and sends it to the the lcd so we can the software in the microcontroller here the stm32 is smart enough not to send data to the keyboard that it knows is already on the screen so just updating text like that is actually reasonably quick I mean you can still see it draw but it could be so much worse I'm afraid it's not really fast enough for use as a frame buffer extension even if I wrote the software to do it but it should be fine for displaying status 480 by 32 we should be able with a bit of care to get four lines of readable text on it which is going to be useful so what is next well there is some more reverse engineering I want to do for the microcontroller in the keyboard the other thing I want to do is to put the whole thing on this rather ratty piece of Vero board because I actually want to get all this stuff inside the keyboard itself there's plenty of space under here that will let me just have the keyboard as a whole with a usb cable coming out of it and I'd plug it in and it works the whole thing is running at a fairly respectable 200 ish milliamps given that this was all made in 1985 I was expecting more to be honest that is perfectly fine over usb and given the quality of the keyboard I'm quite willing to put up with 200 milliamps of electricity the other two things that need seeing to are the g and the h key that we had problems with earlier that's caused by a dodgy membrane if I find it under these this thing here it is so if I twiddle the membrane it stops working and it's been coming and going all day depending on the orientation of the keyboard it has to be cocks up like this so that it shows up on the camera these lcds are notoriously hard to record that needs seeing to but this is extremely respectable it works perfectly fine as a keyboard the uh the usb composite keyboard driver is working flawlessly I haven't actually checked to make sure I've got all the keys and properly mapped but I think I do I have function keys over here on the left hand block except this one which is escape because the keyboard doesn't have an escape on it the other thing I might be able to use is this but then I'd have to find some way of getting back tick this maps very nicely onto a standard numpad with cursor keys it's not an inverse t cursor block but it'll do so that is excellent next job viewer board moment of truth time here is my piece of shoddy viewer board all viewer board looks shoddy but this one is mine here I have a usb cable you can see the log from my laptop it wasn't working because I plugged it in without the keyboard attached and it doesn't set up properly if there is no keyboard so let's plug it in and see what happens I've checked the pinouts so let's see um well the screen's turned on it's not beeping it's not in demo mode okay had to take the jumpers out before it will boot into for the microcontroller will boot properly so it looks like it's set up the screen however is still black what do I press the key no nothing well here we are with it all disassembled and the logic analyzer attached to it and you can see by the trace that here is the initial 2 2 packet that is being sent to the keyboard of course there is no keyboard to reply this is the reset line on d0 and it's never coming low which explains precisely what we're seeing the keyboard is never coming alive because the reset line which is active low is being held high by this thing now I've checked that the reset line here is actually attached to the right pin here which is b3 so for some reason b3 is not producing the reset signal that is a software issue okay it turns out that b3 is actually used for jtag debugging and I had to remember to turn off the debugging pins so here it is all set up and you can tell by the view here that it does work but I will demonstrate I run it I hit the reset button you can see this is the reset line which goes low and is then followed up by the initialization packet so let's plug it back into the keyboard and see what happens all right I have programmed it so the blue light will turn off once the keyboard is initialized because we won't have a screen or anything so plug in there you go and I don't know if that came up on camera but the keyboard clicked indicating initialization good the board is working right the next job is let me turn this off but the next job is to fix the membrane because if I set this to continuity mode like so and this is all quite small each of these fingers is conductive except for this one that bit at the end is not conductive that's what was causing the GNH key problems okay microscope time luckily I'm recording all this in 4k this time so there's a hairline across there that I bet is a crack yeah it goes diagonally done that way okay we need a fix for this let me think I have wrapped the tape around the end of the tail and it conducts to itself but not to the tail itself so I think that if I were to lift this up and then fold it over so the copper was on the back and then stick it down with more copper that should make contact so that conducts but I have to put pressure on it which isn't brilliant hopefully the clamp will do that but I think I can do better that has in fact not worked so there's the conductive bit there's the bit stuck on the top which doesn't conduct and there's the tail so I push it there it works here it doesn't so I'm going to hook it up to the clamp anyway because that may provide enough pressure to actually make it work I'm sure this is going to turn into a lot of shaky jiggliness but now that that's actually hooked up if I actually looking at the camera screen to figure this out touch the tail there whoops and the solder pad it's making contact so I'm going to call that working so let's put it all back together and try it with the new board okay so we have the system log we have the keyboard plugged in power usb cables are always backwards okay it beeps it's ready we have a g fantastic okay let's try a picture okay that's barely visible on the camera it looks pretty good to me good it works I have the functioning production board working right the next step is to stick this on the inside of this so that I can use it as a single unit okay here's it put in place I haven't done anything complicated I just taped it on with special electrical sticky tape which is supposed to last for a substantial amount of time and doesn't peel off or go goopy or anything like that I'll leave that when I see it now all I need to do is put it back together okay here it is ready to go all complete and finished what I need to do is to plug it into my laptop via a usb-c hub of course and it starts up which takes a few moments and it is now working it's really awkward because it's propped up in a piece of wood to make the screen visible so I will just put something on the screen if I can remember how it works there we go uh oh yes I fixed that bug let me just pull in the new code there you go so yeah I am pleased with this I'm as soon as this video is over I'm actually going to take this over to the other computer at which point I will have to start editing this video but I will be doing it with this keyboard which is what 38 years old which is I think quite impressive okay I am very glad this is now actually working it's taken long enough it's been a fairly intensive week or so of work but I'm pleased with the results all the source code etc will be up on github look in the description of the video for the links if you have one of these keyboards and you want to give this stuff a try please let me know our github issue is probably the easiest way and I would be delighted to try and help and as always I hope you enjoyed this video and if that doesn't show up on camera I will feel incredibly stupid