I don't know why, but I absolute adore these stories of "Why does this obscure thing operate in the obscure way it does?" answered by the primary source. They're fascinating glimpses into the never-ending sea of trade-offs that is professional engineering!
The comedic value of the IBM PC architecture and its myriad of cautionary tales cannot be overemphasised. From the keyboard controller controlling a short to the A20 line to the rather questionable choice of using a programmable timer to generate audio (BTW, what was used in the cassette port?) and the 6845 sync frequencies that would ruin (if not set fire to) an MDA monitor, all the way to write-only EGA registers and the TSRs that were needed to keep track of which video mode the screen was on, the list and its hilarity, is enormous.
I assume the IBM engineers who came up with these ideas had a lot of fun.
Maybe officially, but it's hard not to appreciate engineers getting away making the most idiotic, borderline surreal, technical decisions for multiple generations of a machine architecture. The PC must have been the most hated piece of hardware ever to be designed within IBM and the outlet of countless corporate-induced frustrations.
Most things that look crazy from the outside probably had very good reasons for existing. There's usual some weird technical quirk that made it work the way it does, and working around the problem (or doing it right) would have required a few thousand more gates or a couple more pins which would have been expensive.
Making something correct with no regard for cost is relatively easy. Making something that works at all but costs less than $5 in bulk can be a lot more difficult.
My point is, it's easy to get into this kind of weird design world, if you just do the quickest thing at every step, with no ability to think about how the big picture is going to look.
I'm sure nobody wanted to make a weird architecture, because they're harder to extend and harder to write software for, but if you always have the deadlines breathing down your neck, don't be surprised if you end up in a scary forest indeed.
Back in the day the Win32 Beep() function was a pretty effective tool for debugging certain multi-threaded and server tasks.
You set up uniquely pitched beeps for certain events, and then listen for the order in which the events occur. It worked because a call into Beep() halted the entire process and all of its threads for the duration of the beep. It prevents multiple threads from beeping at the same time, and it slowed everything down just enough so that you could pick up each individual event with your ear. It beat the hell out of staring at a massive log file.
This reminds me of a talk by two of the Nobel price winners in medicine this year (Moser couple). They, together with O'Keefe, measured brain activity in various parts of the brain. Before computer loggers and visualization was very viable, neuroscientists hooked the sensors up to speakers. So they sat and watched mice move in a maze, and listened to various parts of the brain "fire".
The listening is still being done today in experiments. An experienced neurophysiologist (in the particular field of single cell recordings) can distinguish the sound of an actual braincell firing, or groups thereof, from all surrounding noise. Which is sometimes more convenient than recording the signal, feeding it into rather complicated template matching algorithms and waiting for results. Especially since braincells might die while being recorded from, so you have to decide quickly.
I was initially surprised to find that Beep is still available in the latest .NET framework (in multiple forms) because it just seems so archaic, but I guess the most basic audio feedback can still be useful.
This brings back some memories, but not the ones everyone else seems to have: I'd spent several hours (at least) looking at MSDN docs, various DLLs on my system, and the contents of the Windows SDK trying to figure out how to get an old fashioned beep.
I finally ended up on Larry's blog and, as it seemed like he'd know how it all worked, asked him.
I was quite pleasantly surprised by his response, as I wasn't really expecting an answer, never mind such an in-depth blog post the next day.
Sun Microsystems hardware would halt processing to beep the console speaker for half a second; I worked on a military communications system whose throughout would throttle to nothing whenever a long series of beeps occurred. Wiggling the mouse was enough to flush the alerts:
and message processing throughput would return to normal. Operators in the field were trained to use the mouse for this purpose.
Edited to add: the programmers were aware of the problem, but there was a system level requirement that alerts must be audible and that's how Trusted Solaris worked until well into version 8.
FYI, the PC and XT shipped with the 8253, the AT shipped with the 8254. And the 8254 is actually in the southbridge nowadays. I wonder whether the cheap Win8.1 tablets still have the speaker connection to 8254.
Just pressed left shift five times to enable sticky keys on my Macbook running Windows 8 (native, no virtualization) and got no beeps. does anyone know if this has changed since Windows 7? I'm sure this generated a beep sequence in older versions of Windows.
That makes me remember way back as an intern when I turned our testing tool into a crude music player by using a table of note frequencies and a text file format based on sheet music to make Chopin's Etudes play over the PC speaker by calling Beep().
Some people might remember from really old DOS games, but... You can even use the PC speaker as a "soundcard" (Actually as a 1-bit DAC. Here's the function called a few thousand times per second when using the Linux audio subsystem, updating the 1-bit output to the speaker (timer control of this output is disabled in this operation mode, kernel config is CONFIG_SND_PCSP).
There was this one game I picked up off the shelf at Target wayyyyyyyy back in the day (likely around 1990-1992) that had printed on the box a selling point that you could hear music without a sound card. It used the pc speaker. And sounded horrendous.
Still can't remember what the name of the game was and had been trying to track it down the last few years to see if it was as bad as I remembered.
I just remember high color (S?)VGA rendered/scanned in graphics, a man who was visiting alien planets and battling monsters. My 386 at the time was too underpowered to make the game remotely playable.
It was also possible to record by sampling one of the parallel port pins. Lousy sound quality, but we manged to record a song and play it back over the speaker, and have it be recognizable.
Great suggestion, but a little late. :) At 19, no EE experience, and only a few months of experience with C, we barely knew what we were doing. We also managed to fry one computer by turning up the amplifier too high.
