>>> 2023-01-29 the parallel port

A few days ago, on a certain orange website, I came across an article about an improvised parallel printer capture device. This contains the line:

There are other projects out there, but when you google for terms such as "parallel port to usb", they drown in a sea of "USB to parallel port" results!

While the author came up with a perfectly elegant and working solution, on reading that article I immediately thought "aren't they just being an idiot? why not just use a USB parallel port controller?" Well, this spurred me to do some further reading on the humble parallel port, and it turns out that it is possible, although not certain, that I am in fact the idiot. What I immediately assumed---that you could use a USB parallel controller to receive the bytes sent on a parallel printer interface---is probably actually true, but it would depend on the specific configuration of the parallel controller in question and it seems likely that inexpensive USB parallel adapters may not be capable. I think there's a good chance that the author's approach was in fact the easier one.

I wrote a popular post about serial ports once, and serial ports are something I think about, worry about, and dream about with some regularity. Yet I have never really devoted that much attention to the serial port's awkward sibling, always assuming that it was a fundamentally similar design employing either 8 data pins each way or 8 bidirectional data pins. It turns out that the truth is a lot more complicated. And it all starts with printers. You see, I have written here before that parallel ports are popular with printers because they avoid the need to buffer bits to assemble bytes, allowing the printer to operate on entire characters at a time in a fashion similar to the electromechanical Baudot teleprinters that early computer printers were based on. This isn't wrong, it's actually more correct than I had realized---the computer parallel port as we know it today was in fact designed entirely for printers, at least if you take the most straightforward historical lineage.

Let's start back at the beginning of the modern parallel port: the dot matrix printer.

There's some curious confusion over the first dot matrix printer, with some Wikipedia articles disagreeing internally within the same sentence. In 1968, Oki introduced the Wiredot. The Wiredot is probably the first "dot matrix impact printer" (dot matrix thermal and dyesub printers had existed for about a decade before), but the title of "first dot matrix impact printer" is still often given to the Centronics 101. I have a hard time telling exactly why this is, but I can offer a few theories. First, the Oki Wiredot was far less successful on the market, seemingly only released in Japan, and so some people writing about printer history may just not have heard of it. Second, the Wiredot made use of an electromechanical character generator based on a permanent metal punched card, so it's arguably a different "type" of machine than the Centronics. Third, the Wiredot may have actually been more of a typewriter than a printer in the modern sense. The only photos I have seen (I think all of the same specimen in a Japanese computer history museum) show it mounted directly on a keyboard, and I can't find any mention of the interface used to drive it.

In any case, while the Centronics 101 is unlikely to be the first, it is almost certainly the first widely successful example of dot-matrix impact printing technology. Prior to the Centronics 101, the most common types of computer printers had used either typewriter mechanisms or chain-driven line-printer mechanisms. These machines were expensive (I have heard as much as $30,000 in 1970 money for IBM line printers), physically large, and very tightly integrated with the computers they were designed for. With the inexpensive and small Centronics 101, though, a printer was, for the first time, a peripheral you could buy at the store and connect to your existing computer. The dot matrix printer was to the line printer somewhat as the PC was to the mainframe, and a similar (albeit smaller) "dot matrix printer revolution" occurred.

