Building a keyboard interface

kb_wptr = $0000 kb_rptr = $0001 kb_flags = $0002 scan_code = $0003 lda #$00 sta kb_flags sta kb_wptr sta kb_rptr sta scan_code key_pressed: ldx kb_rptr lda kb_buffer, x sta scan_code cmp #$0a ; enter - go to second line beq enter_pressed cmp #$1b ; escape - clear display beq esc_pressed lda PORTA cmp #$66 ; backspace - shift left mode display space beq backspace_pressed lda scan_code jsr print_char inc kb_rptr jmp loop backspace_pressed: lda #%00000100 ; increment and shift cursor to the left; don't shift display jsr lcd_instruction inc kb_rptr lda #$20 ; space jsr print_char lda #%00000110 ; increment and shift cursor to the right; don't shift display jsr lcd_instruction jmp loop

I have added BackSpace key to Ben's keyboard interrupt handler if anyone is interested. Pertinent code on post below. It was a little more complex than i imagined. The lda PORTA may not be the best, but if anyone has a better solution please post.

There’s a description of using 4-bit mode here: https://hackaday.io/project/174128-db6502/log/181838-adventures-with-hd44780-lcd-controller

Phil Dennis

Can anyone explain how to set up 4-bit mode for the display?

I was just working on the keyboard interface too and noticed all 8 pins of PortA were being used for the keyboard. I have no idea how to implement the 4 bit mode for the LCD. Ben, can you do a video on that please so we can continue with the keyboard connection?

I did wonder if I'd missed a video where that was explained, it's quite a big change. I'm not a fan of the 4-bit mode, I'd have preferred to just connect the SR up to port B alongside the LCD and wire its output enable to a spare pin on port A or CB2 or something like that. It's a much more expandable setup that way.

George Foot

This was an excellent video! Thank you so much!

I just realized one more thing - for this video, the interface to the display has been cut down from 8 bit to 4 bit, to make room for connecting the shift register. That could be worthy of a mention since it could trip up people who want to try this out with their breadboard computer.

Phil Dennis

Ah yes I saw that post, I have the same model. I just experimented a bit, thanks for the pointers - I have it working now using a 74HC74 flip flop to send a dummy response. I think what's going on is the keyboard is trying to work out if it should speak PS/2 or USB, waiting for some hint from the host. After sending a dummy byte to the keyboard, it then stops sending AA and sends scancodes as it should.

George Foot

I absorbed the hardware portion of this very easily. Very well described and easy to comprehend. The software side seemed rushed and I had to keep going back and replaying. I’m a software engineer in my day job so this tells me you could do the software portion in a second video and not rush it. Overall this is yet another Ben Eater masterpiece.

Jim Kelly

Not sure what the 'next' video will be about but I would vote for a split (around 25 mins) by ending with 'now we just have to implement the software part; but then add just a bit of unfinished business to make the 2nd part more complete and longer to do something simple but useful: implement backspace, wrap or scroll @ end, home cursor, and left/right? I hope you keep going and ultimately pull a character set together for integrate into the worlds worst (but my favorite) video card. Maybe a few steps towards that...

Michael Weitman

I really enjoyed the single video format so that I can see the software part right after the hardware part. If breaking it up into 2 videos means more Eater knowledge then that would be my vote. If you go the two video route then it would be really nice to have them both come out at the same time. That would be the best of both options. I got a good laugh out of the F0 vs 0F at the end. "And that did nothing..." I would leave that part in there as I think we have all been in that same type of situation before.

Some thoughts on the software portion of the video: As far as I can see, it appears that kb_flags is used without being initialized to zero at the start of the program. Maybe it would be helpful to include a description of how the buffer is circular, relying on the pointers wrapping from $ff to $00 when incremented. Also appropriate might be a warning that in general code should check for the buffer being full before inserting data so as to avoid overflow. The means of setting checking and toggling the release flag within kb_flags seems like it might be tricky for a newcomer and so might benefit from a more detailed explanation, for example involving truth tables. The jump from showing the scan code in place of the counter, to printing the decoded characters seems a little large - the buffer logic and the mapping logic are both added before the code can be run. One possible intermediate step that came to mind would be to print scan codes from the buffer sequentially in hex. And a print_hex function could also be more broadly useful.

Phil Dennis

