43

Long time ago I had an old IBM PS/2 that I had fished out of a dumpster. It ran IBM DOS 5.0 and was a solid little machine. Occasionally I would encounter the following scenario, and I recently started wondering what was going on internally:

Sometimes a program would hang, absolutely unresponsive to all user input with nothing on the screen updating (aside from the cursor blink, if it was in text mode). I would have to Ctrl+Alt+Del to reboot and get it running again. When the computer was in this state, keypresses would do nothing, until I had typed something like 5, 10, 15 (don't remember the precise number) keys. After the requisite number of keypresses, each keypress thereafter would cause the PC speaker to emit a short beep.

As a user, I understood the meaning to be "your actions are not productive, stop it." However nowadays I've been learning more about the way these systems worked, and it got me wondering what was actually happening inside. Presumably the program I was running at the time got wedged, either stuck in an infinite loop or blocked waiting for an interrupt that never came. Obviously the beep was not something the program itself was doing. And yet, to emit a beep, something in the system had to set the tone frequency in the Programmable Interrupt Timer and open the speaker output gate for a moment.

What was actually "counting" my keypresses? Did it have a full-fledged hardware input buffer, and for what purpose? What was actually responsible for controlling the speaker?

Improve this question
3
  • 2
    My friend once had a clone 386 motherboard that, if you held a key down line this, would emit a series of beeps of different pitch, in a vaguely musical manner.
    – Kaz
    Jul 19 '19 at 9:37
  • there are gold anwers here, thanks for asking!
    – John Balvin Arias
    Jul 20 '19 at 3:07
  • 1
    As I understand/recall, this did not happen if the machine was actually locked up (program not making forward progress after performing cli). It only worked under a soft-lockup where the executing software was in an infinite loop but interrupts were still enabled (which usually corresponds to Ctrl+Alt+Del still working).
    – R.. GitHub STOP HELPING ICE
    Jul 20 '19 at 19:58
62

Well, it was simply the BIOS' way to tell you that the keyboard buffer is all the way filled up.

What was actually "counting" my keypresses?

In so far as there is a 16 entry (32 bytes) buffer area to type ahead while the main program is still working on something else. So if 16 keystrokes come in without a single one being read, it's full and the beeping tells you that this key press went into nirvana :)

Did it have a full-fledged hardware input buffer, and for what purpose?

No, not really hardware, rather a software one with hardware support. Whenever a keypress happens an interrupt occurs, in which the BIOS takes the waiting keycode, translates it and stores it in the buffer. Later to be read by any foreground program (via INT 16h or DOS). So it is a hardware event, but the buffer itself is handled by some (quite small) software.

The reason is rather simple, the original PC was fricking slow, but intended to be used in an office environment where users were experienced in fast typing (like on a typewriter). So the keyboard buffer was a way to equal out when the program did need time for like a redraw (scroll) or insert or whatsoever.

The mentioned 16 entries are a compromise between usability and memory usage - after all, it was supposed to work the same way on a basic 16 KiB machine. Fast typers could still overrun it (not just when the machine was locked up). As a result, back then (with the original 4.77 MHz PC and PC XT), TSRs offering an extension to like 128 entries were quite common and well received.

What was actually responsible for controlling the speaker?

Again the BIOS. After all, controlling all basic I/O is what it's supposed to do, isn't it?

Improve this answer
7
  • 4
    That design is still there in Windows. When Windows is locking up and you hit the keyboard too many times, you get a nasty PC speaker beep.
    – Kaz
    Jul 19 '19 at 3:22
  • 6
    It's not really that the PC was slow - it just couldn't do two things at once. Electric typewriters were substantially slower than PCs, but they didn't do anything except for processing the keyboard input. Not to mention that a programming model of "loop, keep checking for key presses" was substantially easier to implement than an event-based model that would do something useful with the keyboard interrupt right away; even if you did write your own keyboard interrupt handler, you'd still use a buffer - it's an easy and quick solution that works essentially perfectly.
    – Luaan
    Jul 19 '19 at 8:23
  • 3
    Don't forget that the reason you hear the beep is the application cannot read the buffer fast enough - not having a buffer would make the same happen earlier.
    – Luaan
    Jul 19 '19 at 8:24
  • 1
    I think Doskey added a longer buffer. Fun fact: I wrote a TSR to convert English keystrokes to Hebrew characters (similar to the classic keybhe.com). But I incorrectly hooked BIOS int 16h instead of hardware int 9, and this meant that if there were keystrokes in the buffer, you could change their language before they were consumed. Fun times...
    – Jonathan
    Jul 21 '19 at 9:24
  • 2
    Having used a CP/M machine with a single character buffer which frequently lost characters when used with a modem and similar, this was a very nice improvement back then.
    – Thorbjørn Ravn Andersen
    Feb 16 at 12:01
17

There is a circular buffer which holds all your keypresses. The BIOS is always monitoring the keyboard and filling that buffer, even after some kinds of crashes. It is expected that MS-DOS or the application is going to eventually fetch some keypresses, but that wasn't happening. So as soon as the buffer filled up, the BIOS just wanted to warn you.

Most did a beep in that circumstance. Some BIOSes lit an LED or did nothing.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.