This posed a challenge, though. Earlier printers had either relied on the computer to perform all control functions (somewhat like the inexpensive inkjet printers that became ubiquitous in the '00s) or had a high-level interface to the computer (such as an IBM mainframe I/O channel) and a large internal controller. These approaches kept printers some combination of computer-specific and expensive, usually both. The new generation of desktop printers needed a standardized interface that was inexpensive to implement in both the printer and the computer.

For this purpose, Centronics seems to have turned towards the established technology of teletypewriters, where the bits of each character were used to select an appropriate type matrix. The dot matrix printer would work very similarly, with the bits of each character directly selecting an impact pattern template from a simple character generator (unlike the Oki's metal plates, the Centronics seems to have used some type of ROM for this purpose). This was far easier if all of the bits of each character were available at the same time. While computers mostly used serial data interfaces for components, the extra hardware to buffer the bits into each byte (given that the printer had no other reason to need this kind of storage) would have been an expensive addition in 1970. Since ASCII was a 7-bit standard, there was an implication that any interface to the printer should be at least 7 bits wide.

Centronics was an interesting company to make a printing breakthrough. Effectively a division of Wang (best known for their CRT word processors), Centronics had originally built special terminals for casino cashiers. A major component of these terminals was a slip printer for receipts and account statements, and the Centronics dot-matrix impact head was originally developed as a faster, smaller print head for these slip printers. As sometimes happens with innovations, this new form of high-speed printer with simplified head (consisting of one solenoid for each pin and only 7 pins needed for acceptable quality) became a more interesting idea than the rest of the terminal.

Centronics was not a printer company, and did not have the expertise to develop a complete printer. To close this gap they entered a partnership with Brother International, the US arm of Japanese typewriter (and sewing machine) maker Brother, whose president incidentally lived next door to the president of Centronics. And thus came about the Centronics 101, with the print head and control electronics by Centronics and basically all other components by Brother based on their typewriter designs.

I go into this history of Centronics as a company both because it is mildly interesting (Brother printers today are more the descendent of the original Centronics than the hollow shell of Centronics that survives as Printronix) and because the general flavor of Centronics going into the printer business with a next-door neighbor makes an important property of the Centronics 101 more explicable: the choice of interface. Centronics was getting this printer together quickly, with an aim towards low cost, and so they stuck to what was convenient... and incidentally, they had a significant backstock of 36-pin micro-ribbon connectors on hand. This style of connector was mostly used in the telecom industry (for the RJ21 connector often used by key telephones for example), but not unheard of in the computer world. In any case, since there was no established standard for printer interfaces at the time, it was just about as good as anything else.

And so, largely by coincidence, the Centronics 101 was fitted with the 36-pin micro-ribbon (also called Amphenol or CHAMP after telecom manufacturers) connector that came to be known as the Centronics connector.

The pinout was kept very simple, consisting mostly of a clock (called Strobe), 8 data pins, and a half dozen pins used for printer-specific status information and control. For example, a Busy pin indicated when the printer was still printing the character, and a Paper Out pin indicated that, well, the paper was out. Control pins also existed in the forward direction, like the Autofeed pin that indicated that the printer should linefeed whenever it reached the end of the line (useful when the software generating output was not capable of inserting correct linebreaks). Since 36 pins is a whole lot of pins, Centronics provided generous features like a pull-up reference and a separate ground for every data pin, besides chassis ground and shield.

Let's take a look at the details of the Centronics protocol, since it's fairly simple and interesting. Centronics printers received data one character at a time, and so I will use the term character, although the same applies to any arbitrary byte. To print a character, the computer first checks the "busy" pin to determine if the printer is capable of accepting a new character to print. It then sets the character values on the data 0 through data 7 pins, and produces a 1uS (or longer) pulse on the "strobe" pin. This pulse instructs the printer to read out the values of the data pins, and the printer places a voltage on the "busy" pin to indicate that it is printing the character. Once completed, the printer pulses the "acknowledge" pin and resets the "busy" pin. At this point, the computer can send another character. A couple of sources suggest that the "acknowledge" signal is largely vestigial as most computer implementations ignore it and send another character as soon as "busy" is reset.

Critically, the Centronics interface was completely directional. From the computer to the printer were the data bus and several control pins. From the printer to the computer were four control pins but no data bus at all. Returning to my original inspiration to read about the parallel port, this suggests that a parallel controller actually can't be used to receive data from a printer output, because it is only capable of transmitting on the data bus.

Of course, reality is yet more complicated.

The Centronics interface we're speaking of here is strictly the interface on the printer, and especially in the '70s that bore only a loose relation to the interface on the computer. Most computers would still need a dedicated printer controller card and a variety of proprietary interfaces were in use on the computer side, with various cables and adapters available to make a Centronics printer work.

As with many things in the world of microcomputers, there wasn't really any standardized concept of a computer parallel interface until the IBM PC in 1981. The IBM PC included a parallel printer controller, but not one intended for use with Centronics printers---the IBM PC was supposed to be used with the IBM printers, rebadged from Epson, and the IBM PC's printer port wasn't actually compatible with Centronics. IBM chose a more common connector in the computer world, the D-shell connector, and specifically the DB25. Because there are only a limited number of practical ways to implement this type of printer interface, though, the IBM proprietary parallel printer protocol was substantially similar to Centronics, enough so that an appropriately wired cable could be used to connect an IBM PC to a Centronics printer.

And that pretty much tells you how we arrived at the printer interface that remained ubiquitous into the late '90s: an adapter cable from the IBM printer controller to the Centronics printer interface.

The thing is, IBM had bigger ambitions than just printers. The printer port on the original IBM PC was actually bidirectional, with four pins from the printer (used to implement the four printer control pins of the Centronics standard) available as a general-purpose 4-bit data bus. The IBM printers seem to have used the interface this way, ignoring the Centronics assignments of these pins. Even better, the original IBM PC was capable of a "direction-switching" handshake that allowed the peripheral to use the full 8 bit data bus to return data. This feature was apparently unused and disappeared from subsequent PCs, which is ironic considering later events.

The four printer control pins provided by Centronics were rather limited and more sophisticated printers had more complex information to report. To address this need, HP (which had adapted the Centronics interface nearly from the start of their desktop printers) re-invented IBM's simpler bidirectional arrangement in 1993. The HP "bi-tronics" standard once again made the four printer pins a general purpose data bus. Since the computer already needed the hardware to monitor these four pins, bi-tronics was compatible with existing Centronics-style printer controllers. In other words, it could be implemented on the PC end as a software feature only. All parallel printer interfaces capable of the Centronics standard are also capable of bi-tronics, as long as suitable software is available.

The lopsided nature of this arrangement, with 8 bits forward and 4 bits reverse, became an irritation to the new generation of computer peripherals in the '90s that demanded high bandwidths. Scanners and ethernet interfaces were made with parallel ports, among many other examples. To address this need, Intel, Xircom, and Zenith introduced the Extended Parallel Port or EPP standard in 1991. I would love to know which product from Zenith motivated this effort, but I haven't been able to figure that out. In any case, EPP was basically a minor evolution of the original 1981 IBM PC parallel port, with a more efficient handshaking mechanism that allowed for rapid switching of the 8-bit data bus between the two directions.

Because standards need friends, Hewlett-Packard and Microsoft designed the Extended Capability Port or ECP just a year later. ECP was actually quite a bit more sophisticated than EPP and resembled later developments like Firewire in some ways. ECP parallel ports were not only fully bidirectional but supported DMA (basically by extending the ISA bus over the parallel port) and simple compression via run-length encoding. This might sound overambitious for the '90s but it found plenty of applications, particularly for storage devices. Perhaps one of the most notable examples is the first generation of Iomega Zip drives. They were internally all SCSI devices, but SCSI controllers were not common on consumer machines. Iomega offered a parallel port version of the drives, which relied on a proprietary ASIC to convey SCSI commands over an ECP parallel port. ECP's DMA feature allowed for appreciably better transfer speeds. This setup is very similar to the modern UASP protocol used by many higher-end USB storage devices... SCSI is one of those protocols that is just complex enough that it will probably never die, just adapt to new media.

The parallel printer port remained only loosely standardized, with most supporting some combination of "standard" mode (also called SPP), EPP, and ECP, until, surprisingly, 1994. IEEE 1284 aimed to nail down the mess of parallel ports and modes, and while 1284 is superficially viewed as a standardization of the Centronics connector, it really does take on the whole issue. IEEE 1284 specifies five modes:

• Compatibility Mode, which behaves identically to the original Centronics specification. This is also called SPP for Standard Parallel Port.
• Nibble Mode, which uses the four printer control lines of the Centronics standard as a 4-bit data bus in the reverse direction, like the original IBM PC and printers.
• Byte Mode, which uses the 8-bit data bus for both directions with a simple handshaking arrangement to switch directions. Byte Mode is largely similar to, although not compatible with, the original IBM PC bidirectional feature.
• EPP, as specified by Intel/Xircom/Zenith
• ECP, as specified by HP/Microsoft

Because EPP and ECP both specify distinct handshake protocols, it's mostly possible for a parallel controller to automatically detect which mode a device is attempting to use. This has some rough edges though and becomes more unreliable when dealing with devices that might use the pre-EPP byte mode, and so most parallel controllers provided some way to select a mode. In modern motherboards with parallel ports, this is usually in the form of a BIOS or EFI configuration option that allows the parallel port to be set to SPP only, EPP, or EPP/ECP automatic detection. Usually this can be left on EPP/ECP, but some legacy devices that do not implement normal IEEE 1284 (and legacy EPP/ECP) negotiation may not be able to set up bidirectional communications without manually putting the controller in a more basic mode.

And that brings us to the modern age, with parallel ports via EPP or ECP capable of bidirectional operation at around 2Mbps. But what of my original reaction to the parallel printer emulation article? Given what we know now, could the author have just used a USB parallel controller? I suspect it wouldn't have worked, at least not easily. From my brief research, common USB parallel adapters seem to only implement the the unidirectional "compatibility mode" of IEEE 1284 and actually appear as character printers. More expensive USB devices with ECP support are available (routinely $50 and up!) as well as PCI cards. The IEEE 1284 spec, though, requires one of a few handshake processes before the port enters a bidirectional mode. I suspect it would require modification to the drivers or worse to read the presented byte without completing a negotiation to byte mode or EPP, which of course an older device intended only for printers wouldn't support.

There's a bit of a postscript about Centronics. As with many early technology companies, Centronics made a few missteps in a quickly moving market and lost their edge. Centronics partnership with Brother may have proven fatal in this regard, as Brother introduced their own print head designs and rapidly became one of Centronics chief competitors. Epson, Citizen, and Oki gained significant ground in dot matrix printers at around the same time. Centronics, no longer a market leader, was purchased by Control Data (CDC) to be merged with their printer business, CPI, itself formed through CDC's previous purchase of slip and receipt printer businesses including that of National Cash Register (NCR).

This was in the early '80s, and while dot matrix printers were still very common in that time period it was becoming clear that business and accounting users would be one of the dominant ongoing markets: perhaps the greatest single advantage of dot-matrix printers is that they were the superior choice for filling out pre-printed forms, for several reasons. First, dot-matrix print heads could be made very small and with an impact ink-transfer design could print on just about any material. This was highly advantageous for slip printers that printed on small-format preprinted media. These types of printers are no longer especially common except at grocery stores where they are often integrated into the thermal receipt printer and referred to as check endorsers, because they are used to print a "deposit only" endorsement and transaction reference number on the back of check payments.

Second, impact dot matrix printers use a formidable impact force and can effectively print on several layers of carbon or carbonless multi-part forms. This was very convenient in applications where a multi-part form was needed to transfer handwritten elements like signatures, although it has to some extend faded away as it has become more common to use a laser printer to simply print each part of a carbonless form individually.

Third, dot-matrix printers were so popular for form-filling applications that many featured built-in registration mechanisms such as an optical sensor to detect notches and, later, black bars printed on the edges of forms. This allowed the "vertical tab" character to be used to advance the form to a known position, ensuring good alignment of printed information with preprinted fields even with a feed mechanism that was prone to slippage. Of course many dot-matrix printers used non-slipping drive mechanisms such as perforated edge tapes, but these drove up the cost of the paper stock appreciably and users found tearing them off to be pretty annoying. Unfortunately, as dot matrix printers have faded from use, so too has software and printed media support for registered vertical tab. Purchasing a car a year or two ago, I chuckled at the dealership staff using the jog buttons on an Oki printer to adjust the form registration part way through a particularly long preprinted contract. The form had black bars for vertical registration and the printer model was capable, but it seemed the software they were using hadn't implemented it. The Oki printer in question was of the true "form filler" type and both fed and returned media from the front, making it convenient to insert preprinted forms to be filled.

Centronics did not last especially long under CDC ownership, and met a particularly odd fate. In 1987, Centronics, then under ownership of an investment bank, sold its printing business to competitor Genicom (now part of Printronix). The remainder of Centronics, essentially just an empty shell of a corporation flush with cash from the sale of its former operation, purchased kitchen goods and housewares manufacturer Ekco and renamed itself to that brand. Ekco, in some sense once a leading innovator in computer printing, is now a brand of measuring spoons manufactured by Corelle.

>>> 2023-01-16 huff-duff

We've talked a fair amount about HF radio recently, in the context of OTH radar. Recall that an extremely useful property of HF radio here is that HF frequencies can reflect off of the upper layers of the atmosphere, causing them to rebound towards earth at a range much further than the horizon. This behavior, called ionospheric propagation or (more commonly among radio operators) skywave propagation, is the best way to achieve radio communication over ranges much longer than line of sight, without the use of satellite relays. Since satellites didn't come onto the scene as an option until the '60s, for much of the 20th century HF radio was the major method used for long-range communications when no supporting infrastructure (such as microwave relays or a subsea cable) was available along the way. This included applications like long-distance phone calls and all contact with ships and aircraft at sea.

The history of HF radio and its many interesting military and intelligence aspects could fill a book, and probably will over time on this blog. I have mentioned, for example, HAARP. That of course means that ionospheric heaters and the military-intelligence mission of HAARP are now on my list of topics to address, along with the ubiquitous HAARP conspiracy theories. First, though, I had a reader email me in response to the OTH posts. They asked about CFS Masset: a Canadian Forces Station on Graham Island, off the west coast of BC and a good ways north of Vancouver Island. I've never been to Graham Island but it's on my list, and CFS Masset is one of the reasons. The CFS consists mostly of one of few operating examples of a fascinating artifact of HF radio and military intelligence: the CDAA or Wullenweber antenna.

First, we need to back up a bit and talk a little more about theory and practice of HF radio itself.

We don't talk very much about HF radio today, and there are good reasons why. HF radio requires high power levels and more complex (and expensive) RF electronics than higher bands like UHF. After the extra effort, the low frequencies of HF offer less bandwidth for a conventional channel and so allow only limited symbol rates. HF just isn't very convenient for our modern, data-centric applications like the cellular network that operate in UHF and SHF instead. HF has one big advantage, though, that keeps it in use today: propagation. HF radio is no longer used for general long-distance telecommunications because more reliable and higher bandwidth options are available.

There remains though a large class of users who want very long distance communications with minimal infrastructure: the military. HF radio equipment is widely deployed by militaries around the world, especially at sea. A particularly vivid example of military use of HF is the "numbers station," typically HF stations that broadcast long strings of numbers or letters as a means of clandestine communication with intelligence and military assets in hostile territory. Of course one of the things that makes numbers stations such a spectacle is the mystery: it is often unknown where they originate.

This gets at a major topic in military HF radio: direction finding. When military assets such as ships at sea use HF radio, it is theoretically possible to determine their position based on direction-finding the source of the signal. This is particularly appealing since HF radio is sometimes used by assets that are otherwise very difficult to locate, like submarines. The fact that even some numbers stations (which typically operate from fixed sites on land) still haven't been located hints that this isn't exactly easy, though. Propagation is a double-edged sword: complex atmospheric propagation of HF radio allows it to span vast distances, but it also means that HF radio signals usually arrive by different paths, through different propagation modes, and with very variable strength. This all makes direction finding of HF signals very difficult.

The problem is both difficult and important enough that HF direction finding, or HFDF (sometimes pronounced huff-duff), is sort of its own field within radio communications. The earliest HFDF focused on the use of receivers on aircraft that passed very near the transmitter (in radio terms, i.e. within the radio horizon) where propagation is not a factor and there is a clearer direction of origin. Indeed, the non-directional beacon (NDB) and corresponding radio direction finder (RDF) formerly used for aircraft navigation are basically a simple case of HFDF.

Unfortunately, this technique is not that widely applicable. When the source of an HF transmission is unknown over a very large area (e.g. a submarine) or in hostile territory (e.g. enemy command and control stations), it's impractical to get a direction finding receiver close enough to provide a single, unambiguous propagation path from the transmitter. Military intelligence units spend far more of their time scratching their heads at HF signals with no known origin other than "a long ways away."

The NSA, for example, has been heavily interested in this problem for just about as long as it has existed (dating back to the SIS in WWII). Indeed, one could make an argument that the challenge of HFDF is one of the main reasons that the NSA exists in its modern form. Well before modern signals interception from a huge range of media (including cables, satellite uplinks, etc), the NSA already needed a network of multiple collection sites, coordinated centrally by cutting-edge information systems, to attempt HFDF. The NSA continues to operate a set of clandestine "research sites" with extensive HF equipment.

The larger HFDF effort, by far, was that of the US Navy. The NSA was likely limited here by their relatively small budget (at the time) and need for a high level of secrecy. The Navy, though, critically concerned with locating enemy ships at sea, openly built an enormous infrastructure of HFDF stations. The secret to long-range HFDF, it turns out, is brute force: with multiple highly sensitive direction-finding receivers at widely separated locations, it becomes easier to determine probable sources by figuring out which strong source angles at different stations can plausibly meet.

The Navy's HFDF program, build during the 1960s, was directly based on research done in WWII Germany. Indeed, the ability of both the Soviet Union and the Allies to inspect Germany's highly advanced HFDF sites after WWII means that nearly the entire global military HFDF effort was directly based on the German work. This history is mostly to explain how the German code-name for HFDF research, Wullenweber, came to be a common name for the type of antenna the Germans developed. More generally, it is known as a Circularly Disposed Antenna Array or CDAA.

A typical Wullenweber or CDAA is an array of dipole antennas pointed in different directions. Practically speaking the easiest way to build a CDAA is by arranging the antenna elements in a circle, usually as a couple of rings of towers or frames supporting the dipole elements with a circular groundplane underneath. Many CDAAs have additional inner circles of reflector elements that improve directionality of the dipole antennas (rear and side lobe rejection). Because of the long wavelengths of HF (and the general principle that, to be efficient, an antenna's length must be a small integer division of the wavelength such as 1/4 or 1/2), the individual dipole antennas must be quite large. A fairly typical CDAA occupies a circle of about 1,000' across, with elements on towers as much as 150' tall. The large size and dense arrays of elements made "elephant cage" a common nickname for CDAAs.

The Navy's CDAA design is the AN/FRD-10. The FRD-10 was designed by the Naval Research Laboratory with the University of Illinois, and full-scale construction was contracted to ITT Federal. ITT is more widely remembered today in the form of for-profit university ITT Tech, but this form of ITT is almost completely unrelated to the original ITT: International Telephone and Telegraph. ITT started out as a telephone company serving Puerto Rico and through a series of acquisitions became a major conglomerate with extensive government contracts. ITT, in its heyday, was the kind of company that managed to be peripherally involved in multiple international scandals and coups. Since then ITT has sort of fallen into pieces, but some of those pieces remain major players in the defense industry, like the Harris part of L3Harris (not directly descended from ITT but made up in large part by several acquired ITT business units).

From 1959 to 1972 ITT built 16 FRD-10 sites for the Navy at a cost of around 20 million bucks a piece in 1970 dollars. A full FRD-10 with ground plane was right about 1000' across and 90' tall. It actually consisted of two separate CDAAs, tuned for higher bands and lower bands, colocated on the same center point. The inner low band ring contained 40 unit antennas aimed at 9 degree increments, and the outer high band ring (where more precise direction finding is theoretically possible due to the shorter wavelength) contained 120 elements at 3 degree spacing.

While physically impressive, the actual FRD-10 antenna was in some ways the more minor component of the site. Far more complex and expensive were the supporting electronics, including receivers and a computerized control and recording system. Because of the large number of unit antennas, it was not practical to install a receiver for each antenna. Instead, complex beam-forming networks were used to couple receivers to small subsets of antennas with phase-matching delays to achieve a very directional receive pattern. At the same time, the collective array of antennas was combined by another phase-matching network to produce an omnidirectional output used for receive strength comparisons.

FRD-10 sites were fitted with a complex switching network that allowed multiple independent operator positions to use the array simultaneously. These operators sat at "goniometers," a general term for angle-measuring devices, where they could turn a wheel to change the receive azimuth of their station and observe changes in reception. Operation was not all that manual, though: for clearer signals direction-finding was automatic. Several operators at each FRD-10 site were freed from turning wheels on manual goniometers and instead participated in a semi-automated system that was impressive for the era.

A "signal screener" monitored the omnidirectional output of the antenna for any signals of interest, and upon finding something good pressed a button that caused the computer control system to automatically inform other FRD-10 sites via an HF, SSB teletypewriter network. At the same time an automated direction finder determines the source of the signal and reports it to the network as well. As multiple stations located the signal, a computer system at the network control point compared the bearings from each site and reported a likely source location and confidence interval. An operator at this computer system manually reviewed each reported fix, and had the option of rejecting a fix, at which time the computer would wait to obtain more direction reports and improve confidence.

And now for CFS Masset: of the 18 AN/FRD-10 sites, most were located in the United States where they were initially designated as Naval Security Group Activities (NSGAs). For example, NSGA Homestead in Florida and NSGA Adak in Alaska (very near the never-constructed Alaskan OTH-B). For better precision, it is useful to have sites further apart. For this reason some AN/FRD-10s were installed in allied countries, like NSGA Hanza in Japan and NSGA Edzell in Scotland. Due to the unusually close relationship of the US and Canadian militaries, though, the two sites built in Canada are not US Navy sites like those other countries, but were fully operated by the Canadian Forces. These were CFS Masset on the west coast and CFB Gander in Newfoundland on the east coast (most notable for Gander, the historic dog, and certainly not for any peripheral events of 9/11 later rendered as insufferable musicals).

By the '90s, the relevance of the Navy's HFDF network was declining. The system was expensive to operate, the Cold War had spun down, and our major adversaries were making increasing use of satellite communications and avoiding HF transmissions. In the meantime, HFDF technology had improved and smaller, cheaper systems were starting to perform nearly as well as the FRD-10 (later Navy Security Group sites, for example, used the smaller AN/FRD-13 antenna which was lightly modified from a design by Plessey in the UK). The Navy began to decommission the AN/FRD-10 sites, and by 1999 only two remained in operation, the last two built (in 1972): CFS Masset and CFB Gander.

Indeed, the Canadian Forces continue to operate both AN/FRD-10s to this day. CFS Masset is now properly the Masset detachment of CFS Leitrim, a major Canadian Forces signals intelligence facility located across the country in Ottawa. The antenna at Masset is operated by remote control. While CFB Gander remains an active base, the FRD-10 itself there has similarly been made a detachment of CFS Leitrim.

The Navy was not the only user of the AN/FRD-10. The NSA itself built two, installed nearby each other at Naval Radio Station Sugar Grove (the location on a Navy installation was effectively a cover, the Naval Security Group that operated the rest of the Navy HFDF network had no involvement in these two antennas). Sugar Grove was closed entirely in the 2010s and has since been sold into private ownership.

Several similar systems were built by other organizations. The slightly earlier AN/FRD-9 CDAA antenna was used by the Army and Air Force. Because its mission was more focused on battle in theater than coastal defense, the AN/FLR-9s were mostly located in more exotic locations closer to the conflicts of the time: the Philippines, Thailand, and Turkey. Compared to the AN/FRD-10 the AN/FLR-9 covered a larger frequency range but was somewhat less precise. It met a similar fate, with all sites now inactive. Interestingly, the AN/FLS-9 was converted into an outdoor amphitheater (using the screening frames as part of the structure) for the Philippine Centennial International Exposition in 1998.

The AN/FLS-9 sites tended to be located in more remote areas and so more survive today. The AN/FRD-10, on the other hand, has suffered greatly from both urban expansion and weather. Most AN/FRD-10 sites were either demolished or collapsed in hurricanes, which the design turned out to not stand up to well. Today the Canadian sites are the only remaining examples of the AN/FRD-10 in North America and two of only three total, the third being in Panama. Still, a construction the size of a Cold War CDAA does not fade away easily. Nearly all of the AN/FRD-10s are still quite apparent in satellite images by the ground and vegetation disturbance. One example of a former AN/FRD-10 site is located in the San Pablo Bay National Wildlife Refuge, northeast of the San Francisco Bay area, part of which was formerly NSGA Skaggs Island.

Like OTH radar, HFDF is not dead but no longer requires the enormous facilities it once did. The Department of Defense continues to operate a mostly automated network of distributed HFDF stations, but it is now based primarily on compact portable equipment. Pretty much every large military deployed some type of HFDF, mostly using CDAAs, during the Cold War. In fact, the United States was if anything a latecomer. Besides the CDAA design having originated in Germany, the Soviet Union and United Kingdom built similar CDAA stations as much as a decade before the US. Most of these systems have disappeared like the AN/FRD-10.

True to their early involvement in the technology, Germany remains a relatively large user of the CDAA design. At least two CDAAs in Germany appear to be operational, one under control of the military and one under control of the intelligence agency BND. China, relatively new to the status of world power, is quickly catching up. The PLA constructed at least one CDAA just in the last few years.

One might wonder why there is still any interest in ground-based CDAAs, given the widespread use of signals intelligence satellites. I can speculate on at least two lines: first, with increasing military reliance on satellites comes the specter of ASAT or anti-satellite warfare. The resistance of satellites to attack is very poor and it is reasonable to believe that an adversary like China has the ability to eliminate a large portion of intelligence satellites relatively quickly, and this makes it appealing to have ground-based alternatives (a major reason I am a proponent of eLORAN, which I will write an article about one day). Second, efficient reception of HF requires large antennas. Satellites can rely on line-of-sight which mitigates the issue, and satellite builders have plenty of tricks for fitting large antennas into small launch envelopes, but still, space and weight on satellites is very costly. A ground-based capability can be faster and cheaper than a space-based one, which would be very appealing to for example China which does not have as much benefit of legacy capability and instead needs to field an all-new system quickly.

And there is some longstanding cultural and political impact of the era of HFDF. As I said, one could argue, or at least I would, that HFDF and HF propagation is key to the history of the NSA. Without the unusual demands of HF monitoring, the NSA would have had less motivation to deploy large signals intelligence stations in the United States during the Cold War. These NSA HF stations are the same stations that were later repurposed to satellite monitoring and programs like ECHELON. While I'm very much frustrated that the capabilities of programs like ECHELON and PRISM are often hysterically overstated by the media, they are nonetheless pillars of the modern surveillance state. Sure, they probably would have happened either way, but there would have been more friction without the history of HF interception.

HF radio has always gone hand-in-hand with signals intelligence. Indeeed, it's the reason that signals intelligence came into existence. Later, we'll dig into that a bit more: what if intelligence agencies could modify the ionosphere for their own purposes? Here in the US, the intelligence community built a tool to find out: HAARP.

>>> 2023-01-02 ANT plus is PAN for ants

One of the most interesting areas of modern consumer technology, to me, are low-power, low-range wireless networks. This category of network protocols were historically referred to as Personal Area Networks, or PANs. I say "historically" here because the term has never really had any use among consumers---I wager very few people on the street would be able to name a single PAN protocol, even though most people use one of them regularly. Part of the reason for this state of affairs is, of course, that there is only one PAN protocol that has achieved any real degree of success: Bluetooth.

Bluetooth exists in three major variants that are basically completely separate protocols, although all operate in the same band and are commonly implemented together in the same radio hardware. Bluetooth Classic is the evolution of the original Bluetooth protocol we have all known and loved^whated since the early '00s. Bluetooth High-Speed is a bit of a cheat, where Bluetooth Classic is used only for the initial negotiation, and then an 802.11 network substantially similar to WiFi Direct is used for the actual data transfer.

This might initially seem like a surprising degree of added complexity, but since Bluetooth and WiFi operate in the same 2.4GHz band and are usually needed in the same devices, it was already extremely common for the same chip to implement both protocols. When a need emerged for a higher-speed Bluetooth connection, it made sense to simply exploit that fact rather than reinventing the wheel. Bluetooth just takes advantage of all the work already done for high-speed 802.11, and the Bluetooth standards constrain this 802.11 pseudo-bluetooth to a degree that connection setup is usually pretty reliable. Much of the disappearance of WiFi Direct can be attributed to the fact that Bluetooth HS is basically WiFi Direct anyway, and had the backing of the large set of Bluetooth device vendors.

The third variant of Bluetooth, and the more interesting one for our purposes, is Bluetooth Low Energy or BLE. BLE was not originally Bluetooth at all, it was developed as a completely separate protocol called Wibree. Amusingly, Wibree itself was originally loosely based on Bluetooth and is nearly as old as Bluetooth itself. BLE could be viewed as a case of a spin-off R&D effort that was successful enough to be acquired back into the parent organization, but the process happened through industry associations and standards bodies and was thus a great deal more politically complicated.

The major difference between Bluetooth Classic and BLE is, as the name suggests, power consumption. BLE uses a simplified association model, lightweight network protocol, and an almost MIB-like (management information base, from the ISO protocols) approach to the application layer that minimizes the need for negotiation or setup processes. This all makes BLE amenable to applications where a device wakes up and participates in the radio network only occasionally and for a short period of time, which is great for battery-powered devices.

If you look at the table of BLE device profiles, you will notice a heavy slant in the direction of fitness trackers. Fitness trackers were one of the original motivators of low-power, low-bandwidth wireless connectivity. One of the early vanguards of this type of application was Nike+, launched in 2010. Nike+ consisted of a small module installed in a shoe, and then a receiver that could either be a standalone device or---most famously---an iPod with an accessory receiver. Nike+ used a simple proprietary protocol that, while its own unique branch of protocol design, is substantially similar to later fitness tracking approaches. It's possible that there's a direct relationship between Nike+ and later work like BLE, but I think it's more likely this is a case of convergent evolution. The requirements for a fitness-tracking wireless protocol are fairly straightforward.

Most fitness trackers track a small number of values and then report those at an interval. For an example that I am more familiar with, consider a bicycle. The most basic solutions measure only the RPM of the wheel, usually based on counting pulses from a hall-effect sensor. Somewhat more advanced products like Bontrager DuoTrap measure two pulse rates, the wheel and the crank. A more advanced product might also measure crank torque, getting you to three values, but in general the number of independent values involved in most fitness trackers is small and often only one. Heart rate sensors, for example, are a common class of low-energy, low-cost devices that report one value at a regular interval.

Typically the reporting interval is fairly low, with once a second being very common. The packet sizes are small since there are perhaps a few two-byte counters to report on the high end. In the interests of power saving and implementation simplicity, there's rarely a need for a connection-oriented protocol. As long as the tracking device has a unique ID that allows a receiver to differentiate it from other devices that might be nearby, there's not really even a need for two-way communications. The tracker can just broadcast the measured value each second. More complex receivers might have the user choose from a list of detected devices, but in most cases it's sufficient to use simple signal strength metrics to select the nearest device.

This all sounds delightfully simple, doesn't it? And like it could be far easier to interact with than the modern world of Bluetooth. Well...

WiBree, which became BLE, had a competitor. And a competitor that came directly from the fitness tracking industry, rather than from the broader alliance of mobile device vendors behind Bluetooth (one that has a huge interest in high-bandwidth audio as a primary use case). In 2003, Dynastream Innovations launched ANT. A few years later, Dynastream was acquired by Garmin Canada, giving ANT the imprimatur of a top fitness tracking brand. By 2010 or so ANT, in its 2004 variant ANT+, had become the most ubiquitous wireless protocol in commercial fitness equipment, and today we have basically all forgotten that it exists.

Let's talk a bit about the design of ANT+. It has general similarity and is partially a direct competitor to BLE, so it's probably easiest to discuss it in contrast to BLE. ANT+ is very slow, with perhaps 10 kbps as a typical achievable data rate (this depends somewhat on the network configuration in use). Unlike BLE (prior to 5.0 which appears to have gained a more sophisticated approach), ANT+ devices actively monitor channel usage in order to schedule an optimal time to transmit their payload. This allows a significantly larger number of ANT+ devices to operate in proximity than BLE.

ANT+ radios have extremely low power consumption, enabling ANT+ sensors to run off of a coin cell for an extended period, although BLE now achieves similar performance. ANT+ usually operates in a pure broadcast mode, but it does support reliable delivery when required.

The great thing about ANT+ though is the great simplicity of implementation compared to the Bluetooth stack. This isn't necessarily an inherent problem with BLE, but has more to do with the fact that BLE "sensor receivers" are usually devices with complete WiFi and Bluetooth stacks and so the degree of complexity that comes with managing multiple distinct Bluetooth modes. This isn't necessarily to say that BLE has significant usability problems on modern smartphones, it mostly seems to work very smoothly on modern devices besides Android's OS-level issues about whether or not BLE devices are associated as in a normal pairing relationship.

But the situation continues to irritate me. BLE is still saddled with a long history of Bluetooth standards with a high degree of diversity and user expectation of backwards compatibility. BLE is managed through complex operating system interfaces that are saddled with ideas from other Bluetooth variants and the history of Bluetooth on that platform. ANT+, as a protocol that is both new and very simple, manages to shed all of this complexity.

And that's why ANT+ remains popular today in high-turnover embedded applications, namely commercial fitness equipment. A lot of the cardio equipment you'll find in a modern gym has ANT+ built-in and will detect an ANT+ heart monitor in close proximity and use it instead of the integrated galvanometric heart monitor (the deal with the metal handgrips that tries to suss out electrical resistance changes resulting from your heartbeat from those resulting from the uneven contact of your sweaty hands and body thetans or whatever). This operation is completely association-free, rather the exercise equipment uses RSSI (signal strength) measurement to determine when such a tracker is reasonably close.

This surprisingly widespread support in fitness equipment is a victory for ANT+, but doesn't mean that much without larger consumer adoption. Anecdotally it seems like the number of people interested in purchasing an ANT+ heartrate monitor just for use at the gym isn't that large. So what of ANT+ in consumer devices? Well, it's kind of happened, almost...

Some Android smartphones have shipped with an integrated ANT+ radio, mostly from Samsung, which included ANT+ in pretty much all of their non-budget smartphones for over a decade. Unfortunately, it appears that the Galaxy S20 was the last in the series to feature ANT+. Across other vendors there's about 20 more models with ANT+ support, but all of them older. BLE has pretty much completely eliminated interest in ANT+ from the smartphone industry.

It's still pretty typical for cyclocomputers to have ANT+ support, and in general ANT+ has some ongoing adoption in the athletic industry, but it seems like the wind has gone out of its sails. Devices without ANT+ support can be made to work with a USB ANT+ adapter available fairly inexpensively from Garmin, but dongles have never really been popular with smartphones. As a result, a huge portion of ANT+ devices on the market simply also integrate BLE support... paving the way for BLE to replace ANT+ even for most people's existing equipment. The only thing that seems likely to remain a holdout for ANT+ is commercial fitness equipment in gyms, due to the more complex association process for BLE, but progress marches on and it seems likely that models with BLE support will appear nonetheless.

Now that I've lamented the death of ANT+, let's dig into the details a bit.

Like many short-range digital radio protocols, ANT+ is based on GFSK or Gaussian frequency shift keying. GFSK is essentially a variant of FSK that uses a Gaussian transform to "soften" the edges of the FSK symbols---which has the result of reducing the effective bandwidth of the signal, making more efficient use of spectrum. ANT radios use a very low power of perhaps 1mw, since they are intended for use only at a range of a few meters in most cases.

The ANT+ logical protocol is proprietary, but the interface to ANT+ chips is openly documented. ANT+ networks consist of a master node and one or more slave nodes [1], but these roles are not necessarily what you would expect. Since the master device establishes channel parameters and many ANT+ devices are low-power sensors that operate in a simple broadcast mode, it is not unusual for the sensor to act as master and the receiver (such as a smartphone) as slave.

There are a wide variety of configuration packets used to set up data channels, but once a data channel is established, but to facilitate simple passive devices a sensor can establish a data channel in broadcast mode by using a set of default parameters (e.g. "network ID 0"). Alternately, devices wishing to communicate with reliable delivery can exchange configuration packets to establish a channel in acknowledgment mode, which will have unique identifying values so that the channel can be uniquely tracked. A typical packet has a payload of 8 bytes, but the special bulk transfer mode (used mostly for transferring firmware updates) can use larger packets to increase the effective bandwidth. Overall the protocol is reasonably simple, and the specification PDF is openly available and only 134 pages (more than half of which is appendices).

To implement collision avoidance and thus allow many devices to coexist in close proximity, ANT+ operates on a cycle defined by the "channel period," which can have various values depending on the type of device in use. ANT+ devices monitor the RF channel in use for other packets, and if they observe packets from unrelated devices they will "phase shift" to transmit later in the channel period instead. For devices of like type, a very large number of devices can thus operate in the same channel and physical space without any collisions (once the avoidance process has "settled").

And that's some useless knowledge about a dying protocol.

[1] I use here the terms found in the ANT+ specification document.

>>> 2022-12-24 santa tracking

Let's talk about a different kind of radar: the one notionally pointed at the north pole. That's right, it's a Christmas post. I will keep it mercifully short, and follow up soon with the article I wrote most of today (not at all Christmas themed) before a tangent reminded me of this topic.

For decades now, NORAD, the North American Air Defense Command, has operated the "Santa Tracker." This service, ostensibly backed by NORAD's radar and satellite remote sensing, updates children on Santa's progress as he rounds the globe delivering presents.

Just as traditional now as the Santa Tracker are newspaper articles recounting its origin story. It generally goes like this: Sears ran a Christmas advertisement telling children to call a phone number to talk to Santa. They misprinted the phone number, so that it was actually the phone number for the "Red Phone" at NORAD, where a kindhearted Air Force officer had to improvise when the phone started ringing---not with news of impending doomsday, but with hundreds of children anxious to speak with an authority even higher than the Air Defense Command.

As tends to be the case with such popular stories, the version we hear today is arms length from the truth. From contemporaneous reporting, it seems the facts go more like this: The phone number printed in the advertisement was correct, but one particularly child misdialed. Instead of getting Santa Claus, they got the desk phone of Col. Harry Shoup, at what was then called CONAD. Shoup was reportedly gruff and ended the call quickly, only later realizing (due to a joke made by another NORAD employee, placing an image of Santa on a map board) that they could turn the incident into a publicity coup. That they did, and over decades the story has become more and more embellished to the favor of NORAD.

Obviously there is a cynical take on military public relations here, but it's a holiday, so let's focus instead on the more positive: telephone trivia.

There are elements of the well-known story that are clearly doubtful. The "red phone" for instance, with some articles saying the child called on a "secure line." Secure telephone lines, as a matter of definition, are either on separate secure telephone networks (such as AUTOSEVOCOM, the secure sibling of AUTOVON) or make use of cipher equipment that encrypts the via a method deemed sufficient for the purpose---typically by the NSA, which has historically preferred to stick to classified or "suite A" algorithms. A random child wouldn't be able to call a "secure line," either because they were not on the secure network or because they did not have the cipher equipment, depending on the type of secure connection.

In the time period of these events, 1955, cipher equipment was primitive but did exist. SIGSALY, the first functional secure voice encipherment system, entered service in 1943... but did require a room full of equipment and multiple operators. Most likely, a "secure line" at NORAD would be understood to refer to a NORAD-internal secure telephone network, likely the set of leased lines used to communicate with SAC bases. As a practical matter, though, the term "secure line" does not seem to have been in very common use until the 1970s introduction of the STU enciphered phone. The STU initially connected in cleartext "insecure" mode and then completed a negotiation before starting enciphered "secure mode," making the movie phrasing "is this a secure line" a real question someone would ask, necessary to confirm that the STU had successfully set up encryption.

What phone did some kid reach? The original Sears ad is easy to find. It was run by a Colorado Springs Sears location, which should be obvious considering it was a local call (long-distance toll free calling was not yet common in the '50s), and NORAD is located just outside of Colorado Springs, so the whole thing must have happened in that area. Still, very few news articles go beyond just saying "Sears."

The phone number in the ad is ME 2-6681. Remember that in the '50s, phone numbers were still commonly written using exchange names... but dialed using numbers, so that ME 2-6681 would be dialed as 632-6681. ME, the exchange name, could be short for a number of things. Since AT&T really set the numbers before they set the names, AT&T internally circulated a list of suggested exchange names that, for 63, included Medford, Melrose, Mercury, etc. In the case of Colorado Springs, it seems this phone number would have been read Melrose 2-6681, although the newspaper ad suggests the seasonally appropriate reading Merry Christmas 2-6681.

The nature of this phone number is a point of contention---the common version of the story is that this number is incorrect and actually goes to NORAD, but more reliable reporting from the time period suggests the phone number in the ad was correct and a child just misdialed. Besides the fact that the latter seems more likely, we can check newspaper archives to see if this number was ever advertised outside of the Sears incident. In fact it was. An advertisement in the Colorado Springs Gazette-Telegraph, 10 Oct 1960, lists the phone number ME 2-6681 for Walker & Co Realtor-Insurer. Walker & Co continued to advertise that same phone number through the '70s, but what of '55 when the original NORAD (CONAD) incident occurred? Unfortunately the newspaper archive I use doesn't have the Gazette-Telegraph prior to 1960, so I think we are left to speculate that Walker & Co likely picked up the phone number after Sears was no longer using it.

In any case, given that the child apparently misdialed a local phone call, it seems most likely that it was either the phone at Shoup's desk or at a watch desk he was manning. Given that he was a colonel at the time and not likely to be on rotating watches, I would imagine the phone he was in the habit of answering was the one in his office.

In the decades since the original '50s introduction of the Santa Tracker it has expanded into a massive phenomenon and perhaps the most successful single PR effort for the Air Force and, now, Space Force. It has taken odd turns from a particularly ostentatious collaboration with the Canadian Royal Air Force which reportedly intercepted Santa with an injured reindeer in 1958 to celebrity voice-overs by Aaron Carter in video versions of the tracker.

And all of this over a misdialed phone call. Well, that and fifty years of military propaganda.

>>> 2022-12-17 the keyboard controller

One of the more common arguments you hear in contemporary computer security circles is about hardware trust and embedded controllers. Technologies like Intel ME, the ARM Secure Element, TPMs, etc, remind us that the architecture of the modern computer is complex and not entirely under our control. A typical modern computer contains a multitude of different independent processors, some running relatively complete software stacks. They come from different vendors, serve different purposes, and are often unified only by opacity: for several different reasons, the vendors of these controllers don't like to discuss the details of the implementation.

It's tragic how the modern PC has put us into this situation, where we no longer have control or even visibility into the working of core, privileged components of our computers---components running software that could potentially be malicious. By the modern PC I do, of course, mean the IBM PC of 1981.

I don't want to belabor this post with much background, but if you are quite new to the world of computer history I will briefly state one of the field's best-known facts: for reasons that are ultimately more chance than logic, the original IBM PC established many de facto standards that are still used in computers today. "PC compatibles," in the 1980s meaning computers that could run software targeted originally at the IBM PC, had to duplicate its architecture rather exactly. The majority of modern computers, with Apple products as a partial exception, are directly descended from these PC compatibles and are thus strongly influenced by them.

Let's talk a little bit about the architecture of the IBM PC, although I'm going to pull a slight trick and switch gears to the 1984 PC/AT, which has more in common with modern computers. By architecture here I don't mean the ISA or even really anything about the processor, but rather the architecture of the mainboard: the arrangement of the data and address busses, and the peripheral controllers attached to them. The 80286 CPU at the core of the IBM PC had an 16-bit data bus and a 24-bit address bus. Together, these were called the system bus.

The system bus connected, on the mainboard, to a variety of peripheral devices. The RAM and ROM sat on the bus, as well as the 8254 timer, the 8259 interrupt controller (actually two of them), the 8237 DMA controller (once again, two of them), and the 8042 keyboard controller.

We are going to talk about the keyboard controller. See, there's something sort of interesting about these peripheral controllers. Most of them are purpose-built ICs, like the 8237 which was designed bottom to top as a DMA controller (actually by AMD, and used under license by Intel). The 8042, though, is not really a keyboard controller. It's a general-purpose microcontroller from the same product line used as a CPU in some early video game consoles. The 8042 on the PC/AT mainboard was simply programmed with software that made it function as a keyboard controller, reading scancodes from the keyboard, interrupting the CPU (via the 8259), and reporting the scancode read on the system bus.

The actual software on the 8042 is poorly known, and seemed to vary in its details from one model to the next (this is one of the things that could create subtle compatibility issues between ostensibly PC-compatible computers). In fact, the OS/2 museum reports that the software of the 8042 on the PC/AT itself wasn't dumped and analyzed until 2009-2010. And IBM, of course, was not the only vendor of 8042-based keyboard controllers. For decades following, various manufacturers offered keyboard controllers intended to replicate the function of IBM's own software.

These keyboard controllers were known to have a number of undocumented commands, the details of which depended on the mainboard vendor. And most interestingly, since they were general-purpose microcontrollers and had spare capacity after handling the keyboard, the 8042 in practice served as more of a general-purpose embedded controller. The term "keyboard controller" is a misnomer in this way, and it would probably be more accurate to call it an "embedded controller," but that term wasn't yet in use in the mid '80s.

The sort of miscellaneous functions of the 8042 are well-illustrated by the A20 mask in the PC/AT. Explaining this requires brief IBM PC backstory: the original PC used the 8086 processor, which had a 20-bit address bus. The 80286 in the PC/AT offered a 24-bit address bus, allowing it to address appreciably more memory (16MB as compared to 1MB). The problem is that the 8086 had a mostly accidental behavior in which memory addresses beyond the 20-bit limit (the details of this relate to the unusual addressing mode used by the 8086) would wrap back to zero and instead address early sections of memory. Some software written in the 8086 period actively exploited this behavior as an optimization, and some of that software was quite popular. Suddenly, on the PC AT, these just-past-1MB addresses actually referred to the new upper section of memory. Software that assumed it could address early memory by wrapping past the 1MB limit was in for a surprise---typically one that halted execution.

The 80386 would introduced "virtual" mode that addressed this problem by emulating the 8086 in a bug-compatible way, but the 80286 lacked this feature. To make sure that existing IBM PC software would be usable on the PC/AT, IBM introduced a trick to the architecture: the A20 gate. An extra logic gate on the motherboard would force the A20 line (the 21st bit of the address bus, due to zero-indexing) to zero, restoring the original "wraparound" behavior. For older software to run, the A20 gate should be "closed" for compatibility. To use memory beyond 1MB, though, the A20 gate needed to be "open" so that the second MB of memory could be addressed.

Anyone who has studied the boot process of modern computers knows that it is littered with the detritus of many generations of awkward additions. The PC/AT was sort of the genesis of this situation, as the 80286 introduced the concept of "real" vs. "protected" mode and the need for the operating system or bootloader to switch between them. Along with this came a less widely known need, to also manage the A20 gate. On boot, the A20 gate was closed. Software (such as an operating system) that wanted to use memory past 1MB had to open it. Given that the A20 gate was just a random bit of extra logic in the mainboard, though, how would software interact with it?

The answer, of course, is the keyboard controller. The 8042 could be sent a command that would it cause it to open the A20 gate. In fact, this wasn't the only role the 8042 served in the basic management of the processor. The 80286 couldn't switch from protected mode back to real mode without a reset, so for the computer to switch between real mode and protected mode dynamically (such as for multitasking with legacy software) something had to "poke" the reset line on demand. Once again, the PC/AT placed the 8042 keyboard controller in this role.

Over time, the 8042 tended to accumulate more roles. It handled the mouse as well in later computers with PS/2-type mice. It drove the PC speaker on some motherboards. Some early laptops used the 8042 for power management or display functions. None of these things were ever really standardized and often become a headache today.

Over time, the number of discrete components on motherboards has plummeted. The 8042 fell victim to this process fairly early on. On most PC-compatible computers, the 8042 gave way to the "Super I/O controller." This larger genera-purpose microcontroller combined even more functions, combining the serial, parallel, floppy, and keyboard/mouse controllers into one device that also handled auxiliary functions like fan speed control, MIDI/game port (different functions but for practical reasons usually packaged together), power management, and yes, the A20 gate and processor reset. The Super I/O is still more or less present in computers today, but it's usually referred to as the Embedded Controller or EC in modern architectures. The EC is often connected to modern processors over the LPC or "low pin count" bus, which amusingly is a somewhat modernized version of the original ISA expansion architecture on the PC/AT... long ago replaced by AGP, PCI, PCIe, etc. for most purposes.

That said, all of these terms are becoming somewhat irrelevant today. Modern processor architectures are pushing perpetually further into unified chipset designs in which progressively larger controllers of various names integrate more and more functions into one device. I learned about computer architecture in the days in which the "northbridge" and "southbridge" were the major active components of the system bus... but few computers today have discrete north and south bridges (or front-side and back-side buses for that matter), the functions of the two having been integrated into various combinations of the processor die and a large, monolithic motherboard chipset like the platform controller hub (PCH), with the functions of essentially all motherboard components put into one IC.

The 8042 thing all feels like sort of a hack, and indeed it was, but the PC and PC/AT (and PS/2 for that matter) architectures were full of such hacks. The IBM PC had a device we've mentioned, the PIC or programmable interrupt controller, that served to multiplex 7 different interrupt lines onto the processor's single IRQ pin. By the release of the PC/XT, all seven of those interrupts were in use on many machines, so IBM decided to get some more... by daisy chaining a second PIC onto the interrupt 2 line of the first one. In other words, interrupts 8-15 on a PC/AT (and subsequent PC compatibles) are in fact interrupts 0-7 on the second PIC. When the second PIC receives an interrupt, it forwards it to the first PIC by triggering interrupt 2, which then interrupts the processor.

Conventionally the keyboard used interrupt 1, so the 8042 was wired up to the interrupt 1 line of the PIC. The mouse, though, assuming a PS/2 mouse, used interrupt 12... reflecting the fact that the interrupt-capable mouse interface introduced on the IBM PS/2 was copied to the PC/AT, at the same time that the second PIC was added. In other words, the mouse is one of the things that they had run out of interrupts for. Of course today, we use keyboards and mice primarily via a polling strategy over USB.

This kind of hardware-level hackjob is not at all a thing of the '80s, and most modern systems still have plenty of it going on. Two of the most common cases are the need to reset the processor for various reasons and low-power modes, where something needs to wake up the processor... ideally something that consumes less power than keeping the processor awake. I am dealing with a microcontroller device right now, for example, where the embedded capacitative touch controller does double-duty to wake up the processor from deep sleep state on certain events. This allows the processor to shut off its own power, a huge savings considering the tiny draw of keeping the capacitative touch controller powered. It's oddly like the original 8042, taking some input controller that's a little more powerful than it needs to be and giving it some miscellaneous extra tasks.