When I first read the description I went into it thinking it would have to be split into two videos, but after watching it I think it works as one. If you did split it into two, I would want to see how to use Shift to set a register for upper case could be implemented in addition to how to recognize a release, mostly for my curiosity, but also to make sure the software part isn't too short. But I'm new to all of this but quite curious, so splitting HW and SW helps me work on each piece separately a lot better.

I prefer a single video to make it into one package but then I’m an experienced software and assembly guy and hw newbie so I understand people have different opinion on this

Great video! My preference for this video is two separate videos, in first building interface and small code to get keyboard running, and second go in detail how to optimise/write code, to get better result. Then like me one week making trial and error can see with what you come up week later. Thank you for great content!

I would vote for splitting the video - as it stands it's on the longer side with a lot of good info; a lot to absorb and as others have pointed out the split would allow for expanding the software portion. Some suggestions for the hardware portion of the content: 1 of 3: Power consumption/overload implications of slow input rise time for CMOS logic chips - In the discussion on rise time and the Schmitt trigger, you could consider mentioning the excessive power consumption by, and possible damage to, the 74HC04 CMOS inverter chip due to slow rise or fall time on the input. Maybe point out that the datasheet specifies a maximum rise/fall time (e.g. 400ns at 6V as can be seen on the video at 37:55.) It could even be an opportunity for a brief explanation at the transistor level - the need to avoid both transistors in the totem pole output stage being partially on for an extended period of time creating a short circuit, and as a side-effect giving insight on the simple inverter circuits within the chip. 2 of 3: "CRC bit" vs. "parity bit" (minor point) - At 24:30 the video mentions the "CRC bit", of course referring to the parity bit. It would probably be clearer to use the word "parity" since that's what is used in all the literature I've seen on the ps2 keyboard protocol. 3 of 3: Unfortunate behavior of the "Amazon's Choice" ps2 keyboard - An Amazon search for "ps2 keyboard" brings up the "Perixx PERIBOARD-409P Wired PS2 Mini Keyboard" as the "Amazon's choice". I purchased this keyboard to experiment with after the prior video and my observation is that it behaves differently from the one in the video: after it is powered on, it repeatedly sends the 0xAA 'successful self test' code and importantly, does not send any keyboard scan codes until it has been sent a (any) command by the host. I confirmed this by creating a circuit to send commands and the keyboard started sending scan codes after the first command was received. I'm not sure what to suggest here, as sending commands is not trivial (I used the 74HC165 with supporting circuitry.) Maybe a disclaimer that some ps2 compatible keyboards may have this kind of behavior. (More details in my reddit comment to someone having problems with this keyboard: https://www.reddit.com/r/beneater/comments/m836ul/ps2_keyboard_not_working_on_the_6502_but_is/gs9dk4p)

Phil Dennis

How about overlapping keys? Like pressing one key then pressing and releasing another before releasing the first one? Maybe I misunderstand what is sent and I need to look more closely at what is happening? :-)

Yep, you do normally want to do as little as possible in an interrupt handler. I guess I figured the lookup was only a couple instructions. And the release does work for simultaneous keypresses—the keyboard ensures the release sequence F0, xx is sent all at once so xx will always refer to the key being released even if other keys are being pressed nearly simultaneously.

Ben Eater

Yep, that's exactly how I'd do it. Depending on whether the shift flag is set, do the lookup in one table vs. the other.

Ben Eater

A few things not described that came up for me. Why do all the mapping from scan codes in the interrupt and not when parsing the data? Normally you would want the interrupts to be as short as possible no? Also, the solution with a single Release bit would only work if you press one key at a time? As a first working solution this is great though!

Great video! I like how you first do things that dont work, explain why it doesnt work and how to fix it.

Richard

I found a lot of detail was introduced in the software part, and it felt rushed. After thirty minutes, one's attention begins to wane a bit and it isn't always clear why something is being done. Sometimes you allow us to encounter mistakes or explore assumptions ourselves, but in the software part you evade all the problems by adding "oh and also, you'll need to change...". So I would split it into two. One option, to side step the annoyance of a gap between hardware and software parts, is to delay the release of the hardware video by a few days and put them both out simultaneously. That said, I greatly enjoyed the content and---however you want to slice it---I think it is top drawer.

rhc

George! Fan of your YT videos. :-) In my SBC, I simply use a 65C22 to control everything. Have upper/lower case and everything is serial (no shift registers). https://github.com/cbmeeks/Potpourri6502/wiki https://github.com/cbmeeks/Potpourri6502/blob/master/pckybd.asm

