Welcome to the deep dive. And before we jump
into the actual material today, I was looking
over the directory metadata for this session.
Oh, yeah. Yeah. And it perfectly sets the stage
for what we're going to be doing today. Like,
if you were searching for this, the title you'd
see is the deep dive, decoding ISO 2047 and the
hidden language of computer terminals. That is
quite the mouthful. It is. But the description,
it captures the essence of our source material
perfectly. It reads. Ever wonder what happens
behind the screen when you hit backspace or hear
a computer bell? Right. In this deep dive, we
explore the fascinating, outdated world of ISO
2047, the 1975 standard for graphical representations
of 7 -bit control characters. From Teletype Model
33 quirks like WRU, who are you, to the obscure
visual symbols used for debugging early tech,
we unpack the hidden codes that built modern
computing. It really hits all the marks. It does.
And we've got all those target SEO keywords woven
in there, too. ISO 2047, computer control characters,
seven bit coded character set, tech history,
teletype model 33, ASCII debugging, graphical
representation of control characters, legacy
computing, Unicode control pictures. The works.
Covering all the bases. Exactly. But beyond the
metadata, the core question we are exploring
today is something most of us won't, you know,
we just never think about it. We take it completely
for granted. We really do. When you, the listener,
type on a keyboard today, the feedback loop is
instantaneous. It's visual. Very tangible. Right.
You press the letter A, and a luminous A appears
on your screen. But what happens when you press
a key that tells the computer to do something
completely invisible? That's the million dollar
question for early computing. How do you visualize
a command that simply says, start a new line,
or acknowledge this message? You've hit on a
fundamental problem of early computer engineering
there. We are essentially talking about the translation
of functional mechanics into a visual language.
Right. And in the early days of computing, that
translation was quite literal. I mean, you couldn't
just trust that a machine received an invisible
command. You had to see it. You often needed
to prove it physically. Yes. And that necessity
is exactly what brings us to our sole source
for today's discussion. It's a Wikipedia article
detailing ASO 2047. Which is an incredibly dense
read. It is not a narrative at all. If you pull
up this article, it is just a dense, incredibly
bureaucratic table. Just a wall of text. A wall
of acronyms, hexadecimal codes, and geometric
shapes that honestly, they look like alien hieroglyphs.
They really do. But the premise here is that
this dry table is actually a blueprint. a blueprint
of early digital communication. It's a catalog
of invisible forces. That's a great way to put
it. So to start at the absolute foundation here,
what exactly was ISO 2047 trying to solve back
in 1975? Well, to understand the solution, you
really have to understand the specific hardware
environment of the mid -1970s. OK, set the scene
for us. We're talking about the era of terminals,
specifically video display terminals, or VDTs.
And they're electromechanical predecessors, like...
Teleprinters. The loud clunky machines. Exactly.
So ISO 2047, which was published by the International
Organization for Standardization, is formally
titled Information Processing Graphical Representations
for the Control Characters of the 7 -bit Coded
Character Set. Quite the title. Very dry. But
its entire purpose was to assign a printable,
visible picture to a command that is inherently
unprintable. But why? I mean, why would you want
to print an unprintable command? If I press backspace,
I want the cursor to move backward. I don't want
a picture of a backspace to appear on my screen.
And normally, yes, you wouldn't. But think about
what happens when something breaks. OK. Imagine
you are a systems engineer in 1975. You've got
this massive mainframe in one room, and it's
communicating with a terminal down the hall over
a noisy analog telephone line. So lots of static.
Lots of potential for errors. Endless potential
for errors. The terminal keeps crashing or printing
garbage characters. You need to look at the raw
stream of data coming over that wire to see what
the mainframe is actually sending. Right, so
you put it in a diagnostic mode. Exactly. But
here's the catch. If you just send the raw data
stream to the terminal to display... The terminal's
hardware is just going to interpret those control
characters. Oh, I see. If the mainframe accidentally
sends a clear screen command because of line
noise, your terminal clears the screen. So you
lose the very evidence you were trying to examine.
You lose the evidence. So engineers built a monitor
mode or a transparent mode into these terminals.
How does that work? In this mode, the terminal's
character generator, the internal circuitry that
maps a binary code to a pattern of pixels on
a screen or pins on a print head, it bypasses
its normal instructions. It stops obeying the
commands. Right. Instead of executing the control
character, it looks up a special table and draws
a symbol on the screen representing that character.
ISO 2047 was the international agreement on what
those specific symbols should look like. It also
established standard two -letter abbreviations
for every single command. Just to ensure there
was zero ambiguity when engineers were talking
to each other. Precisely. No guessing involved.
It's kind of the equivalent of a mechanic taking
the cover off an engine. to watch the valves
move rather than just listening to the car run.
You have to expose those hidden mechanics. That's
a perfect analogy. But the source material indicates
this didn't just spring out of nowhere in 1975.
The timeline in the article shows a much deeper
lineage. Right, it does. Standardizing a global
visual language takes a lot of time. I can imagine.
The Wikipedia text explicitly notes that the
graphics and the two -letter codes formalized
in ISO 2047 were essentially carried over, completely
unchanged, from much older standards. Really?
How old? The primary ancestors are a European
standard from 1968, known as ICMA 17, and an
American standard from 1973 called ANSI X3 .32.
1968, let's just... ground ourselves in that
year for a second. It's early. That is incredibly
early in the timeline of widespread data communication.
We are talking about the Apollo program era here.
Yes. The fact that the European Computer Manufacturers
Association, ECM, was already recognizing the
need to draw pictures of network control codes
in 1968. Yeah. I mean that tells me data networks
were already getting way too complex to troubleshoot
by merely guessing what was going wrong. Oh,
the complexity was scaling incredibly rapidly.
In the late 1960s, you were transitioning from
isolated mainframes running batch jobs to time
-sharing systems. Where multiple users are accessing
a central computer at the same time. Exactly.
Via remote terminals, you suddenly had data streams
intermingling, complex routing codes, and constant
communication handshakes. The margin for error
must have been high. Very high. And the cost
of computer time was astronomical back then.
If a batch job failed because a single control
character was corrupted, you wasted thousands
of dollars. Wow. Establishing a unified diagnostic
language wasn't just an academic exercise for
these guys. It was an economic necessity. And
that necessity clearly resonated globally because
the article lists the different national adoptions
of this standard. And it kind of reads like a
roll call of the emerging tech powers of the
late 20th century. It really does. It mentions
the standard was adopted in China as GBT 3911
1983. In Korea, it was KSX1010, which the source
notes was formerly known as KSC5713. And in Japan,
it became JISX0209 in 1976. That geographical
spread is crucial to understand. Computing was
ceasing to be purely an American or European
domain. Right. For an IBM mainframe in New York
to eventually communicate with a terminal in
Tokyo, the foundational layers of how data was
structured and how errors were visualized had
to be identical. It's the digital equivalent
of agreeing on international maritime flags.
Exactly. A universal language for ships passing
in the night, or in this case, packets of data.
But there's a specific detail about that Japanese
standard and the source that really caught my
eye. It says JISX0209 .1976 was officially abolished
on January 20, 2010. January 2010. That is quite
a late date for something rooted in 1960s terminal
debugging. It is incredibly late. Right. I mean,
by 2010, the iPhone had been out for three years.
We were firmly in the era of high -definition
touch screens and cloud computing. Yet somewhere
in the Japanese industrial standards bureaucracy,
a committee finally looked at a document detailing
how to draw tiny geometric shapes for 7 -bit
teleprinter codes and decided, yep, it's finally
time to take this off the books. It speaks volumes
about the concept of technical debt and just
the sheer inertia of infrastructure standards.
Once it's in print, it stays in print. Well,
when a standard is embedded into the firmware
of millions of devices worldwide, you can't just
unpublish it because it feels old. Good point.
There might be a shipping company or a banking
back end somewhere still utilizing a legacy system
that references that specific 1976 document for
compliance. Right, some dusty server rack in
a basement. Exactly. Standards bodies are notoriously
conservative, and rightly so. They only abolish
a standard when they are absolutely certain its
removal won't cause a catastrophic ripple effect
in legacy systems. So if the Japanese standard
was abolished in 2010 and the source notes that
the graphical symbols of ISO 2047 are generally
considered outdated and rare today, what replaced
them? That's a great question. If a programmer
today needs to look at a raw data stream and
spot an invisible control character, how do they
do it without these specific geometric symbols?
The need to debug data streams definitely hasn't
gone away. but our displays are no longer constrained
by low -resolution character generators. We have
millions of pixels now. Right. Modern tools typically
rely on text -based representations. The source
mentions two common methods. First, the ISOIEC
646 three -letter abbreviations. Okay, what does
that look like? So instead of drawing a strange
symbol for the escape command, a modern text
editor in debug mode will simply display the
letters ESC in a little colored box. Oh, that
makes total sense. Much more readable for a modern
programmer than trying to memorize abstract shapes.
Precisely. You don't have to consult a manual
to know what ESC means. The other common method
mentioned is carrot notation. Carrot notation.
Yes. This is highly prevalent in Unix and Linux
environments. You use an upward pointing carrot
symbol followed by a letter. I've seen that.
For instance, the escape character, which is
the 27th character in the ASCII table, is represented
as carrot bracket. A line feed is carrot J. Carrot
J. It's a shorthand that maps the invisible control
codes to the visible alphabetical keys on a standard
keyboard. So we traded custom geometry for practical
typography. We did. It's much more efficient.
But for the duration of this deep dive, I want
us to live in that era of custom geometry. I
want to look closely at the logic of these glyphs.
because they are an incredible window into how
engineers conceptualize data when data was still
a very new concept. It's a fascinating way to
look at it. Let's look at the very first entry
in the standards table, hexadecimal 00. Hex 00,
the very bottom of the 7 -bit architecture. A
common abbreviation is NUL. The full name is
simply null. Yes. Now the concept of null is
philosophically interesting before you even get
to the computing part. Very true. It's not a
space. A space is a tangible thing. It moves
the cursor forward. Null is the absolute absence
of value. But how did that actually function
in early hardware? Well, in the context of the
early punched paper tape systems, which were
heavily used for data storage and terminal input,
Null was incredibly literal. Literally nothing.
Exactly. A paper tape represents data by punching
holes in a row. A seven -bit code meant there
were seven possible positions for a hole across
the width of the tape. OK, I'm picturing that.
For the NUL character, the punch mechanism simply
didn't fire. A row with absolutely zero holes
punched in it was a null. So it was just blank
tape? Just blank tape. Why would you need to
send blank tape? What's the point of sending
nothing? Primarily for mechanical timing. Mechanical
timing? Remember, these were heavy, physical
machines. If a command told the teleprinter's
heavy metal carriage to return to the left margin,
that physical movement took a fraction of a second.
Because it's a heavy piece of metal flying across
the machine. Right. If the computer kept sending
text data during that fraction of a second, the
letters would print randomly across the paper
as the carriage was flying backwards. Oh, wow.
It would just streak across the page. It would
be a mess. So the computer would send the carriage
return command and then immediately send a stream
of null characters. I see. The tape reader would
read the blank tape, do absolutely nothing, and
effectively buy time for the mechanical carriage
to finish its journey. Null was a digital pause
button. That's a brilliant way to frame it. A
digital pause button. button? Yeah. But here
is the challenge for the ISO 2047 committee.
How do you draw a picture of a pause button?
It's a paradox. How do you visualize nothingness?
According to the table, the official symbol they
chose for NUL is a tiny empty box. U plus 2395
in modern Unicode. And the official two -letter
abbreviation is NU. An empty box is a very pragmatic
solution, really. And if you want to show that
a character space is occupied by a command that
does nothing, you have to provide a boundary
for that nothingness. Right, because otherwise
it's just blank space on the printout. Exactly.
If they just left it blank, the debugging engineer
wouldn't know if the system received a null,
a space, or if the printer simply dropped a character
due to a fault. That distinction is critical
when you're debugging. It is. The empty frame
proves the character was successfully received
and categorized as empty. It's proof of abscess.
That's so clever. But standardizing these symbols
wasn't always a clean, logical process. Far from
it. We see evidence in the source that there
was friction and debate over how to represent
certain concepts. There's a very specific, almost
tedious footnote regarding the character at XO5.
The inquiry character. Ah, yes, ENQ. The common
abbreviation is ENQ, and its primary visual glyph
in ISO 2047 is a cross shape. It looks very similar
to a Maltese cross. That's right. But the footnote
points out that the standard also provides a
fallback glyph. If you couldn't draw the cross,
you were allowed to use a box with an X inside
it. Yes. And here is the fascinating historical
wrinkle. The older 1968 European Standard, Irene
17, only listed that box decks. It didn't feature
the cross shape at all. That seemingly minor
detail is actually a massive clue about how standard
-setting bodies function. Between 1968 in Europe
and 1975 on the global stage, a debate occurred.
But why do you think they felt the need to change
it? A box deck seems perfectly clear. It means
Hey, look here. We have to speculate slightly
based on the hardware constraints of the time,
but the most likely culprit is visual clarity
on low -resolution displays. Visual clarity.
Think about it. A boxed X requires drawing a
square and then drawing diagonal lines through
it. Yeah. On an early dot matrix screen, which
might only use a 5 pixel by 7 pixel grid for
a single character, drawing a box with an X in
it often results in a solid, unreadable smudge.
Oh, because the pixels just bleed together. Exactly.
You don't have enough resolution to render the
distinct lines. A distinct cross shape, however,
requires fewer pixels and relies on stark horizontal
and vertical lines. Which CRT monitors handle
much better. Much better. It's just easier to
draw on a primitive screen. So the global committee
probably realized the European design was too
complex for cheap hardware. But they couldn't
just delete it. They couldn't. You can't just
invalidate the older European standard entirely
because there was already hardware out in the
field manufactured between 1968 and 1975 that
used the boxed X in its ROM chips. So you'd break
compatibility if you just erased it. Exactly.
So the ISO committee compromises. They promote
the clearer cross -shape to the primary status,
but they enshrine the boxed X as an official
fallback to ensure backward compatibility. That's
amazing. It's a bureaucratic fossil preserved
right there in the standard. It really emphasizes
that these aren't laws of physics we're looking
at. They are human agreements subject to all
the messy realities of hardware manufacturing
and committee negotiations. Completely. Let's
move deeper into the table. If null is about
nothingness, the next cluster of characters we
see is intensely structural. I look at this block
of codes and I see the absolute necessity for
rigidity in early networking. We're talking about
Hexo V1 through Hexo 4 now. Exactly. Let's look
at those. These are the communication control
characters. They manage the flow and structure
of the data payload. At Hexo 1, we have SOH or
Start of Heading. Start of Heading. Hexo 2 is
STX Start of Text. 0x03 is ETX, end of text,
and 0x04 is EOT, end of transmission. When I
see these, I immediately think of how we use
the Internet today. If I send an email, I just
type the message, hit send, and I never think
about how it gets there. It's seamless for the
user today. But these codes suggest that in the
1970s, the application, or even the programmer,
had to manually build the envelope for the data.
That's a very accurate analogy, building the
envelope. In early network topologies, data didn't
flow in a continuous unstructured stream. It
had to be meticulously packetized. Every piece
had its place. Exactly. The start of heading
SOH character acted as a loud announcement to
every switch and router on the network. It essentially
said, attention, the data following this character
is not the message itself. It is routing information.
Like the address on the outside of the envelope.
Exactly. It contains the address of the destination
terminal. So the machines would read the heading,
to figure out where to send the data, and then
they would encounter the STX, the start of text
character. Precisely. STX told the receiving
machine, the routing information is over. Everything
from here on out is the actual payload you need
to print or display for the human operator. The
actual letter inside the envelope. Right. And
this would continue until the machine received
ETX, the end of text character, which closed
the payload. And finally, EOT, end of transmission.
which I imagine was the definitive sign off,
like, I am dropping the connection now. Yes.
EUT was the command to disconnect the circuit
entirely, hang up the phone, basically. Visually,
the ISO 2047 symbols for these four are quite
clever. I'm looking at them here. SOH, the start
of the heading, looks like the top left corner
of a box. Yes. STX is an upside down T. ETX,
the end of the text, is the bottom right corner
of a box. You can literally see the visual framing
of the data packet. It's very architectural.
The geometric shapes provide a distinct visual
boundary when reviewing a diagnostic printout.
You can see the start and end of the blocks at
a glance. It's all very rigid and mathematical,
but... nested right next to these structural
commands is my absolute favorite detail of this
entire Wikipedia article. Oh, I know what you're
gonna say. It completely shatters that cold mathematical
feeling and injects a bizarre sense of human
conversation into the network. It involved that
inquiry character we were just discussing, the
one with the cross and the box decks at hex 05.
It is a striking historical note. According to
the source, If you were sitting at a teletype
Model 33, which was arguably the most iconic
and ubiquitous terminal of the era, the physical
key on the keyboard for this inquiry command
wasn't labeled E and Q. No, it wasn't. It was
labeled W R U. And the article helpfully translates
that for us. W R U stood for Who Are You? Who
are you? It is a direct literal translation of
what the network handshake protocol was attempting
to achieve. I find that endlessly fascinating.
I'm imagining a computer operator in a noisy
room needing to verify a connection to a terminal
in another city. They don't run a diagnostic
script. They reach out and press a physical button
that asks the machine on the other end of the
telephone wire, who are you? It's very personal.
It is. It is an interrogation happening over
copper wires. To understand why this was necessary.
You really have to understand the lack of security
and certainty in early dial -up networks like
the Telex system. It was basically the Wild West.
It really was. You were literally dialing a phone
number to connect your terminal to another terminal.
There were no digital certificates. There was
no cryptographic authentication. It's a phone
connection. Right. If you dialed a wrong digit
or if the telephone exchange misrouted your call,
you might connect to a terminal in a completely
different company. And if you just started transmitting
a financial report right away, you've just committed
a massive data breach. Exactly. You've just handed
your secrets to a stranger. So standard operating
procedure dictated that before you sent any payload,
you pressed the WRU key. This sent the E &Q character
down the line. And what happens on the other
side? The receiving teletype, upon receiving
an E &Q, was hardwired to respond. It didn't
require human intervention on the receiving end
at all. Oh, so the person on the other end didn't
have to type I am Terminal 5. No. Inside the
receiving teletype was a mechanical component
called an answerback drum. An answerback drum?
A physical drum? Yes. It was a literal rotating
cylinder with rows of small metal pegs. Like
a music box. Exactly like a music box. When the
machine was installed, a technician would physically
break off specific pegs to encode the machine's
unique identifier. So they programmed it with
pliers? Literally. They'd encode perhaps a company
abbreviation and a terminal number. When the
E &Q signal arrived, it triggered a solenoid
that spun this drum. And as it spin? As the drum
spun, the remaining pegs tripped contacts that
transmitted that unique identifier back down
the phone line. That is incredible. So the receiving
machine physically played its own name back across
the wire. That is exactly how it functioned.
And the operator sitting at the transmitting
terminal would see that unique identifier print
out on their own paper roll. And if it matches?
If it matched the machine they intended to reach,
they knew it was safe to transmit the STX and
the payload. Who are you? Was a fundamental security
protocol built out of spinning metal and solenoids.
It's just so tactile. And it makes you view modern
networking through a completely different lens.
It really does. When I open a web browser and
connect to my bank, there is an immense amount
of cryptographic handshaking happening in milliseconds.
TLS certificates are being verified, public keys
are being exchanged. But conceptually, at the
very bottom of the stack, my laptop is still
just walking up to the bank server and asking,
who are you? And demanding proof. The fundamentals
haven't changed. We just automated the music
box drum. It is the exact same paradigm, just
abstracted behind millions of lines of code.
The Teletype Model 33 just made it wonderfully
explicit for the human operator. Well, since
we are talking about spinning drums and solenoids,
let's lean into that. Because as abstract as
start of heading is, the reality is that many
of these 7 -bit codes were designed to control
heavy physical machinery. And what's wild is
how much of that physical vocabulary has survived
into our modern glass screen era. Let's look
at hex 07. The common abbreviation is BEL. The
full name is Bell. And in 1975, that wasn't a
metaphor. It was a literal command to ring a
bell. Explain the use case for that. I mean,
why does a computer need to ring a bell? Remember
that early data processing often involves long
periods of waiting? An operator might start a
batch job that takes two hours to compile on
the mainframe. Right. They aren't going to sit
and stare at a silent terminal for two hours.
They might be in the next room sorting punch
cards or getting a coffee. They seem to need
an alert. The mainframe needed a way to alert
the operator when the job was done or, more importantly,
when the job encountered a fatal error and halted.
So it sends a BEL character down the wire? Yes.
Upon receiving Hexo 7, the terminal would trigger
a circuit that rang an actual 110 volt mechanical
bell inside the casing. Like a fire alarm? Essentially.
It was an audible alarm built directly into the
tech stream. You could embed BEL characters into
your code so the machine would literally chime
when it reached certain milestones. The ISO 2047
symbol for it is great, too. In modern Unicode,
it's U plus 237E, and it looks a bit like an
old -fashioned tell deskbell with little vibration
lines coming off it. It's a very charming glyph.
But the physical control goes far beyond just
making noise. It dictates the entire geometry
of how text was laid out on paper. I'm looking
at the list of format effectors. Ah, the format
effectors. At hex 08, we have BS, backspace,
HT at hex 09, horizontal tabulation, LF at hex
0A, line feed, BT at hex 0B, vertical tabulation.
FF at 0xC, form feed, and CR at 0xD, carriage
return. These commands are direct descendants
of the mechanical typewriter. A computer screen
today can place a character anywhere instantly
using coordinate geometry. Just light up a pixel.
Exactly. But a teleprinter operates under strict
physical laws. The printhead is a heavy block
of metal. It moves sequentially left to right.
The paper feeds linearly from a roll or a stack.
Let's break down the distinction between carriage
return and line feed. Because I think a lot of
people today use the enter or return key on their
keyboard and assume it's one single action. Just
go to the next line. It feels like one action
to us now. But historically it was two very distinct
physical movements. It's a crucial distinction.
Carriage return, hex 0D, specifically commanded
the heavy printing mechanism, the carriage, to
slide all the way back to the left margin. Just
horizontal movement. Yes, but it did not move
the paper. If you only sent a carriage return,
the next line of text would print directly on
top of the previous line. Oh man, so you just
get an illegible black smudge of ink. Exactly,
you're just striking the same piece of paper
over and over. So you needed the line feed, hex
0A. Yes. Line feed commanded the platen, the
roller holding the paper, to rotate exactly one
notch, advancing the piper up by one line. Vertical
movement. Therefore, to start a new line of text
correctly, the computer had to transmit both
characters. A carriage returned to move left
and a line feed to move down, often abbreviated
as CRLF. CRLF. And the ghosts of that physical
necessity still haunts us today. It does. It
causes headaches even now. It is the reason why.
For decades, text files created on a Windows
machine looked broken when opened on a Unix or
Linux machine, and vice versa. The great new
line format war. Because Windows operating systems
historically used the two -character CRLF sequence
to mark a new line mimicking the physical teleprinter.
While Unix -based systems decided that was inefficient.
Right. They just used a single line feed character
to represent a new line. We had a digital format
war purely because of the ghost of a 1960s mechanical
carriage. It is the ultimate example of skeuomorphism.
We retained the data structure of the physical
mechanism long after the mechanism itself was
replaced by pixels on a screen. But visualizing
these physical movements for the purpose of debugging.
proved to be incredibly tricky for the ISO committee.
Very tricky. The standard really seems to struggle
when it comes to the backspace character. Let's
look at the footnotes for hex 08. The problem
with backspace is representing kinetic energy
in a static single character space. Right, because
the command means move the print head one position
to the left. Which is easy to do mechanically,
but hard to draw if you can only take up one
space on the grid. Exactly. The footnote in the
standard acknowledges this difficulty. It states
that a best -fit approximation must be used.
Its primary suggestion is an arrow pointing to
the upper left. Okay. But then the source lists
an entire array of alternative, defensible choices.
It suggests hooked arrows, arrows that curve
back on themselves in a U -turn shape, arrows
with a right -angle bend pointing left, arrows
curving downwards and leftwards. It's almost
comical. They're throwing every possible curved
line at the problem. Why was a simple straight
arrow pointing left Not good enough. Because
a simple straight arrow pointing left is already
a standard typographical and mathematical symbol.
Oh, like the lesson sign. Or just a general directional
indicator. It could be confused for a logical
operator depending on the context of the code.
The debugging engineer needed to see a symbol
that instantly conveyed the action of the mechanism
retreating against the normal flow of text. So
the hooked and looping arrows attempt to visually
communicate a reversal of momentum. Exactly.
Graphic design under extreme constraints. But
if we are talking about extreme physical actions,
we have to look at the device controls. This
is the section of the table, encompassing DC1
through DC4, occupying hex codes 11 through 14.
These are arguably the most raw physical commands
in the entire standard. Why do you say that?
Well, the names are deliberately generic. Device
Control 1, Device Control 2, and so on. They
were designed as wild cards. The standard didn't
mandate what they did. It just provided the code
so that hardware manufacturers could wire them
to turn specific peripheral devices on and off.
And the Wikipedia article gives us a vivid example
of how they were actually used in practice, returning
to our favorite machine, the Teletype Model 33.
It explains exactly what these generic controls
triggered on that specific hardware. Yes. On
the Model 33, these controls managed the physical
paper tape system. It's a paper tape. A teleprinter
wasn't just a keyboard and a printer. It often
had a separate paper tape puncher and a paper
tape reader bolted to the side of it. Like a
massive attachment. Right. This allowed you to
record data offline and then transmit it later
at maximum speed. And the device controls manipulated
those peripherals. The source notes that DC2
and DC4 were commonly mapped to the puncher.
DT2 was labeled tape E, and DC4 was labeled with
an abbreviation that effectively meant not tape
E or tape off. Consider the reality of that.
You are a terminal receiving a quiet stream of
data. Suddenly, the invisible DC2 code arrives
over the wire. Tape E up? Immediately, a heavy
electrical motor engages. A complex mechanism
of hardened steel pins begins violently punching
holes into a thick strip of paper tape at 10
characters a second. It must have been so loud.
It is loud, it generates heat, and it creates
literal physical confetti. It continues this
industrial process until the DC4 command arrives
and the motor abruptly shuts off. The computer
is reaching across the country and physically
turning heavy machinery on and off in your office.
It's a very visceral form of remote control.
And the source also mentions DC1 and DC - Yes.
DC1 and DC3 were mapped to the paper tape reader.
DC1 was commonly referred to as XON and DC3 as
XO off. XON and XOF. If you wanted the terminal
to start transmitting the data that was stored
on a punched tape, you sent the DC1 command.
A motor would engage, physical star wheels would
pull the tape over a reading head, and the terminal
would start sending data based on the holes it
sensed. DC3 would halt the reader. This XON -XOF
concept became a massive part of computer history,
didn't it? A huge part! It evolved from physically
stopping a paper tape motor into a broader software
concept called flow control. Exactly right. If
a computer was receiving data faster than it
could process it, it would send an XOFS command
to tell the sender to pause. Once it caught up,
it sent XON to resume. We abstracted the physical
paper tape motor into a software buffer limit.
It is another instance of physical reality mapping
directly into software architecture. And the
visual symbols assigned to these four device
controls in ISO 2047 are wonderfully abstract,
yet somehow fitting for industrial machinery.
What do they look like? They are represented
by circles with different quadrants filled in
or shaded. DC1 has the top left shaded, DC2 has
the top half shaded, and so on. Oh, interesting.
They resemble the phases of the moon, or perhaps
more aptly, the rotating cams and gears inside
the machinery they controlled. It's an industrial
aesthetic for an industrial function. But eventually,
the machines had to do more than just punch tape
and ring bells. They had to manage the complexity
of the data itself. Right. the logic of the network.
Let's move to a group of characters that I think
of as the bureaucracy of the network. Because
once you have machines talking to machines without
humans intervening, you need an automated way
to manage disputes, confirm receipts, and organize
the paperwork. This is where we see the true
foundation of network protocols. The core of
this bureaucracy rests on the acknowledgement
characters. Let's look at those. At hex 06, We
find ACK, standing for acknowledge, and at hex
15 we have NA, negative acknowledge. I love how
straightforward these are. The visual symbols
chosen for ISO 2047 are universally understood.
The symbol for ACK is a literal checkmark. Simple
and effective. Just a simple graphic indicating,
yes, the data was received and the check sum
is correct. The symbol for NAC is the same check
mark, but with a horizontal line struck forcefully
through it. A visual veto. Exactly. A visual,
know the data is corrupted, please send it again.
It's like grading a test. The elegance is in
the simplicity. Early data transmission over
analog telephone lines was incredibly prone to
errors. Static on the line would frequently flip
a bit from a 0 to a 1, turning an A into a B,
or worse, turning an A into an end of transmission
command. Which would just terminate the whole
session. Right. So data was sent in blocks. A
transmitting machine would send a block of text,
followed by an ETC character, hex 17, end of
transmission block. And then it would just wait.
Exactly. It would pause and wait for the receiving
machine to process the block. The receiver would
calculate a checksum mathematically to verify
the data's integrity. And if it's good? If the
math checked out, it transmitted an ACK back
down the line. The sender, upon receiving the
ACK, would proceed to send the next block. And
if it's bad? If the receiver detected an error,
it sent an AK. The sender would then rewind and
retransmit that same block. It is a highly choreographed
continuous loop of verification. And intertwined
with that process is SYN at hex 16. Synchronization.
What was the role of that character? SYN was
essential for synchronous transmission systems.
In simpler asynchronous systems, like standard
dial -up modems, every individual character was
framed by a start bit and a stop bit. to tell
the receiver when to read. Start reading, stop
reading. Right. But that added a lot of overhead.
Synchronous systems transmitted data in a continuous,
rapid stream without start and stop bits. To
make that work, the transmitter and receiver
clocks had to be perfectly locked in time with
each other. Like two musicians keeping the same
beat. Precisely. Before transmitting the actual
data, the sender would stream a continuous series
of SYN characters. SYN, SYN, SYN. The receiving
hardware would lock onto the repeating bit pattern
of the SYN character and adjust its internal
clock to match the incoming signal exactly. Once
they were synchronized, the data payload could
flow seamlessly. Okay, so we have the check marks
for success, the crossed out check marks for
failure, and the synchronization beats to keep
time. But what happens when the bureaucracy fails
entirely? What happens when a machine is hopelessly
confused or a process needs to be violently aborted?
That's when you hit the panic buttons. We have
panic button characters. The most direct panic
button is Canon at hex 18 cancel. And what does
that look like? Its symbol in ISO 2047 is a stark
geometric shape. It resembles an hourglass or
two triangles touching at their points. What
triggers a cancel command? CAN was generally
used to tell the receiving system to completely
discard the data it had just received in the
current block, usually because the transmitting
system itself realized it had made an error,
or the human operator hit an abort sequence.
So it just trashes the current block. It's a
command to wipe the slate clean for the current
operation without dropping the connection entirely.
And then there is SUB at hex 1A, substitute character.
The standard dictates its visual symbol looks
like a little blot containing a question mark
shape, or perhaps a reversed S. Why would a machine
need to substitute a character? The substitute
character was a crucial mechanism for graceful
failure. Graceful failure. I like that term.
Imagine a terminal receiving a stream of text
and one specific byte is garbled by line noise
so badly that the terminal's hardware simply
doesn't recognize it as any valid character in
the 7 -bit set. It's just junk data. Right. Older,
less sophisticated hardware might simply crash
or hang indefinitely when it encountered an illegal
instruction. Which is catastrophic if you are
in the middle of a large job. Exactly. So more
advanced hardware was programmed to catch that
error. Instead of crashing, it would say, I received
an unreadable byte. I will discard it, and in
its place on the screen or printout, I will insert
the SEB character. Oh, I see. It was a visible
placeholder that told the human operator something
was supposed to be here, but it was lost in transit.
It allowed the rest of the transmission to continue
uninterrupted while flagging the specific point
of failure. It's a managed failure state. I don't
know what this is, but I'm not going to let it
ruin the whole document. That is very smart engineering.
It's pragmatic. But if we are talking about smart
engineering, we cannot talk about this standard
without bowing down to Hex 1B, ESC, ESCAPE. Yes,
ESCAPE, represented in ISO 2047 by a circle with
a horizontal line drawn through the middle of
it. U plus 238B in modern Unicode. It is arguably
one of the most powerful and significant control
characters ever devised. Why is it so powerful?
In modern computing, I hit the S key to close
a full screen video or cancel out of a dialog
box. It feels like a very mundane go away button.
But historically, it was much more than that.
The clue is in the name. Escape. It is an escape
from the limitations of the seven bit architecture.
What do you mean? You have to remember the fundamental
constraint these engineers were working under.
A 7 -bit code only allows for 128 unique values.
Total. Just 128. That includes all your uppercase
letters, lowercase letters, numbers, punctuation,
and all 32 of these control characters we've
been discussing. That leaves absolutely zero
room for anything else. Exactly. What if you
want to tell the terminal to change the text
color to red? Or clear the screen? Or move the
cursor to coordinate line 10, column 20? You
don't have any unique 7 -bit codes left to assign
to those complex commands. You've run out of
numbers. So how does escape fix that? The escape
character fundamentally alters the state machine
of the receiving terminal. It acts as a massive
modifier key. When a terminal receives the ESC
character, it essentially stops treating the
incoming data as normal text. It shifts gears.
It says, okay, the very next characters I receive
are not letters to be printed. They are part
of a special extended command sequence. So you
string characters together to make new commands.
Precisely. These became known as ANSI escape
sequences. For example, if the terminal received
an A, it would print A. But if it received the
ESC character, followed immediately by an open
bracket, followed by the letter A, the terminal
wouldn't print anything. What would it do? It
would interpret that specific multi -character
sequence as a command to move the cursor up one
line. That's brilliant. By utilizing escape as
a gateway, engineers essentially unlocked an
infinite number of command combinations without
needing to expand the underlying 7 -bit architecture.
It allowed hardware to evolve incredibly complex
graphical interfaces over rudimentary connections.
It was a trapdoor built into the foundation that
allowed the entire system to scale. The foresight
to include that in the standard is just staggering.
It saved the computing industry from locking
itself into a dead end. Before we leave the bureaucracy
section, though, I want to look at how they organized
information itself before the era of visual operating
systems. We have four specific characters at
the end of the 10 series hex codes, FS, GS, RS,
and US. The information separators, hex 1C through
1F. Now, if I'm a listener sitting here at my
laptop, I organize my digital life very visually.
I have a desktop. I open a folder called Finances.
Inside that, a subfolder called 2026. Inside
that, a spreadsheet file. And in that file, I
have rows and columns of data. It's all spatially
organized? I can see the hierarchy instantly.
How did engineers manage that kind of hierarchical
data structure in a linear stream of 7 -bit text?
They managed it precisely by using those four
invisible separators. They are the primitive
structural ancestors of your folders and files.
Okay, walk me through it. You have to imagine
data being written sequentially onto a massive
reel of magnetic tape. There are no visual folders
on a tape. It is just a million miles of ones
and zeros. To make sense of it, a database program
needs markers embedded directly into the text
stream to define the boundaries of the data.
So how did the hierarchy work? Which one is the
smallest? It started from the smallest element
and built upwards. U .S. at hex one F is the
unit separator. A unit might be the smallest
discrete piece of information, for example, a
person's first name. You would separate the first
name from the last name using a U .S. character.
Like the comma in a modern CSV file. Exactly
like that. The next level up is R .S. the record
separator at hex 1E. A record is a collection
of units. So a complete mailing address, name,
street, city, zip, might constitute one record.
You use an RS character to separate one person's
full address from the next person's address.
And it scales up from there. Yes. Next is GS,
the group separator at hex 1D. You might group
thousands of individual records by geographical
region. A GS character would mark the end of
the East Coast group and the beginning of the
West Coast group. And the biggest one. Finally,
at the top of the hierarchy is FS, the file separator
at hex 1C. This would separate entirely distinct
datasets on the same magnetic tape, like separating
the payroll database from the inventory database.
So a program parsing the tape would just scan
for these invisible characters to understand
the structure of the data it was reading. Yes
it just look for those markers. The visual symbols
designed for these in ISO 2047 are brilliantly
logical too. I'm looking at them. They are all
U shapes or squares divided into four quadrants.
They bill them in each other. For the highest
level file separator FS the top left quadrant
is filled. For group separator GS it moves to
the top right. For Record separator RS, the bottom
right, and for unit separator US, the bottom
left. It's a progression. It's a visual representation
of moving sequentially through the layers of
the hierarchy. It is a very elegant graphic design
for something designed to be purely utilitarian.
It demonstrates a deep intentionality. They weren't
just picking random shapes. They were building
a visual syntax. Which brings us to the final
and perhaps most intriguing aspects of the source
material. We need to look at the anomalies, the
edge cases, and the eventual afterlife of this
visual syntax. Let's start with the bookends
of the entire ASCII table. We've talked extensively
about the control characters clustered at the
lower end of the hex values. But nested in this
standard are two other crucial non -printing
entities that sit outside that main block. At
hex 20, immediately following the control characters,
we have SP. Space, the most ubiquitous invisible
character in all of computing. We press the space
bar more than any other key. It is the caricature
we use to separate words and make human language
readable. But in the context of ISO 2047 and
terminal debugging, the space presents a unique
problem. The problem is ambiguity. On a normal
printout, a space is just blank paper. But if
you are an engineer examining a diagnostic dump
and you see a blank area between two words, you
have to ask yourself a critical question. Did
it mean to do that? Right. Did the computer intentionally
transmit a space character, hex 20, or did the
printer hardware simply fail to fire for a millisecond,
leaving a gap? You can't debug based on assumptions.
You need proof. Precisely. Therefore, in this
diagnostic mode, you have to force the invisible
space to become visible. You have to draw a picture
of a space. ISO 2047 assigned it a very specific
symbol, a tiny open triangle pointing upwards.
In Unicode, it is U plus 25B3. I'm trying to
visualize reading a diagnostic printout where
every single space between every single word
is represented by a tiny upward pointing triangle.
It would look like an incredibly dense alien
text. It would be visually chaotic. for a layperson,
but for an engineer, it provided absolute certainty.
Every triangle proved that a hex 20 code was
successfully received and parsed. And then at
the absolute opposite end of the 7 -bit table,
far away from the control characters sits hex
7f. The very last possible value, DEL, delete.
The delete character is historically fascinating
because its very existence is tied entirely to
the physical properties of punched paper tape.
More paper tape mechanics. Yes. We've talked
about how a null character 0x00 is a row with
absolutely zero holes punched. The delete character
0x7f is the exact opposite. 7 bits means there
are 7 possible hole positions. A value of 7f
in hexadecimal translates to all 7 bits being
set to 1. In binary, it is 11 11 11 11. So on
a paper tape, a delete character is a row where
every single possible hole is punched out. Exactly.
Now consider why that specific physical configuration
was chosen for the concept of delete. Imagine
you are an operator typing on a teletype and
the machine is punching the tape as you type.
You hit the wrong key. You've type a B instead
of an A. The physical hole for the B has already
been punched through the paper. You can't un
-punch a hole. You can't put the paper confetti
back in. The physical error is permanent. Right.
So how do you fix it? You press a physical button
on the tape puncher that backspaces the tape
one position, moving the erroneous B back under
the punch bins. Then you press the rub -out or
delete key. The machine fires all seven punch
pins simultaneously, punching holes in every
single position of that row. It physically obliterates
the B by turning it into a row of seven holes.
That is an incredibly clever mechanical hack.
But how does the computer reading the tape know
it's a mistake? The software drivers running
the tape readers were programmed with a very
specific rule. If you read a row with all seven
holes punched, hex 7f, ignore it completely.
Treat it as if it does not exist, do not process
it, do not print it, just move to the next row.
It was a physical mechanism for erasing data
by obliterating it with maximum entropy. That
is a brilliant piece of engineering history.
and the visual symbol assigned to delete in ISO
2047 perfectly reflects that concept of physical
obliteration. The standard dictates it should
be represented by a shaded, cross -hatched block,
a solid mass of ink that covers the entire character
space. In Unicode, it's U plus 25A8 or similar.
It looks exactly like a physical redaction in
a class -wide document. It is the visual representation
of a void created by overwhelming presence. But
the implementation of these brilliant symbols
wasn't universally smooth. The source material
points us to a highly specific curious anomaly
regarding how this standard was adapted in certain
environments. And I think this anomaly reveals
more about the reality of early computing than
the standard itself does. You are referring to
the note regarding the Irish standard. Yes. The
Wikipedia article references a document from
December 13, 1995, titled Information Technology
Irish 7 -bit Coded Character Sets. It's incredibly
niche. But the source notes that in this particular
Irish standard, the glyphs used for four specific
control characters, ENQ, BS, CR, and ESSO, were
considered anomalous. They did not match the
shapes dictated by the global ISO 2047 standard.
And the reason provided in the text for this
deviation is the critical part. It states the
anomaly was possibly to accommodate the low resolution.
To accommodate the low resolution. That phrase
just hits you with the stark reality of the hardware
of the era. It grounds the entire discussion.
We have spent an hour marveling at the intellectual
effort required to design these intricate, meaningful
geometric symbols. The International Committee
debated whether inquiries should be a cross or
a boxed X. They agonized over how to draw a curved
arrow that perfectly conveyed the kinetic reversal
of a backspace. They designed elegant four quadrant
squares for the information separators. They
built a perfect theoretical language. But then,
that perfect theoretical language collides with
the greedy reality of cheap hardware. Think about
the monitors of the late 70s and 80s. A standard
CRT terminal didn't draw smooth vector graphics.
It used a character generator ROM that mapped
a character to a rigid, coarse grid of pixels,
often just five pixels wide by seven pixels high.
That's only 35 tiny dots to draw a complex shape.
Exactly. Try drawing the ISO standard for backspace,
a sweeping, hooked arrow curving back on itself
in a five by seven grid. It's mathematically
impossible to make it look smooth. The pixels
just clump together. On the screen, it would
look like an elegant arrow. It would look like
an illegible glowing smudge. And if you are an
engineer trying to debug a critical system failure,
an illegible smudge is useless. You need clarity.
So standard or no standard? Local committees
and hardware manufacturers had to bend the rules.
The engineers writing the Irish standard or whoever
was manufacturing the terminals that standard
was based on likely realized the international
ISO shape simply would not render legibly on
the low resolution cathode ray tubes or cheap
dot matrix printers prevalent in their market.
They had to choose simpler, blockier, perhaps
cruder anomalous shapes for those specific commands
because the literal pixels required to draw the
international standard did not exist on this
It is the perfect example of high -level bureaucratic
theory crashing headfirst into the low -level
physical constraints. The standard has to bend,
or the system breaks. It's pragmatism over purity.
It is a poignant reminder of the incredible constraints
under which early digital architects operated.
Every single decision was a negotiation with
hardware limitations. So we know these symbols
bent under the pressure of low resolution. We
know from the earlier Japanese example that standard
enforcement eventually aged out and was abolished
in 2010. And the article itself plainly states
that the graphical symbols of ISO 2047 are outdated
and rare today, having been replaced by text
abbreviations like ESC or carrot notation. So
are they just gone? Is this entire visual language
lost to history, existing only in obsolete Wikipedia
tables? Fascinatingly, no. They are not gone.
They have achieved a form of digital immortality.
They have been preserved in amber within the
ultimate arbiter of modern digital text. The
source explicitly states that these specific
visual symbols are preserved forever in the Unicode
standard. Unicode, the massive foundational system
that ensures a text message sent from an Android
phone in Brazil, renders perfectly on an iPhone
in Canada. the system that manages every human
alphabet and every emoji. Yes. The mandate of
the Unicode Consortium is essentially to catalog
and standardize every single character from every
human language, past and present. But their mandate
also extends to crucial technical and historical
symbols. They recognize that the ISO 2047 visual
representations, while no longer used for daily
debugging, are a fundamental part of computing
history. They are the hieroglyphs of the digital
age. So where do they live in the Unicode table?
The ISO 2047 symbols for control characters are
specifically mapped and cited in two Unicode
ranges. First, the miscellaneous technical block,
which spans hexadecimal codes 2300 through 23FF.
Here you'll find things like the empty box for
null and the literal bell symbol for BEL. But
more specifically, there is a dedicated block
called control pictures ranging from hex 2400
to 243F. Control pictures. I love that phrase.
It sounds like a wing in a modern art museum.
Functionally, it is a digital museum. That block
contains specialized diagonal acronym graphics
designed to represent the control codes if a
system absolutely needs to display them, preserving
the intent of ISO 2047 in a modern typographic
format. So while a programmer at a tech startup
today will never use ISO 2047 to debug a cloud
microservice, the foundational visual language
designed by that committee in 1975 has been permanently
etched into the master dictionary of human communication.
It will exist as long as Unicode exists, which
is to say, as long as our current digital civilization
endures. That is a staggering thought. Let's
take a step back and look at the whole picture.
What an incredible, unexpected journey from a
single, dry Wikipedia table. We started this
deep dive looking at what seemed like an impenetrable
list of 1970s hex codes and bureaucratic acronyms.
But by digging in, by looking closely at what
those codes actually represented, we discovered
a vibrant, noisy, intensely physical world. We
found heavy steel machines physically ringing
bells to demand human attention. We found mechanical
paper tape punches violently tearing holes in
paper to record data. We found isolated terminals
interrogating each other across crackling telephone
lines, mechanically spinning drums to ask, who
are you? We saw the monumental agonizing international
effort to take invisible data commands and force
them into visible graphical shapes just so human
engineers could peer into the dark and understand
what the machines were saying to each other.
It really exposes the hidden physical architecture
that underlies the smooth abstract digital world
we inhabit today. Every sleek interface is built
on a foundation of these crude physical negotiations.
It absolutely is. And it fundamentally changes
how you look at the device sitting in front of
you right now. The next time you, the listener,
are typing an email and you hit the enter key,
I want you to remember that you aren't just moving
a pixelated cursor down a screen. You are invoking
a carriage return and a line feed, the ghost
of a heavy metal cylinder slamming to the left,
and a rubber roller ratcheting paper upward.
When you press the S key in the corner of your
keyboard, you are triggering a command designed
50 years ago to break a terminal out of a 7 -bit
prism. You are participating in a lineage of
commands that stretches back through clattering
teletype machines, across international standards
committees in 1968, all the way to the foundational
logic of the digital age. That historical continuity
is profound and it raises a final provocative
thought that I'd like to leave our listener with
today. We have spent this entire session looking
backward. We've examined the invisible control
commands of the 1970s and the immense creative
effort required to visualize them for human comprehension,
but let's apply that logic to the future. Okay,
let's spin it forward. If some future historian
or digital archaeologist were to dig through
the raw foundational code of the systems we use
right now in the 2020s, long after our current
screens, laptops and interfaces have turned to
dust, what invisible control commands of our
modern era do you think they would struggle to
visualize? We aren't just dealing with line feeds
and paper tape anymore. We are dealing with massive
neural networks, opaque algorithmic weighting
and decentralized cloud infrastructures. That's
a huge question. What is the modern equivalent
of a carriage return? Exactly. What new bizarre
symbols would a future committee have to invent
to visualize the invisible forces of today? How
do you draw a static picture of a command that
subtly adjusts a machine learning algorithm's
bias? How do you graphically represent a protocol
that silently trades a fraction of a cent on
a high -frequency stock market in a microsecond?
What would those new symbols look like? And more
importantly, what would they say about what our
society values and controls today? How do you
draw the invisible forces of the 21st century?
That is a brilliant question. Something deep
to mull over the next time you stare at a blanking
cursor on a blank screen. Thank you so much for
joining us on this incredibly detailed journey
through the hidden logic of ISO 2047. Keep questioning
the invisible structures around you and we will
catch you on the next deep dive.