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 of 1970. 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 very 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 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 we now call the Centronics interface.
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.
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.
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.
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.
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.