Cecil Meeks

I think one of the really special things about your videos is how it bridges the gap between computers and physics. I feel that in a video like this, where you have the context of the other 6502 videos, it's perfectly natural to cover analog -> digital -> software in one go. It really ties the concepts together into a coherent understanding. I can also see the arguments for splitting it into two videos but my personal preference is for the current format!

I felt that the flow from building the circuit to coding the software to use it was very natural. It is a longer video, for sure, but fans of your work know that it's going to be packed with great content. If you split the video, I think that each half will seem kind of light on content. Maybe if you split them, you can expand more on different ways of connecting it, and you can include handling the shift key in the software side of it. Or maybe even throw an eeprom into the mix that can handle the decoding it the keyboard and verifying the start/stop/parity bits (by making them inputs to address bits in the eeprom).

Warren Garabrandt

A single video is fine. What would be really useful though is a link to a hard copy of the final revised program at the end of each video. It can be difficult following what sections of code have been erased and exactly where new code added. Really enjoying your channel - I wish I’d had lecturers like you at college Ben.

I vote 1 video.

Mitch Reynolds

I vote for a single video. I wouldn’t want to build all the hardware and then have to wait a week to learn how to program it. I don’t know if two videos will give you more ad revenue, but if that is not a concern, then single video it is!

Jochen Römling

Yes, you could build a circuit that outputs a high signal if the byte is valid and only trigger an interrupt if that signal and the current interrupt signal are both high.

Dieter Baron

Thanks for new video. 1 part is ok.

Lukasz Pacholik

Seems like there are opinions both ways. But I think two shorter 20 minute videos would be preferable. Plus, two videos released closer together, which would be a nice treat for fans of your videos. I'd watch them either way, but that's my $0.02.

Luke McNinch

It's tough to say. I think for us, your most faithful viewers, we just enjoy the topics and getting content! But for a mass audience, more consumable videos will always be better. I'd probably split them up, if nothing else because I can see it feeling perfectly fine, and two 20 minute videos are easier to consume than one 40 minute one. Keep up the great work!

Christopher Wirt

I think too splitting the hardware and software pieces into 2 videos would be good. If the hardware piece could be wrapped up so when done you could have some sort of meaningful.... even if that term is used loosely... output on the lcd that would be great. And then could the software video be released sooner rather than next month? Thanks for the videos.

I think that it would work better when split into hardware and software part. For the hardware part you could link Dave's (EEVblog) video about schmitt inputs - he's done an amazing explanation of how it works. If you decide to split the video it would be awesome if you could demonstrate handling of shift as for many people it's not easy to think in assembler and how to handle program state on such low level. I think that would be a great addition the to software content. It's great video, as always!

I really like the transition from the digital domain to the analog domain and back to digital again. I've been experiencing the same multiple trigger issue in the range of undetermined voltage values and never understood the use of Schmitt triggers. Now I understand perfectly. Thanks again for the clear explanation. Up next: figuring this out with a USB keyboard ;-). Oh, and regarding your question: I like it as one video. Since the hardware part and the 'software' part is very complementary.

It's great to see that coming together! I was surprised you didn't use another 555 for the delayed interrupt, it would have been perfect for that, but it was great to talk about Schmitt triggers. It would be interesting to look at alternatives like using the 6522's built in shift register which should be possible if your first strip off the start bits.

George Foot

I’ve not had a chance to watch the video yet (I’ll do that this evening), but I just wanted to say for what it’s worth I do prefer the software bit to the hardware. (Though obviously both are great!)

Auctoris

Learnt so much again, as usual - many thanks for doing what you do so well!

Simon-David Pressinger

Regarding the start/stop/parity, could you set up logic to only allow the interrupt to the VIA to go high iff those extra bits are correct?

Rick Mann

I woke up to an early access video from Ben Eater an early view video from 3blue1brown! It is a good morning.

Ivan Toshkov

For me, the more the better, especially if you put chapter markers in the description. I love this stuff!

Rick Mann

I like it better as one video and not two. It goes together well. And thanks for the explanation on schmitt triggers. That helps my understanding a lot. Very cool. You make me want to buy an oscilloscope.

xedover

I personally like the "split" in the middle style. It allows for easier scanning if I where to recreate this.

I like it the way it is. But if you do split it then you might want to add the Shift Flag. That would just be another table (data block), right?

ProgrammerDor