Transcription

Keyboards are one of the most familiar computer input devices, and for many years this PS2 interface was ubiquitous. It also happens to be a relatively simple interface, which makes it great for interfacing with a home-built computer like this 6502. And if you don't happen to have a home-built computer, well, check out Eater.net slash 6502 for kits and links to all the videos on my channel on how I went about building this. But anyhow, if we look at this PS2 connector, you can see there are six pins in here, and actually only four of them are used. Two of them, pins 3 and 4, provide power to the keyboard, and then the other two, pins 5 and 1, are clock and data for communication with the keyboard, so that the keyboard can send information about keystrokes. Now to connect to these pins, I'm going to use a cable here that has the opposite connector, and I can just use this, and I'm just going to cut this end off, and then strip off the insulation to get to the wires inside. And inside here, we've got, looks like four wires, red, black, orange, brown, as well as the shield. So I'll go ahead and strip these as well. Thin enough, I can just use my fingernails, and I'll just twist these to kind of clean everything up. So there we go. Now we can get to all the wires, and it actually only breaks out the four wires, because there's only, as we saw, only four pins being used, as well as the shield, which I guess we'll just connect to whichever one of these is ground. And now to figure out which pin is which, we can use a multimeter. So this is the ground pin here, so let's see which of these is ground. Looks like maybe the orange one. So the orange one is ground, and I can just go ahead and twist that to the shield, because we want the ground and the shield connected. And then I can go ahead and figure out the other pins. So five volts is that pin, so let's see. So five volts is black, that figures. It's kind of confusing. And then the data pin is pin one, I believe it's that. So data is red, and then clock is pin five right here. So that ought to be the brown one. Sure enough. So here's what we found. So ground and power are orange and black, and then clock is brown, data is red. And if we want to go ahead and hook up power, I've got a five volt adapter here that we can use. And we just need to hook these up to the orange and black. And what I'll do is I'll just use these jumper cables here. So we'll hook up the five volts So we'll hook up the five volts from the power adapter to the black wire, which we found is the five volt wire. And then I'll hook up ground from the power adapter to the orange and the shield, which is ground here. And so now we still don't have anything hooked up to the brown and the red, which are the clock and data, but we do have power hooked up. So if we plug the keyboard in, let's see what happens. And you see those lights flash, so the keyboard got power. But of course we don't have the clock and data hooked up, so, you know, nothing's gonna work. But now let's take a look at what those clock and data pins are doing. So now to see what signals the keyboard is generating on the clock and data pins, I'm going to hook up an oscilloscope probe. So I'll connect the ground to this ground here, and then I'll hook a probe up to the clock pin, and then I've got a second probe here that I'll hook up to the data pin, and I'll connect the ground here as well. All right, so we've got our clock and data hooked up to the scope here. So if we start pressing some keys, it looks like something's happening there. Let's zoom in, and let's see, adjust these. There we go. So we have clock and data, and it looks like we're getting some kind of signal here. So we have our clock, which has a bunch of clock pulses, and then we have the data down here, and it looks like on each clock pulse, you know, the data is either going to be a zero or one, so we're getting just a series of bits that are coming out of the keyboard, which makes sense. And you'd expect a different series of bits depending on which key we press. And sure enough, it looks like as we press different keys, we're seeing different data show up here. So that's really cool, but what can we do with this? How would we actually interface with this and hook it up to a computer or something like that? How do we extract all of these bits? So one thing we might want to do is convert this serial bit stream, where we just have two signals, clock and data, and convert it into a parallel stream where we have, we actually have eight data bits on separate wires that we can then interface into, you know, a computer bus. Now whenever I think about converting a serial clock and data into a parallel interface, you know, I think about using a shift register. And the 74HC595 is a very popular shift register. And basically what happens is on each clock pulse here, it'll read whatever is coming in the serial data input and put it on the first output. But it does that after shifting what was on that output to the next output. So each time a new clock pulse happens, we read a new bit in and shift all the existing bits down to the next output, and then that new bit shows up here. So after eight clock pulses, we'll have read eight bits in, and we'll have all eight of those bits showing up here in the output of the shift register. Now in the case of the 74HC595, the outputs of the shift register go into a latch, and I guess the idea here is that you could read eight bits in, then trigger this latch clock, and then all eight bits will immediately, sort of simultaneously, appear on the output here. You can also trigger the latch clock for each bit, and then you'll just sort of see the same thing showing up on the outputs here. So I've got a 74HC595 chip here that we can hook our keyboard up to. So let's go ahead and do that. Of course, right now we've got our keyboard broken out like this, and I'm going to kind of leave this the way it is. What I'll do is I'll hook up some jumper cables here that will let us connect it directly to the breadboard a little bit easier. And so I'll just use the clips on the probes or whatever to hook up one end of each of these jumper wires to the four wires coming out of the keyboard. And to keep things simple, I'm just going to use the same color wires as what was in that keyboard connector, even though the colors don't really make any sense, because it's, you know, black for positive 5 volts and ground is orange, and then clock and data are brown and red. So there we go, and now we've got basically these four pins that I can hook up to a breadboard very easily, so we can start experimenting with this. So I will gently move this aside, and we can get to work interfacing the keyboard to our breadboard. And so now if we look at the pinout for this, we can start hooking some stuff up. I'll start with power and connect the power rails of the breadboard together, and then power and ground for the chip. And then if we look at the other pins on this chip, you see we've got all of these Qs are outputs, so QA, B, C, D, E, F, G, H, those are the eight outputs. So those are all those pins, and then A is the input, that's the serial data input. So that we would connect to the clock pin, or rather the data pin, that's the data input. So that would be the red pin coming from the keyboard. So we could connect that directly to pin 14 like this. Then we have an output enable pin, and if we always want to see what's coming out of our output, we just want to always have that enabled. And you can see it's got the little bubble here, so output enable is active low, which means we want to tie it to ground in order to enable the output. So go ahead and tie that pin to ground. Then we get our latch clock and our shift clock, and the shift clock is our clock coming in from our data source. So we've got our clock and data coming in from the keyboard, and so that shift clock is going to be the clock from the keyboard. So we could hook that up to pin 11, and remember the clock is the brown wire. So we could hook this brown wire here right up to pin 11 like this. Although there's one little problem with that, which is if you look at the clock signal that we're getting, you can see it normally sits here at five volts, and then the clock pulse is actually going low. And so the way that this works is that each bit is clocked on the falling edge of the clock, not on the rising edge, whereas the shift clock on the 75HC595, this is going to be shifting on the rising edge. And so to convert that falling edge to a rising edge, what we could do is actually just invert this clock signal, because if we just run this whole clock signal through an inverter, then instead of this being a falling edge, it'll be a rising edge, and it'll clock at the right time. So here I have an inverter. This is a 74HC04, and what we can do is we can take this clock, put it into one of the inputs on the inverter, and then run the output of the inverter into the shift clock. And then this inverter, of course, needs its own power and ground connections. And so now what we have is we have the data, serial data, going into pin 14 here, and then for the shift clock, we're going to have a rising edge at each data pulse. So we're inverting the falling edge clock to a rising edge clock, and so on the rising edge of each clock pulse, we'll read this data into the shift register, and we'll have some outputs here. Then moving on, we've got pin 10 here, which is the reset pin, and you can see here from the diagram that pin 10 has got the little bubble there, so it's an active low, which means if we pull that reset pin low, then the shift register will zero out all of the outputs, so set all those to zero. We don't really want to do that in normal operations, so normally we would want this reset to be high, so what I'll do is I'll go ahead and tie pin 10 high. So that's almost everything to get the serial data and clock shifting that data in and having it appear over here, but of course to get it out of the chip, we also need this latch to, you know, each time, you know, we change the data coming in here, we need this latch to transfer the output of the shift register to the actual output of the chip, and to do that there's this latch clock, and, you know, what we could do is we just tie the latch clock and the shift clock together, so that would just look something like this, where we just connect both the latch clock and the shift clock to the same clock pin, so that every time a new data bit comes in, it'll shift it in the shift register, and then it'll also trigger the latch to copy that data to the output here. So we're just tying those two clocks together. Now there is going to be actually a problem with this, which is that we don't really want those to happen at the same time, because if we shift the data in and at the exact same time take whatever's on the output here and shift it to the output here, we could get into a situation where the new data hasn't actually populated or propagated, I guess, through the shift register and appeared here before this latch is taking whatever output is there, whether it's been updated or not, and copying it and latching it in on the output here. So ideally what we want is we want this latch clock to happen a little bit after the shift clock. So we want the shift clock coming in to read that data, put it out on the output of the shift register, and then just a little, a moment later, we want the latch clock to then, you know, once this data is stabilized, copy it to our outputs here. So tying them together, we won't get that delay. But one way to get the delay is just to run it through a couple extra gates. And, you know, we've got this inverter here. So if we take that signal that's coming out and run it through two more inverters, it'll invert it and then invert it back again, which won't change the signal at all. But because the inverters have a little bit of a propagation delay, it'll add just enough delay. And it may only be a few dozen nanoseconds, but it's enough so that it's a little bit of a delay. So what I'll do is I'll take the output of this inverter here, so basically the same clock signal, and run it into the input of this next inverter. Then I'll take the output of that next inverter and run that into the input of a third inverter. So we've got the original clock signal coming in. We're inverting it to get a rising edge clock for our shift clock. Then we're inverting that clock and inverting it again to get an output that's going to come out over here, which is going to be basically the same as this, but very slightly delayed. And now what we can do is we can take that output and run it over to the latch clock. So we've got the original clock coming in from the keyboard. We're inverting that to get a clock that's a rising edge for each bit. And that's our shift clock. Then we're inverting it two more times to get what is essentially the same rising edge clock, but very slightly delayed, and using that as our latch clock. That way the data will be shifted in, it'll come out over here, and then just a moment later it'll get latched out and show up on the outputs here. Hopefully that makes sense. So now if we want to actually see what's coming out of those outputs, we can connect up some LEDs. So I'll add a bunch of LEDs here to the breadboard that we can use to look at the outputs. And then I'll connect the cathodes of each LED to ground through 220 ohm current limiting resistors. There we go. And so now we could connect the outputs of the latch here up to this side of the LEDs, and we would see what the latch is outputting. But there is one little issue with this plan, which is if we look at this latch, it's got eight bits, and I've got eight LEDs here, and that's all good. And you would sort of expect, you know, if you hit a key there's some eight-bit code that it's going to spit out. But some of you might have noticed there's actually more than eight bits here. In fact, if we count the clock pulses, we've got 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. So we've got 11 clock pulses, which suggests, you know, we could, you know, read 11 different bits out of this. And that's, you know, sort of regardless of what key you press, you're always getting, it looks like, the same 11 clock pulses with just, you know, different data for each key. And so the 74HC595 has only got eight bits, but fortunately it also has this serial data output, which is really just taking that last bit and allowing you to feed it into the input of another 74HC595. So you can cascade these, so that as bits shift through here, as they kind of shift and fall out the last bit here, you can then feed them in to another one of these, and they continue to populate. So you can string as many of these together as you want, depending on how many bits you want to keep track of. So since we want to keep track of more than eight bits, we want to keep track of 11 bits in this case, I can add another 74HC595 and connect it up the same way. So I'll connect up power and ground, and I'll pull the output enable low, it's an active low, so the output will be enabled. And I'll pull the reset pin high, that's also active low, so high will mean it's not being reset. And then what I want to do is I want to take the serial data output, pin 9 of the first chip, and hook that into the serial data input, or pin 14 of the second chip. So pin 9 of the first chip into pin 14 of the second chip is right there, so we've got the output of one going into the input of the next one. And so now we've got cascaded shift registers. The only other thing we need to do is hook the clocks up, so I'll hook up the shift register clock, and it's just going to be the same clock, because it's all, everything's being clocked at the same time, because as each bit is shifted through, we're shifting them all through all 16 now of the bits that we've got at the same time. And then same thing with the latch clock, I'll just hook those together. And so now we're able to read in and store 16 bits if we want to, but we really only want 11, so we'll just use the first 11 and just ignore the others. So let's go ahead and hook those outputs up to the LEDs, although actually we'll need a couple more LEDs. So let me add a few more LEDs here so we have 11 LEDs. And I'm using different colors for these last three LEDs, and I'll explain why in a little bit, but in any event now we've got 11 LEDs, so we can track all 11 bits that the keyboard is sending. And of course I'll add those 220 ohm current limiting resistors to each of those LEDs. And so now we just need to hook the outputs up to the LEDs. And the first output is here on pin 15, it's QA, and then the next seven are on pins 1 through 7. So there's bit 1, 2, 3, 4, 5, 6, 7, and 8. So those are the first eight bits, and then we've got three more coming off the second chip. So we'll do bit number 9, is right there, 10, and 11. And then I'll just go ahead and tidy some of this up a little bit, and there we go. Okay, so let's go ahead and power this up and test it out. And remember we've got this 5 volt power coming in that we're using to power the keyboard, and so the ground is connected back around here to the orange wire, and 5 volts is connected around here to the black wire. And so we can use that orange and black here to power our circuit as well. So again, let's see, orange is ground, and then black is 5 volts, so we'll connect that there. So now we should be powering our circuit with the same power supply that we're using for the keyboard. And now if we press some keys, we see some lights showing up here. And depending on which key we press, we get a different code. And you can look up online a list of keyboard scan codes, and you'll find some, you know, table that looks something like this, where for each key it has a hexadecimal scan code. And we can use that to decode what key was pressed. So in this case, if we just look at the green LEDs for now, this binary 1 1 0 1, 1 1 1 0 converts to, would that be 2 e in hex. And if we find 2 e in hex, we can see that's the scan code for the 5 key. So that means that the last key I pressed was probably 5. But if I press a different key, like let's say I press 1, we should see a scan code of 1 6. And sure enough, that's a 1 and a 6. So that makes sense. The keyboard's giving us 8 bits of data, and those 8 bits of data convert into a key that was pressed. But what are these these other bits? You know, why do we have 11 bits here instead of just the 8 that it seems like we need? Well, that has to do with the protocol that the keyboard uses for error detection. And the way it works is that for every code that the keyboard spits out, the first bit is actually always a 0. So if you think about the order that the bits are coming out here, we've got a 0 0 1 1 0 1, and then a bunch of zeros, and the last bit is a 1. And if we compare that to what we've got here, this would be the first bit. So 0 0 1 1 0 1, a bunch of zeros, and then the last bit is a 1. So remember, the first bit is getting pushed all the way to the end through the shift register by the time the last bit arrives. So the first bit is over here on the right. So that first bit is actually always going to be a 0, and that's just baked into the protocol that the keyboard uses. And that's called a start bit. So there's always a start bit, and it's always 0, followed by the eight data bits, followed by a parity bit, and then a stop bit. And the stop bit is always 1. So anytime we get a code from the keyboard, we're always going to see this first bit over here on the right is going to be 0, and the last bit that comes out of the keyboard, which is here on the left, is always going to be a 1. And if that's ever not the case, then that means that there was some kind of problem with the data that we got from the keyboard. So either we're not synchronized with, you know, the 11 bits we're showing here aren't, you know, a valid packet of 11 bits coming from the keyboard, or, you know, some other problem. So that's a good sanity check to make sure that we're actually getting valid data from the keyboard, is to make sure that the start bit and stop bit are set correctly. And then the yellow LED here, the bit that comes directly after the data, that is a parity bit, and the keyboard uses odd parity, which means if you include the parity bit and the eight data bits, there should always be an odd number of those bits that are 1. So in this case, we've got 1, 2, 3 of them that are 1s. 3 is odd, so that's correct. If I press a different key, like 2 in this case, the scan code for that is 1e, and so that's what we see, 1e. But in that case, there are four bits set, 1, 2, 3, 4. So in order to make odd parity, the parity bit is set, so that way there are five bits set, and five, of course, is odd. And so as long as there are an odd number of bits set between the data bits and the parity bit, then we know that something's correct. And that way we can detect, you know, if there's a single bit that's off, then the parity check will fail, and we know that, again, something has been corrupted. And if you want to learn more about parity, I've got several other videos you can check out on my channel that talk about parity in much more detail. But basically, as long as the start bit is 0, the stop bit is 1, and the parity checks out as odd parity, then as far as we can tell, we've got valid data here, and we should interpret this as one of these scan codes. At this point, you know, if we don't care about error detection, we could interface this to a computer just by taking these eight bits, feeding them into eight input bits on our interface adapter here, and then any program that we had running on the computer could just read from that input port whenever it wanted to. It would get, and it would, you know, get these eight bits, and it would just read in the scan code of the last key that was pressed. And so that would give us some sort of, you know, rudimentary keyboard interface, I guess. But these scan codes are a little bit more complicated than just telling you the last key that was pressed. So you can't just necessarily assume that you're always going to have this eight-bit value that distinguishes a single key. For example, if you just look at this list of scan codes, you can see some of them aren't eight bits. Some of these are actually 16 bits. So, you know, for example, the home key is E06C. So if we go ahead and press home, what we're seeing here is 6C. So we're seeing the last eight bits, but we're not seeing this E0 part. And that's because it's happening. It's just happening so quickly that we're getting the next byte coming through here. So if we actually zoom out a bit and hit home, you can see there's now a second byte that's happening here. And so if we wanted to capture that here, we would need more than just the 11 bits that we've got in our shift register. We would need 22 bits if we wanted to store two of those little data packets. Well, that's no problem. We can just make another shift register. In fact, I happen to have one right here. So let me hook this up and get everything connected. And so this is just a carbon copy of what I've got here already. And there we go. And for this to work, we'll want the clocks connected. So I'll go ahead and connect the latch clock as well as the shift register clock. And then, of course, for the top one here, the data input is coming from the keyboard. But for this next one, the data input, we actually want to just come out of the 11th bit of this top one and use that as the input to the second one. So that whatever sort of as we shift things in, whatever falls out the end here will get shifted in down here and continue to be stored. So we'll go from the 11th bit of our shift register on the top here and connect that to the input of the second shift register on the bottom. And so now if I push home and I'm going to hold it down, we see E0 on the bottom and then 6C on the top. So that's the E0 6C that matches what we should see for home. But you'll notice that when I let go of home, I get F0 6C. So there's actually even more going on here. In fact, if we zoom out further, when I press home, you see there's actually three data packets. So when I press home, there are two data packets, and when I release it, there are three. You know, home is one of these strange keys that has the 16-bit scan code. How about some other key just like A, you know, just normal single byte scan code? What does that do? When I press A, I get a single byte. When I release A, I get two bytes. So it looks like the keyboard is using an extra scan code to tell us about the key being released, which makes sense. That seems like something you'd want the keyboard to tell you. And in fact, the way it works is when you press the key, so here I'm pressing A and holding it down, and you see we get, this is, say, 1C, which when we look at the codes here, A is 1C. So we're getting that 1C, and you see it's flashing, and that's because I'm holding the key down. And so every, I don't know, 100 milliseconds or whatever, it's actually resending this code, which is how a keyboard works, right? If you hold down a key, it repeats. So it's repeating that code, and then when I release it, I get this F0 1C. And so F0 is this special scan code that means whatever is following it is being released. So when I see F0 1C, it's saying the key is being released, and that key is A, so the A key was just released. And then something similar is happening with these, you know, things like home, these 16-bit ones. The difference here is that the E0 prefix indicates that this is, I guess, what they call an extended scan code. And so when we press home, for example, we get the E0 followed by 6C. And then when we release home, we actually get an E0 we're not seeing, followed by an F0 to say releasing, and then the 6C. So essentially, the release code for home is E0 to say that it's an extended scan code, followed by the F0 to say it's being released, and then the 6C. And of course, if we actually want to see that, we would need to add more registers, which, you know, we can do. I've got another one here, so let me hook it up as the next in sequence here. And of course, I'll connect up the latch clock and the shift register clock, as well as connect the output of the 11th bit in the second register to the input of the third register. So now if we press home, when I release it, you see the E0, then the F0, and then the 6C. So when I press home, and when I'm holding it, the key code that's repeating is the E0 6C. When I release, I get E0 F0 6C. So that's the release code. Whereas, you know, a normal key like A, when you press it, you just see the code repeating for A, because I'm holding it down. And then when I release, you'll see the F0, followed by the code for A again, to say that the A key was released. So here you see the A key was pressed, and then it says we're now releasing the A key. So that's sort of how to interpret it. And so you can see we're kind of keeping a history of all the scan codes coming in. And, you know, in principle, we could keep adding shift registers to be able to store as many scan codes, or sort of buffer, if you will, as many scan codes as we want. And so that's pretty much what I did. Just keep building until I got bored. And so you can see I've got about eight of them here, at least as far as you know. And this is actually pretty cool for being able to see how the keyboard works, because I can just type something like A, B, C, and we can see all the scan codes coming in. So this is where I release the A. This is where I type the B, and release the B, type the C, and release the C. So one interesting thing would be to look at, like, typing a capital letter. Like if I want to type a capital A, the way the keyboard sends that to the computer is literally telling you we're pressing shift, we're pressing A, we're releasing A, and we're releasing shift. So the keyboard doesn't really have a notion of a capital A or lowercase A. It just has a notion of a shift button and an A button, and it's up to whatever the keyboard is interfaced to to work out what that actually means. And then as I mentioned, some of these keys have extended scan codes. So, you know, home we were looking at before is E06C. So if I press and release home, here's where I press it, E06C. And then here's where I release it. You have the E0 and then the F0 to mean release, 6C. So overall there isn't much rhyme or reason to these scan codes and the keys that they correspond to, at least not that I can make sense of. But one thing that sort of makes sense is that home, if we look at that again, it's an extended E06C. And if you look at what 6C is by itself, it's 7. But this is the 7 on the number pad, not 7 along the top, which is 3D. And if you look at 7 on the number pad, that's also the same as home with numlock off. So it sort of makes sense that you have the same code for this home key versus that home key, but this would be extended. But I have to say, overall, the scan codes don't make a ton of sense why they're assigned what they are. I'm sure there's some reason, and maybe someone in the comments will know more about that. But of course, whether this key is home or 7 depends on whether numlock is active. And you can see if I just press numlock, it's got a code of 77. And so it's just like any other key, and it would be up to, again, whatever's interfaced to this keyboard to know whether numlock is active or not. And I won't get into it in this video, but there is a way this interface with the keyboard is bidirectional. So there's a way to send codes to the keyboard as well. And that's how you would do things like turn the numlock light on or off, because the keyboard doesn't actually track that internally. And then, I don't know, a couple other interesting things. There are a couple of keys, the pause key and the print screen key, have very bizarre behavior. The pause key has this make code and no break code. So this make code, it spits out eight bytes whenever you press the pause key. So as soon as I press this pause key, all eight of those bytes pop in, and there's no break code. So if you press pause, you get those eight bytes. When I release pause, nothing happens. So that's kind of interesting that that behaves that way. Print screen, on the other hand, has this 32-bit make code and then a 48-bit break code. So when I press print screen, it's just going to give us those four bytes over and over. And when I release it, we get six bytes. And I don't know why that is. I'm sure there's some historical reason, but that's how print screen works. But at any rate, it may seem excessive to build all of this just to interface with a keyboard. But, you know, honestly, it's actually not that crazy. I mean, certainly it's crazy to have LEDs on everything, you know, because I've got 88 LEDs. But those 88 LEDs really just represent 88 bits of memory. And 88 bits of memory is just 11 bytes of memory. And 11 bytes of memory is not that crazy in a shift register. So at least in principle, a design like this is not that crazy for a keyboard interface. In fact, you can imagine if you're interfacing it to a computer like this, that you would have some I.O. space to find for the keyboard. And there might be a series of addresses. It could be eight addresses like this, or it could be more, perhaps. And the CPU could just read from those addresses off the bus and have access to a buffer of the latest keyboard scan codes. And, of course, then it would be up to the CPU to make sense of them. But that's not a crazy design. You could imagine other designs, for example, instead of buffering, you know, a whole bunch of scan codes, you could have each scan code cause an interrupt on the CPU, and then the CPU goes into an interrupt handler that reads that scan code, hopefully right away before the keyboard sends another one. But you could probably do that. Another alternative might be something more sophisticated where you have maybe a microcontroller or something that's directly interfacing with the serial interface from the keyboard, and doing a little bit more than just putting out raw scan codes and feeding those to the CPU. Because you'll notice that these scan codes don't really have any rhyme or reason, as far as I can tell. You know, scan code one is F9, scan code three is F5, scan code four is F3. Like, they're not in any particular order. And certainly the letters and numbers and things don't map to ASCII codes or anything that you would normally see used in a computer. So it might make sense to have some little microcontroller or something that has a little bit more intelligence to be able to map from scan code to, say, an ASCII code, and keep track of whether the shift key is held down at the moment, or things like that. So I guess all of that's to say that there are lots of different ways you could go about building a keyboard interface, and I'd be interested in hearing what you guys think is maybe the best way to build an interface for something simple like this. So let me know what you think. And remember, if you want to build your own 6502-based computer, minus the ridiculous keyboard interface here, I've got kits over at my website, eater.net slash 6502. Go check that out. And as always, thanks to all my patrons, who help make this video and all my videos possible.