18

Back in the days of MS-DOS, when I needed to type a special character that wasn't part of the keyboard layout, I would press down the left Alt key and type out the character code on the numeric keypad (Alt+130 for "é", Alt+150 for "û") and the character would appear on screen. This was very convenient when the machine I was working with didn't have the proper KEYB command active to support accented characters. This behaviour was so universal that I figured this was implemented by firmware in the keyboard itself.

With Windows NT, this was still possible (using the LEFT Alt key) but there was also a possibility of typing a character via its Windows "ANSI" character code (code page 1252 in my case) by prefixing with 0 : Alt+0233 for "é", Alt+0251 for "û". Coupled with the use of Ctrl+Alt+Del as an Attention key, it was clear that Windows itself had intimate involvement with the keyboard.

Now I'm using Linux Ubuntu and I find that these Alt+num shortcuts don't work at all.

So, has the Alt + numeric keypad feature always been implemented by the OS since MS-DOS 1.0? Or was it implemented in the keyboard firmware or BIOS at one point, and modern operating systems just circumvent it somehow?

user3840170
  • 23,072
  • 4
  • 91
  • 150
Nimloth
  • 2,068
  • 8
  • 16

3 Answers3

31

Handling of ALT plus Numpad 0..9 is done by ROM-BIOS, call it Firmware if you like. DOS-BIOS uses it untampered, other OS may differ.

  • The process is described on page 3-15 of the PC's Technical Reference Manual (6025008 of August 1981).

  • The code is part of the Keyboard interrupt routine starting on p.A-25 line 1784.

  • The ALT-keypad routine itself starts at Label K32 on p.A-28 line 1966.

DOS simply used what BIOS gave it, so the BIOS routines worked fine under DOS itself and all user programs that did use DOS (or BIOS). It didn't necessarily work with programs having their own keyboard handler.

Of course if an OS is not using the BIOS - which Linux, or any modern OS, most likely do not - then it's up to the keyboard driver of that OS to offer that function ... or not, like you experienced.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • This makes me wonder: did Linux in the olden days use the BIOS for keyboard input? (Implying that alt-numpad codes did work then) – Oliphaunt Aug 16 '22 at 22:51
  • 1
    @Oliphaunt I would not think so. After all, it's utmost important for any (somewhat) complete OS (in that context DOS is more of a disk handling library) , to controll all interrupts - which includes ofc the keyboard interrupt (#8). Not to mention that Linux runs in virtual memory mode, where BIOS has no say anyway. – Raffzahn Aug 16 '22 at 22:55
  • https://archive.org/details/waitegroupsmsdos00simr is another great resource around that sort of thing from that era. – Drazisil Aug 16 '22 at 23:56
11

The ALT-GR numpad entry to enter any character is a feature of motherboard BIOS which the x86 CPU executes.

It is not a feature of firmware running on keyboard and doing the matrix scanning.

It is not a feature of firmware running on the AT or PS/2 motherboard keyboard controller.

The character code is put to keyboard buffer by BIOS and thus any OS that uses the BIOS keyboard interface, such as MS-DOS, will get these characters via BIOS keyboard buffer.

Modern OSes don't use the BIOS keyboard interface so they are free to implement any kind of keyboard functionality they want.

Justme
  • 31,506
  • 1
  • 73
  • 145
8

The IBM PC keyboard behaves as though it holds a bitmap of every key that is pressed or released, and repeatedly scans the keyboard, comparing the present of each key with the state in the bitmap. It also maintains a tick count of how many scans have been performed since the last difference was observed. If a difference is observed, it will enqueue for transmission a byte value of 1-127 if a key was pressed, or 129-255 if a key was released. If the last byte value was 127 and the tick count reaches a certain threshold (initial repeat time), the keyboard will re-enqueue its last byte and reduce the tick count by a certain amount (additional repeat-event time). The keyboard itself has no concept of modifier keys; all of the keys behave in equivalent ways.

While it would not have been difficult or expensive for the BIOS to keep a full bitmap of every key (16 bytes would be enough to cover all possible keycodes 1-127) the BIOS looks for six particular keycodes corresponding to left shift, right shift, control, alt, caps lock, num lock, and scroll lock, and has a single byte which it uses to keep track of which of those keys are pressed. Additionally, it has a second byte which it uses to track the state of latching modifiers. If a code 1-127 is received when its associated bit in the first byte isn't set, the BIOS will toggle the corresponding bit in the second byte.

The BIOS also has a byte it uses to keep track of an entered character code. If the BIOS seeks that a number-pad key is pressed while the Alt-key bit is set in the modifier-state byte, it will multiply the value in that byte by 10 and add the numerical value of the number-pad key. If the BIOS sees that the entered-character-code byte is non-zero when it receives a key release for the Alt key, it will stuff the associated character code into the keyboard buffer.

supercat
  • 35,993
  • 3
  • 63
  • 159
  • 5
    It's slighly more complex than that. In the PC and XT era, the keyboard had firmware to do scanning and motherboard had no keyboard controller. In AT and PS/2 era, the motherboard also had a keyboard controller with firmware, and by default the PS/2 scan code set is communicated between microcontrollers and the mothrboard controller maps the PS/2 scancode set to original PC/AT scancodes. In fact some part of the system does keep state as depending on Num Lock state you get slightly different scancodes for cursor keys, either with or without shift. – Justme Aug 15 '22 at 19:31
  • @Justme The NumLock-dependent stuff you mention is done inside the keyboard. The handling depends on the state of the NumLock LED, which is controlled by the BIOS or operating system. – Michael Karcher Aug 16 '22 at 11:58
  • @MichaelKarcher I know it's done inside the keyboard, but it does not apply to PC or XT keyboards, but AT or later. Hence the answer is technically correct, with PC and XT keyboards, all keys are equal and the keyboard has no concept of modifier keys. – Justme Aug 16 '22 at 12:08
  • @Justme: Did it even apply to AT prior to the 101-key keyboards that were intended to maximize compatibility with motherboards which had no concept of them? – supercat Aug 16 '22 at 14:32
  • 1
    @ supercat AT keyboard accepts commands from the host to control the LEDs, XT keyboard does not. the number of keys is immaterial. – Jasen Aug 18 '22 at 02:45
  • @Jasen: Yes, but so far as I know the original AT keyboard still had a 1:1 mapping between key press/release events and the bytes that it sent, and the keyboard+controller had a 1:1 mapping between key press/release events and the bytes seen by the application. It wasn't until the 101-key keyboards that the behavior of keys such as the arrows would be affected by the requested state of the Num-Lock LED. – supercat Aug 18 '22 at 15:35
  • @Jasen: BTW, I wonder whether there are any behavioral differences among keyboards in the situation where Num-Lock is held down for long enough to repeat, the state of the Num-Lk LED is changed, the key remains down for at least one more repeat interval, and then an arrow is pressed before the next Num-Lk LED status byte is received. An application that manually changes the state of Num-Lk may or may not register a repeat event as toggling the state, and so the keyboard would have no reliable way of knowing how the application would interpret a keypad key code. – supercat Aug 18 '22 at 15:39