What the video calls "debounce" is just an autorepeat delay. And on AT and PS/2 keyboards it is not done by any kind of PC side software (neither driver nor keyboard controller firmware), but by the keyboard itself (In late 90's/early 00's there even were PS2 keyboards where you can set the rate manually with key combination). In the protocol layer, autorepeat works by repeating the key down event without key up events in between, so if you are interested in state of the key without the autorepeat you can simply ignore key down events for keys that you already see as down.

The real debouncer hardware is also in the keyboard itself for all standard external keyboards ever used with PC.

On the other hand there were simple keyboard interfaces which involved reading out the whole keyboard as if it was one big shift register and debouncing was then done on the host side in software, two examples from top of the head are Symbolics machines and Wyse terminals. Interface for (S)NES controllers (really for Nintendo controllers up to GameCube) is similar, but I'm not sure whether debouncing is done by controller hardware or not.

I hated the PC keyboard repeat rates until I started using X-Windows and found 'xset r rate 160 80'. Warning: don't typo those numbers or you might have a fun time restoring a sane default :-)

Debouncing is a pattern used in UI software development. Here’s an implementation.

http://underscorejs.org/#debounce

I never would have guessed that debouncing was first used to tame physical keys bouncing on contacts.

Every keyboard has one, every microcontroller reading pushbutton inputs will have one. There is one in your mouse.

The impression I got from the DOS video is that the debouncing function may have just been moved over into software?

The guy in the video is confused. He says

> The default keyboard handling on a DOS PC are meant for typing. So any time you hit a key there is a debounce before the key is allowed to repeat continuously, usually on the order of a quarter second to a half second.

What he is describing is the keyboard driver autorepeat feature, if you hold down a key for a while the driver will generate a sequence of virtual keypresses. This is just a software convention, it's also possible to read the state of the keys directly (pressed down or not) instead of treating them in terms of key-press events. Using the word debouncing for this is incorrect.

Debouncing happens on a millisecond time scale, it's due to the key actually physically bouncing.

> it's due to the key actually physically bouncing.

More precisely: it is due to the contacts bouncing, they don't close just once when they touch each other, they rebound and close again, this repeats a number of times before they finally settle.

Consider it just one more example of software eating the world. Yes, it is in software now, not in hardware but the function is exactly the same. One of the first assembly programs I ever wrote was a debounce routine for a KIM-1 (it already had one, but that didn't stop me from reinventing that particular wheel).

That's how it's often done with Arduinos:

https://www.arduino.cc/en/Tutorial/Debounce

What is done in software is translation from raw scan codes to ASCII which is done by BIOS code (or overridden by DOS driver for non-US keyboard layouts) that handles interrupts from keyboard controller and presents API on INT 16h.

This code works by tracking state of modifier keys (and setting the keyboard LEDs appropriately) and converts key down events for other keys into keycode/character pairs.

DOS in turn provides function INT 21, AH=07 which is thin wrapper on top of INT 16h which waits for key press and returns it as either ASCII character or zero followed by extended scan code (returned on second invocation) for non-ASCII keys (this DOS function is what is called by readey() in Borland Pascal/C++).

Edit: it is not as thin wrapper as it looks like, because it does not blindly call into BIOS and block there, but loops in DOS code and calls INT 28h until key is ready. INT 28h is intended as a hook for TSR to either do unimportant background processing (kind of poor mans multitasking) or call into DOS when it is known to be safe to do so. Particularly interesting thing to do in INT 28h handler is executing HLT in order to conserve power as any condition that would cause DOS to exit from this loop generates interrupt.