3 ms·

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

by bane 9y ago

swimfar 9y ago
That's how it's often done with Arduinos: https://www.arduino.cc/en/Tutorial/Debounce https://www.arduino.cc/en/Tutorial/Debounce
vilhelm_s 9y ago
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.
- jacquesm 9y ago
  > 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.
dfox 9y ago
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.
jacquesm 9y ago
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).

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

by bane 9y ago

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

That's how it's often done with Arduinos: https://www.arduino.cc/en/Tutorial/Debounce https://www.arduino.cc/en/Tutorial/Debounce

vilhelm_s 9y ago

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.

jacquesm 9y ago
> 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.

dfox 9y ago

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.

jacquesm 9y ago

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).