That is a pretty awesome tour de force. Somewhere deep inside your computer is an (emulated) PC/AT trying to get out :-).
An interesting lesson about the use of 'beep' for the assistive technologies. I see those sorts of things in architectures which have grown up over time and I wonder whether or not you could know at the time "Hey we're using this weird thing, please deprecated at your earliest convenience" or if it was more "there I fixed it."
Compatibility at the GPIO level was so ingrained in the PC community early on (there was even a code name for it, "Is it FlightSim compatible?" which referred to Microsoft Flightsim, a game that tested the compatibility limits of clones.) So as a tenet to the community all sorts of hacks could be committed in its name. Something like "Well we can depend on this, if they changed it then it would break compatibility and they can't do that."
Also an interesting take on how much Microsoft has had to unwind in a compatible way over the years.
Finally, the Linux console used to beep the speaker this way (I have no idea if it still does) and sometimes when I lay there sleeping I would hear my server softly feeping, yes feeping on its console bell. Sadly it wouldn't stop until I got up and logged in and figured out what was complaining.
"So," say I, "what is the madness, The state of awful system sadness,
That would cause Linux such distress?"
After all, the days of yore, from which this reference came before, those days are long since gone.
Yes, the PDP is long since gone, and though it legacy carries on, the once-great HACTRN is no more.
So once again this begs the question, which I ask through my HN session, what did feep upon your console's bell?
--qwertyuiop924 (with apologies to The Great Quux (with apologies to Edgar Allan Poe))
there should be a rule for this: all great & powerful modern emotional things can be reframed to point back to some work of Edgar Allen Poe. whether hacker related or not. the only dependency is the human condition
The way I remember FlightSim (from first official PC clone presentation, compaq in 1982! https://www.youtube.com/watch?v=7THrlGIL9k0 ) was that it jumped directly to raw hardcoded pointers in the bios instead of calling interrupts.
Another "test" was WordStar? using DOS/BIOS CP/M compatibility layer (afaik the only software ever to do that?). There were also programs expecting MS basic in the rom.
> Also an interesting take on how much Microsoft has had to unwind in a compatible way over the years.
It's very much self-inflicted technical debt. From a Spolsky on Software article from 2004:
> Raymond Chen is a developer on the Windows team at Microsoft. He's been there since 1992, and his weblog The Old New Thing is chock-full of detailed technical stories about why certain things are the way they are in Windows, even silly things, which turn out to have very good reasons.
> The most impressive things to read on Raymond's weblog are the stories of the incredible efforts the Windows team has made over the years to support backwards compatibility:
Look at the scenario from the customer's standpoint. You bought programs X,
Y and Z. You then upgraded to Windows XP. Your computer now crashes
randomly, and program Z doesn't work at all. You're going to tell your
friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not
compatible with program Z." Are you going to debug your system to determine
that program X is causing the crashes, and that program Z doesn't work
because it is using undocumented window messages? Of course not. You're
going to return the Windows XP box for a refund. (You bought programs X, Y,
and Z some months ago. The 30-day return policy no longer applies to them.
The only thing you can return is Windows XP.)
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
> This was not an unusual case. The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1.
The Simcity case reminds me of Bryan Cantrill's talk on lx-branded zones: apparently, there was a bug in rpm which didn't touch Linux, because Linux wasn't doing things fast enough to trigger the condition. So there was some code added to check if the running program was rpm, and to pause it briefly if it was. Apparently the comment the people who wrote it left amounted to, "we wrote this, and even we feel dirty about it."
Well, an update is needed: the Windows testing team was huge. Now, if they remark at all a program has a problem, it will just be silently uninstalled during the next major Windows upgrade.
...That's actually worse. If a program has a problem, tell the user. Besides, the idea that things won't change has been firmly ingrained in Windows programmers' heads for years.
Heck, at this rate, we'll need WINE for Windows, so Windows can run apps for earlier versions of itself.
The answer to that question is a lot less obvious than one would expect.
Windows installation upgrades (hereafter "migration") have been blocking setup if a known-incompatible program[1] is detected during installation, telling the user to uninstall it prior to allowing the upgrade to continue.
For Windows 10, the goal was to make the migration process (which would take ~40 hours to gather/apply on a typical system from Vista -> 7, the same process takes 20 minutes to an hour on upgrades to modern 10 nowadays) a lot faster, and a lot more seamless, as to get as many users as possible on the latest OS release to reduce effort supporting other software versions[2] and such.
Of course, blocking the installation with a known-incompatible program would result in popping up to the user, say, 'hi, this update can't install until you uninstall this program. please do so!', and they of course will respond 'what update? I don't want to uninstall my program so you can install an update! [I don't trust this at all/I'll forget/...]', and therefore said update (which wouldn't just be from 7/8 -> 10, but also cross-build on 10 itself) would never get installed.
There is no sane way to ask the user, since this will reduce adoption of new builds further than what people not understanding/accepting Microsoft's POV on this will attempt by 'not upgrading'.
[1] A common case to cite is the deinstallation of the product 'Speccy', which, funnily, will cause a system crash in a kernel driver shipped with the product if said older version is later installed on the new OS version and run. Given the chance people will have odd ways to automatically start this, and that people's systems will instantly crash if run, it makes sense to block the installation on this product.
[2] I maintained a hobby product that worked with fringe cases in the OS for a long period of time, and over time as I moved to newer OS versions myself, I'd end up having a large amount of features break on downlevel systems due to depending on new implementations/refactors done in 8, 8.1 or 10 with regards to those components of the OS.
That's an "interesting" approach. Unfortunately, it is made worst by the fact MS laid off tons of testing engineers a few years ago, and now release clearly buggy versions of Windows. To add insult to the injury, it now does so (adding new bugs and new incompatibilities with perfectly fine programs) every few months...
It’s a quote from the HACTRN, the explanatory notes of which explains: “the TTY's bell […] on the CRT in the poem above is a particularly obnoxious flavor of "beep", […]”
Anyone else remember that driver that allowed the internal speaker to output wave sound?
I remember days of playing SimCity 2000 and Doom without a sound card, so it was just beeps and buzzes. Then one day I discovered that driver and started to enjoy small sounding wave sound
Not exactly that but a similar story for you. I was a huge dork in high school and figured out the sound API on my HP-48G which was just really a way to play a sound from the internal speaker at a frequency and duration. I programmed the first parts of Holst's Jupiter using my calculator and a friend's calculator. Man that was real fun to do. Created an API on top of that to simplify it to play notes at a certain length.
That calculator was amazing. Real nice programming environment there for a high school kid that didn't have programming everywhere like we do today.
I did something similar with an Arduino. I managed to get an okay Star Wars out of it.
As for calculators, my school unfortunately standardized in TI: You guys had RPL, we have TI-Basic, which is worse than actual BASIC. And our calculators cost more! (Second-hand, anyways, because let's face it, nobody buys their calculators new)
I like to think my TI-83+ from 15 years ago is still being used by some kid who bought it off some kid who bought it off some kid who's the guy that bought it off me when I finished college.
Yes, I remember, speaker.drv. there was also one for win 3.11. I have fond memories of squeezing Windows on a bootable 2M3.0 floppy with UC2 compression and ramdisk to use it on the dos machines in university
Searching for that filename returns some very nostalgic websites. Here's one[0], which refers to speaker.drv as a way to play audio in NCSA Mosaic. It links to SPEAK.EXE on ftp.microsoft.com; incredibly, the URL[1] still works. The page must be about 20 years old.
There were some DOS games that had that baked in. Here's one example from 1987 (!), that used CGA graphics. They couldn't really spare the processing power during the game itself, so they kept it for the intro and the main menu.
The first time I launched a game that played less beeppy sounds than usual on my PC without a soundcard, actually almost understandable words, I nearly had an heart attack because I knew very well this was impossible. I needed a few minutes to recover.
I remember building a resistor ladder DA converter and connecting it to the parallel port. Software like No$ gameboy emulator used it, and it was easy enough to write to the parallel port directly.
I still have the connector with the resistor ladder laying in a drawer down here. A parallel port plug with a audio connector coming out of the back. :) Good times.
Somewhat (maybe) related : another world from Éric Chahi used to support the pc speaker as sound output, and had digitized sound effects and voices (very low quality but still incredible).
The PC port of Pinball Fantasies could also play MOD music through the internal speaker fairly nicely. My personal favorite is still the "Magic Mushroom" disk, which played the audio part of an Air-O-Zone air freshener commercial, all in 360K. :)
hey. your story intrigued me, so i found it and hosted it somewhere more free. Its quite rare these days. It doesn't work in Dosbox on OSX unfortunately so I couldn't see it.
This is:
echo Magic Mushroom
Echo --------------
echo This Program was made by the R&D Team at
echo the Cleveland Corp. of Australia at Hendra
echo To turn 'Magic Mushroom off press any key
echo Bye,Bye,Bye
It may not work in dosbox, but mushroom.ovl is just raw 8-bit[1] linear audio sampled at 8kHz so you can load it up in your raw-audio-capable app of choice. On linux try "aplay mushroom.ovl", for example.
[1] Actually only 6 bits per byte are used; presumably this was done to improve decoding speed or something.
The result is 6 bits of resolution, along with a high pitched squeak during playback, depending on the output circuitry and speaker characteristics (it's less noticeable when a low-pass filter is added).
https://archive.org/details/msdos_Spelljammer_-_Pirates_of_R... had full music and sound effects through PC speaker. Very low quality, yes. But, it was amazingly close to the merely low quality audio of most PC games of the time even when you did have a sound card.
This 8254 mention made me curious. Does anyone know which other parts of the original PC hardware are still present in modern machines for compatibility? (Real mode in CPUs, A20, ...)
Back when I made that post I thought it was an 8253. But I checked the sources for the function that Beep.Sys uses to program the timer and it claims that it’s an 8254 so I went with the source code.
How hard would it be to use the chip? Not hard but now that Win7 has shipped, the number of machines with an 8254 that’s actually wired to something is going to dwindle to around 0. The machines will still have an 8254 (it’s on the SuperIo chip in every PC) but it won’t be connected to any hardware.
Yeah, saw a motherboard like this a couple of years back when I was helping a friend build a new PC. We couldn't get it to boot even to the BIOS and started looking for the POST codes. There weren't even pins to attach a speaker to, just nubs on the board. Nor was there any sort of LED indicator. I ended up having to read the POST codes using a multimeter. That was a fun day.
The SuperI/O is the part of the southbridge (which later became the ICH and nowadays is known as PCH) that implements the legacy ISA chips (RTC, 8042[1], 8254, 8257, 8259). It used to be separate, which was already an improvement over the separate integrated circuits of 30 years ago.
[1] nowadays the 8042 is mostly emulated in SMM because it needs to convert USB to PS/2.
Intel finally got rid of hardware A20 gating in Haskell. Real mode still exists, and iirc, the processor still defaults to it. You just can't jump into real mode from x64 mode, you need a virtualized environment in 32 bit mode to do that.
> You just can't jump into real mode from x64 mode, you need a virtualized environment in 32 bit mode to do that.
I think what you mean is the vm86 mode is not available in 64-bit protected mode (no hardware task switching and 64-bit IRET ignores EFLAGS.VM).
But you can jump into real mode from 64-bit protected mode by clearing PE and PG at the same time. There are a couple more chores to do (clear EFER.LME and CR4.PAE) if you want the real mode code to be able to enter 16- or 32-bit protected mode. This[1] is an example.
On first few AMD's original AMD64 microarchitectures, 16 bit segments (both vm86 and 16b protected mode) were not working when the CPU was in long mode. The fact that they do on many modern CPUs is one of the Intel's extensions to AMD64. Also this is the reason why 64b windows do not support NTVDM and 16b windows applications, while the current hardware can support that. Another of these backward compatibility Intel's extensions concern whether x87-style FPU instructions are valid in long mode 64b code segment.
This discussion is interesting, I had read earlier that long mode was a point of no return, I guess that's not true after all?
I guess no v86 mode still makes it a dealbreaker for NTVDM type applications. Nobody wants to go back to a windows 95 style OS where a 16bit application runs unprotected and can stomp over anything and bring the machine to a halt. (For example, in win95 you could run debug.com and overwrite the first blocks of physical memory with zeros, which would immediately crash everything since that's where interrupt vectors like the IRQ timer is stored)
Would it be possible to bounce from 64bit long mode to 16bit real mode with some trusted code that bounces on to a mini kernel in 32bit protected mode that hosts v86 16bit applications, and then back again?
Well a certain amount of it is emulated in SMM, but from the fact that its still possible to boot DOS on most modern machines, a lot of the core hardware is still there emulated or otherwise. I was just reading a review on the Asus X99-A II, board where they were talking about the super-io chip's PS2 keyboard port. And IIRC, a couple years ago someone (IBM IIRC) dared to ship a machine without an 8042 keyboard controller/emulation, and it failed to work in a ton of places (kgdb for one).
Frankly, I'm a little surprised at the hate for the couple thousand or so transistors required to support the set of 8253/8259/8250/8042/etc chips that form the basis of the original XT/AT. Especially given the love for all things ARM, which tend to implement their peripherals in a very 1980's way with simple fixed MMIO ports punched into the address map, but without the standardization that form the basis of PC/AT hardware.
And just to stay on topic, almost every single decent ATX/ITX board I've used in the last decade has a 4 pin PC speaker port. Including the skylake machine I built last night. Same thing goes for RS232 ports, which are still on the vast majority of decent PC hardware even if they don't have headers soldered on. The X99 in that review actually had the headers, and I owning the older version of the board actually have a cable plugged into it which I attach to assorted hardware for firmware/etc work.
> Especially given the love for all things ARM, which tend to implement their peripherals in a very 1980's way with simple fixed MMIO ports punched into the address map, but without the standardization that form the basis of PC/AT hardware.
Isn't that a source of flexibility, though? The fact that that stuff is not standardized and is instead hidden behind a hardware abstraction layer (the OS kernel) means that ARM systems get the freedom to drop the legacy interfaces and centralize the hardware abstraction where it belongs: in the kernel.
1) a specific kernel for specific hardware, there's no universal kernel like for PC and
2) lot of hope that the maintenance or support of that specific kernel is not going to be dropped as soon as the hardware ships out of the gates (which is the fate of many routers or android phones, which cannot be updated to newer OS releases).
It's possible the OP was talking about firmware development for embedded hardware (Arduino-scale devices), using the RS232 port on the X99 to communicate with the firmware. Lots of embedded hardware has a serial console hidden somewhere inside, and when debugging, it can be faster to add some printf equivalent calls or a new console command than to use a JTAG.
I think most motherboards actually still support all of these crusty old GPIOs in hardware, but on a SuperIO https://en.wikipedia.org/wiki/Super_I/O chip. One of these will usually hang off your southbridge/PCH via the Low Pin Count connector https://en.wikipedia.org/wiki/Low_Pin_Count, which was specifically designed as the compatibility interface for these things.
In a modern PC, almost none of these are used - why would anyone want to use the crummy old AT 24-bit DMA controller when you can use PCIe bus mastering - but they're there if want to boot into an old real-mode OS.
I recall being asked to look into a perplexing problem with some legacy technology a few years ago. An 80s era radio controller system was effectively some DOS software running on a DOS embedded board. The boards were dying from old age. Replacing them with modern industrial PC boards wasn't working as expected - the software wouldn't run. The techs had tried various methods of slowing down the hardware to match the software's expectations to no avail. After much probing about (all original source code was long ago lost - if it was ever available) I found the code was crashing inside something that looked like an RS232 driver. Specifically the software was using what was apparently an undocumented scratchpad register in the 8253/8254. The modern PC's hardware emulation didn't cover that (the data was always reading back as 0xff - enough of a problem to turn the delay_n_millisecs() type routine I think I was looking at into a delay_forever() routine). The lesson, as always, avoid undocumented quirks unless you have absolutely no alternative.
The beeper using ancient interface is also long gone. Nowadays, the HDA chip handles it most of the time. There is no reason except ancient compatibility to call into the beeper via the ancient interface.
Good luck using an AT keyboard today :P there are some USB converters.
Some motherboards that offer PS/2 connectivity (rare, mostly "gaming motherboards" for n-Key rollover fanatics) but I don't even know if that chipset would do AT.
I wish it were a lot less rare as few ps/2-usb converters are very good, especially with a Model M for some reason. I don't want to retire it, it's still in great condition, unlike the dozen or more other keyboards I've had that have died after a year or two.
I think I still have an old Silicon Graphics keyboard somewhere in the garage. Built like a tank, I'm pretty sure it would still work if I had a port to connect it to.
Most like the same things the rest of them do like SMBus, temperature sensors, fan control and voltage monitoring.
They also do the GPIO for various other features like resetting the bios or switching between different BIOS flash chips, more recently the LED controls on the newer motherboards and the error code segment display that is now used instead of the POST beeping sounds so you can actually know wtf is going on :)
Even if you _have_ PS/2 connectivity, good luck getting it work with legacy hardware. E.g. an original Model M kbd will not work with most modern PS/2 due to electrical limitations (can't remember if it's non enough volts or not enough amps)
Only a few PS/2 -> USB adapters are fully functional according to the PS/2 specification. I use an adapter from Sanoxy [1] with my Model M and it works superbly. I have read of other Model M enthusiasts using the same one.
...way back when, a lot of sound cards had a connector on the top which could be hooked up to your CD drive, so that the drive could play Red Book audio which would be sent (as analogue) to your speakers.
Clever me noticed that the pinout of the CD drive matched the pinout of the PC's internal speaker. Aha, I thought; I can connect it up so that the internal speaker noises come out through my sound system.
Turns out that full-voltage square-wave 5V, amplified and pushed through a set of decent speakers, is... slightly loud.
(I was actually lucky not to damage the speakers. Or have a heart attack.)
The big problem with Beep(), or so did thirteen-year-old me think, was that unless you were on Windows NT it ignored the arguments, always producing a sound with the same frequency and duration. It meant that, despite it seeming like a straightforward replacement, you couldn't really use Beep() to port MS-DOS code that relied on Borland Pascal's CRT unit [1] to produce sound effects with the PC speaker.
Another problem of using hardware beeper is that when you are using a terminal, you may not hear the beep from the motherboard (which may be located in the next room or even miles away)
>It turns out that they couldn’t. And the answer to why they couldn’t came from a totally unexpected place. The American’s with Disabilities Act.
I wonder how much this act has cost society. Just in this particular instance, let's say keeping this chip on PC motherboards adds 5¢ to the cost of each motherboard. Multiply by a billion PCs sold in the last 10 years (The actual number is higher, but maybe some don't have the chip. Macs and stuff.). Did having the PC beep provide $50M worth of utility to society over the last ten years? I doubt it. $50M of research into e.g. sight restoration technology would also likely have been more useful to blind people in general.
You're making lots of wrong assumptions and insulting remarks here.
This act is not just about 'blind people', but people with all kinds of disabilities. If you read the article, you'll see that Beep() API is used for assistive technologies, which can be anything, from devices for motor impairment to deafness. Not everyone who is disabled is blind.
If this API would have suddenly disappeared the 'cost to society' would have been much higher than the assumed figure of $50M that you're stating here. Imagine if you'd wake up one day and your mouse doesn't work anymore because it's no longer compatible. That's how important assistive technologies can be to disabled people.
Furthermore, the suggestion that blindness can be 'fixed' by donating $50M to 'sight restoration technology' (whatever that is) grossly underestimates the complexities and variety of sight related disabilities. Vision is not a switch you can turn on again with an operation.
I'm well aware of the ADA and its effects. There was recently a good report about legal trolls suing small businesses for minor parking space violations under the ADA, so I took the chance to refresh my memory on the act.
>Imagine if you'd wake up one day and your mouse doesn't work anymore because it's no longer compatible.
Huh? This analogy doesn't make any sense. Things aren't compatible because of the ADA; they're compatible thanks to standards bodies and market pressure.
> That's how important assistive technologies can be to disabled people.
Only a small fraction of people need the beeper, and from what I understand based on a presentation from a deaf coworker a few years back, the best assistive technologies are those that emerged naturally, not from archaic ADA-imposed requirements. She cited OS X's accessibility features.
>Vision is not a switch you can turn on again with an operation.
I'm aware. I never said $50M in research would cure blindness; I said it would do more for blind people than a little beeper in the PC chassis. $50M is also quite a conservative estimate.
Nowadays that's not an actual chip anymore, but part of another (probably the superio that handles tons of legacy pc stuff in one chip). However it nevertheless needs dedicated hardware, in the form on a trace or a wire going to a more proper sound subsystem (or even a dedicated buzzer)
An interesting lesson about the use of 'beep' for the assistive technologies. I see those sorts of things in architectures which have grown up over time and I wonder whether or not you could know at the time "Hey we're using this weird thing, please deprecated at your earliest convenience" or if it was more "there I fixed it."
Compatibility at the GPIO level was so ingrained in the PC community early on (there was even a code name for it, "Is it FlightSim compatible?" which referred to Microsoft Flightsim, a game that tested the compatibility limits of clones.) So as a tenet to the community all sorts of hacks could be committed in its name. Something like "Well we can depend on this, if they changed it then it would break compatibility and they can't do that."
Also an interesting take on how much Microsoft has had to unwind in a compatible way over the years.
Finally, the Linux console used to beep the speaker this way (I have no idea if it still does) and sometimes when I lay there sleeping I would hear my server softly feeping, yes feeping on its console bell. Sadly it wouldn't stop until I got up and logged in and figured out what was complaining.