IBM, sonic delay lines, and the history of the 80x24 display ============================================================
by Ken Shirriff

What explains the popularity of terminals with 80x24 and 80x25
displays? A recent blog post "80x25" motivated me to investigate
this. The source of 80-column lines is clearly punch cards, as
commonly claimed. But why 24 or 25 lines? There are many theories,
but I found a simple answer: IBM, in particular its dominance of the
terminal market. In 1971, IBM introduced a terminal with an 80x24
display (the 3270) and it soon became the best-selling terminal,
forcing competing terminals to match its 80x24 size. The display for
the IBM PC added one more line to its screen, making the 80x25 size
standard in the PC world. The impact of these systems remains decades
later: 80-character lines are still a standard, along with both 80x24
and 80x25 terminal windows.

<http://exple.tive.org/blarg/2019/10/23/80x25/>

In this blog post, I'll discuss this history in detail, including
some other systems that played key roles. The CRT terminal market
essentially started with the IBM 2260 Display Station in 1965, built
from curious technologies such as sonic delay lines. This led to the
popular IBM 3270 display and then widespread, inexpensive terminals
such as the DEC VT100. In 1981, IBM released a microcomputer called
the DataMaster. While the DataMaster is mostly forgotten, it strongly influenced the IBM PC, including the display. This post also studies
reports on the terminal market from the 1970s and 1980s; these make
it clear that market forces, not technological forces, led to the
popularity of various display sizes.

Some theories about the 80x24 and 80x25 sizes =============================================
Arguments about terminal sizes go back decades, [5] but the article
80x25 presented a detailed and interesting theory. To summarize, it
argued that the 80x25 display was used because it was compatible with
IBM's 80-column punch cards, [1] fits nicely on a TV screen with a
4:3 aspect ratio, and just fit into 2K of RAM. This led to the 80x25
size on terminals such as the DEC VT100 terminal (1978). The VT100's
massive popularity led to it becoming a standard, leading to the
ubiquity of 80x25 terminals. At least that's the theory.

It's true that 80-column displays were motivated by punch cards4 and
the VT100 became a standard, [2] but the rest of this theory falls
apart. The biggest problem with this theory is the VT100's display
was 80x24, not 80x25. [3] In addition, the VT100 used extra bytes of
storage for each line, so the display memory did not fit into 2K.
Finally, up until the 1980s, most displays were 80x24, not 80x25.

The DEC VT100 terminal had an 80x24 display. Over a million of them
were sold. Photo from Jason Scott, (CC BY-SA 4.0).

<http://static.righto.com/images/terminal/ 865px-DEC_VT100_terminal_transparent-w300.jpg>

Other theories have been expressed on Software Engineering
StackExchange and Retrocomputing StackExchange, arguing that 80x24
terminals resulted from technical reasons such as TV scan rates,
aspect ratios, memory sizes, typography, the history of typewriters,
and so forth. There is a fundamental problem with theories that 80x24
is an inevitable consequence of technology, though: terminals in the
mid-1970s had dozens of diverse screen sizes such as 31x11, 42x24,
50x20, 52x48, 81x38, 100x50, and 133x64. [11] This makes it clear
that technological limitations didn't force terminals into a
particular size. To the contrary, as technology improved, most of
these sizes disappeared and terminals were largely 80x24 by the early
1980s. This illustrates that standardization was the key factor, not
the technology.

<https://softwareengineering.stackexchange.com/questions/148754/ why-is-24-lines-a-common-default-terminal-height>

<https://retrocomputing.stackexchange.com/questions/5629/ why-did-80%C3%9725-become-the-text-monitor-standard>

I'll briefly summarize why technical factors don't have much impact
on the terminal size. Although US televisions used 525 scan lines and
60 Hz refresh, [9] 40% of terminals used other values. [6] The display frequency and bandwidth didn't motivate a particular display size
because terminals generated characters with a wide variety of matrix
sizes. [8] Although memory cost was significant, DRAM chip sizes
quadrupled every three years, making memory only a temporary
constraint. The screen's aspect ratio asn't a big factor because the
text's aspect ratio often didn't match the screen's ratio. [7] Of
course technology had some influence, but it didn't stop early
manufacturers from creating terminal sizes ranging from 32x8 to
133x64.

The rise of CRT terminals
=========================
At this point, a bit of history of CRT terminals will help. [11] Many
readers will be familiar with ASCII terminals, such as stand-alone
terminals like the DEC VT100, serial terminal connections via a PC,
or the serial port on boards such as the Arduino. This type of
terminal has its roots in teleprinters, electro-mechanical
keyboard/printers that date back to the early 1900s. The best-known
teleprinter is the Teletype, popular in newsrooms as well as computer
systems in the 1970s. (The Linux device /dev/tty is named after the
Teletype.) Teletypes typically printed 72-character lines on a roll
of paper. [10]

A Teletype ASR33 communicated in ASCII and printed 72 characters per
line. Hundreds of thousands of these were produced from 1963 to 1981.
The punched tape reader and punch is on the left. Photo from Arnold
Reinhold, (CC BY-SA 3.0).

<http://static.righto.com/images/terminal/
1280px-ASR-33_at_CHM.agr-w400.jpg>

In the 1970s, replacing teleprinters with CRT terminals was a large
and profitable market. AT&T introduced the Teletype Model 40 in 1973,
a CRT terminal with an 80x24 display. [12] Many other companies
introduced competing CRT terminals, and "Teletype-compatible" became
a market segment. By 1981 [11] these terminals were being used in
many roles besides replacing teleprinters and the name shifted to
"ASCII terminals". By 1985, CRT terminals were a huge success with 10
million terminals installed in the US.

The IBM 3270 terminal, specifically the newer 3278 model. From IBM
3270 Brochure (1977).

<http://static.righto.com/images/terminal/3270-operators-w400.jpg>

<http://bitsavers.org/pdf/ibm/3270/GS20-3149-0_3270_Brochure_May77.pdf>

But there's a parallel world of mainframe terminals, a world that may
be unfamiliar to many readers. In 1965, IBM introduced the IBM 2260
Display Terminal, which placed IBM's "stamp of approval" on the CRT
terminal, which had previously been "somewhat of a novelty." [6] This
terminal dominated the market until IBM replaced it with the cheaper
and more advanced IBM 3270 terminal in 1971. Unlike asynchronous
ASCII terminals that transmitted individual keystrokes, these
terminals were block oriented, efficiently exchanging large blocks of characters with a mainframe. The 3270 terminal was fairly
"intelligent": a 3270 user could fill in labeled fields on the
screen, and then transmit all the data at once by pressing the
"Enter" key. (This is why modern keyboards often still have the
"Enter" key.) Sending a block of data was more efficient than sending
each keystroke to the computer, and allowed mainframes to support
hundreds of terminals. In the next sections, I'll discuss the 2260
and 3270 terminals in detail.

<https://en.wikipedia.org/wiki/Computer_terminal
#Block-oriented_terminal>

The chart below [6] shows how the terminal market looked in 1974. The
market was ruled by IBM's 3270 terminal, which had obsoleted IBM's
2260 terminal by this point. With 50% of the market, IBM essentially
defined the characteristics of a CRT terminal. Teleprinter
replacement was a large and influential market; the Teletype Model 40
was small but growing in importance. Although DEC would soon be a
major player, it was in the small "Independent Systems" slice at this
point.

In 1974, IBM dominated the terminal market; 50% of the terminals sold
were IBM terminals (or compatibles). From Alphanumeric and Graphic
CRT Terminals.

<http://static.righto.com/images/terminal/piechart-w400.jpg>

<http://bitsavers.org/pdf/ventureDevelCorp/ Alphanumeric_and_Graphic_CRT_Terminals_1975-1980_Nov1975.pdf>

The IBM 2260 video display terminal
===================================
The IBM 2260 was introduced in 1965 and was one of the first video
display terminals. [14] It filled three roles: remote data entry (in
place of punching cards), inquiry (e.g. looking up records in a
database), and as a system console. This compact terminal weighed 45
pounds and was sized to fit on a standard office typewriter stand.
Note the thickness of the keyboard; it reused the complex keyboard
mechanism of the IBM keypunch. [13]

IBM 2260 Display Station. Photo from IBM via Frank da Cruz.

<http://static.righto.com/images/terminal/xi05-w500.jpg>

You might wonder how IBM could produce such a compact terminal with
1965 technology. The trick was that the terminal held just the
keyboard and CRT display; all the control logic, character
generation, storage, and interfacing was in a massive 1000 pound
cabinet (below). <15> This cabinet contained the circuitry to handle
up to 24 display terminals. It generated the pixels for these
terminals and send video signals to the terminals, which could be up
to 2000 feet away.

The IBM 2848 Display Control could drive up to 24 display terminals.
The cabinet was 5 feet wide and weighed 1000 pounds.

<http://static.righto.com/images/terminal/ibm-2848-w250.jpg>

One of the most interesting features of the 2260 is the sonic delay
lines used for pixel storage. Bits were stored as sound pulses sent
into a nickel wire, about 50 feet long. The pulses traveled through
the wire and came out the other end exactly 5.5545 milliseconds
later. By sending a pulse (or not sending a pulse for a 0) every 500 nanoseconds, the wire held 11,008 bits. A pair of wires created a
buffer that held the pixels for 480 characters. [16]

Sonic delay line module from the IBM 2260 display. This module
contained about 50 feet of coiled nickel wire. Image from 2260 Field Engineering Theory of Operation Manual.

<http://static.righto.com/images/terminal/sonic-delay-line-w500.jpg>

<http://www.bitsavers.org/pdf/ibm/2260/
Y27-2046-3_2260_2848_FETOM_Mar68.pdf>

The sonic delay line had several problems. First, you had to
constantly refresh the data: as bits came out one end of the wire,
you had to feed them back in the other end. Second, the delay line
was not random access: if you wanted to update a character, you
needed to wait several milliseconds for those bits to circulate.
Third, the delay line was sensitive to vibration; Wikipedia says that
heavy footsteps could mess up the screen. Fourth, the delay line
speed was sensitive to temperature changes; it needed to warm up for
two hours in a temperature-controlled cabinet before use. With all
these disadvantages, you might wonder why sonic delay lines were
used. The main reason was they were much cheaper than core memory.
The serial nature of a delay line was also a good match to the serial
nature of a raster-scan display.

<https://en.wikipedia.org/wiki/IBM_2260>

The coiled nickel wire inside a sonic delay has transducers at both
ends (center and bottom left, with twisted wiring attached). To
adjust the delay, the threaded rod (bottom left) moves the
transducer's position along the wire. The metal boxes on the ends of
the wires are dampers to prevent reflections. Photo courtesy of Alan
Parker.

<http://static.righto.com/images/terminal/delay-line-internal-w500.jpg>

The image below shows the screen of the 2260 Model 2, with 12 lines
of 40 characters. (The Model 1 had 6 lines of 40 characters and the
Model 3 had 12 lines of 80 characters.) Notice that the lines are double-spaced; this is because the control unit actually generated 24
lines of text but alternating lines went to two different terminals.
[20] This is a very strange approach, but it split the high cost of
the control hardware across two terminals. [19] Another strange
characteristic was that the 2260's scan lines were vertical, unlike
the horizontal scan lines in almost every video display and
television. [21]

IBM 2260 display showing 12 lines of 40 characters. Image from 2260
Operator Manual.

<http://static.righto.com/images/terminal/screenshot-w450.jpg>

<http://www.bitsavers.org/pdf/ibm/2260/ C20-1688-1_2260_Operator_Manual_Jul68.pdf>

Each character was represented in 6-bit EBCDIC, giving a character
set of 64 characters (no lower-case). [18] The delay lines stored the
pixels to be displayed, but they also stored the EBCDIC code for each character. The trick here is the blank column of pixels between each
character for horizontal spacing between characters. The system used
this column to store the BCD character value but blanked the display
during this column so the BCD value didn't show up as pixels on the
screen. This allowed the 6-bit character value to be stored
essentially for free.

The relevant question is why did the 2260 have a display with 12
lines of 80 characters? [23] [24] The 80-character width allowed the
terminals to take the place of 80-column punch cards for data entry.
(In the 40-character models, a card would be split across two lines.)
As for the 12 lines, that appears to be what the delay lines could
support without flicker. [22]

Image from 2260 Operator Manual.

<http://static.righto.com/images/terminal/operator-w300.jpg>

<http://www.bitsavers.org/pdf/ibm/2260/ C20-1688-1_2260_Operator_Manual_Jul68.pdf>

The IBM 2260 was a big success, and led to the popularity of the CRT
terminal. The impact of the IBM 2260 terminal is shown by a 1974
report on terminals; about 50 terminals were listed as compatible
with the IBM 2260. The IBM 2260 didn't have an 80x24 display
(although it generated 80x24 internally), but its 40x12 and 80x12
displays made 80x24 the next step for IBM.

<http://www.bitsavers.org/pdf/datapro/datapro_70/ 70D-010-20_All_About_CRT_Display_Terminals_Apr1974.pdf>

The IBM 3270 video display
==========================
In 1971, IBM released the IBM 3270 video display system, which
proceeded to dominate the market for CRT terminals. [26] This
terminal supported a 40x12 display to provide a migration path from
the 2260, but also supported a larger 80x24 display. The 3270 had
more features than the 2260, such as protected fields on the screen,
more efficient communication modes, and variable-intensity text. It
was also significantly cheaper than the 2260, ensuring its
popularity. [25]

The IBM 3270 terminal. The Selector Light Pen was used to select data
fields, somewhat like a mouse. This terminal is a later model, the
3278; in the photo it is displaying 43 lines of 80 characters. From
IBM 3270 Brochure (1977).

<http://static.righto.com/images/terminal/brochure-w300.jpg>

<http://bitsavers.org/pdf/ibm/3270/GS20-3149-0_3270_Brochure_May77.pdf>

The technology in the 3270 was a generation more advanced than the
2260, replacing vacuum tubes and transistors with hybrid SLT modules,
similar to integrated circuits. Instead of sonic delay lines, it used
480-bit MOS shift registers. [27] The 40x12 model used one bank of
shift registers to store 480 characters. In the larger model, four
banks of shift registers (1920 characters) supported an 80x24
display. In other words, the 3270's storage was in 480-character
blocks for compatibility with the 2260, and using four blocks
resulted in the 80x24 display. (Unlike RAM chips, a shift register
size didn't need to be a power of 2. While a RAM chip is arranged as
a matrix, a shift register has a serpentine layout (below) and can be
an arbitrary size.)

<https://en.wikipedia.org/wiki/IBM_Solid_Logic_Technology>

Die photo of the Intel 1405 shift register. This shift register was
not used in the IBM 3270 but was used in other terminals such as the
Datapoint 2200.

<http://static.righto.com/images/terminal/i1405-w350.jpg>

IBM provided extensive software support for the 3270 terminal. [28]
This had an important impact on the terminal market, since it forced
other manufacturers to build compatible terminals if they wanted to
compete. In particular, this made 3270-compatibility and the 80x24
display into a de facto standard. In 1977, IBM introduced the 3278,
an improved 3270 terminal that supported 12, 24, 32, or 43 lines of
data. It also added a status line, called the "operator information
area". The new 32- and 43-line sizes didn't really catch on, but the
status line became a common feature on competing terminals.

Looking at industry reports [6] [11] [32] shows the popularity of
various terminal sizes from the 1970s to the 1990s. Although there
were 80x25 displays in 1970 (if not earlier), the 80x24 display was
much more common. The wide variety of terminal sizes in 1974
diminished over time, with the market converging on 80x24. By 1979,
the DEC VT100 (with its 80x24 display) was the most popular ASCII
terminal with over 1 million sold. Terminals started supporting
132x24 for compatibility with 132-character line printers, [29]
especially as larger 15" monitors became more affordable, but 80x24
remained the most popular size. Even by 1991, 80x25 remained
relatively uncommon.

<http://www.bitsavers.org/pdf/datapro/alphanumeric_terminals/ Datapro_C25_010_Comparison_Display_Terminals_Jun91.pdf>

The IBM PC and the popularity of 80x25
======================================
Given the historical popularity of 80x24 terminals, why do so many
modern systems use 80x25 windows? That's also due to IBM: the 80x25
display became popular with the introduction of the IBM PC in 1981.
The PC's default display card (MDA) provided 80x25 monochrome text
while the CGA card provided 40x25 and 80x25 in color. This became the
default size of a Windows console, as well as the typical size for
PC-based terminal windows.

<https://books.google.com/ngrams/graph?content=80x25&year_start=1975 &year_end=1990&corpus=15&smoothing=1>

<https://en.wikipedia.org/wiki/IBM_Monochrome_Display_Adapter>

<https://en.wikipedia.org/wiki/Color_Graphics_Adapter>

The IBM PC with an 80x25 display generated by the MDA (Monochrome
Display Adapter) card. Photo from Boffy b (CC BY-SA 3.0).

<http://static.righto.com/images/terminal/IBM_PC_5150-w400.jpg>

Other popular computers at the time used 24 lines, such as the
Osborne 1 and Apple II, so I was curious why the IBM PC used 25
lines. To find out, I talked to Dr. Dave Bradley and Prof. Mark Dean,
two of the original IBM PC engineers. They explained that the IBM PC
was a follow-on to the rather obscure IBM DataMaster office
computer,30 and many of the IBM PC design choices followed the
DataMaster microcomputer. The IBM PC kept the DataMaster's keyboard,
but detached from the main unit. Both systems used BASIC, but the
decision to get the PC's BASIC interpreter from the tiny company
Microsoft would change both companies more than anyone could imagine.
Both systems went with an Intel processor, an 8-bit 8085 in the
DataMaster and the 16-bit 8088 in the IBM PC. They also used the same
interrupt controller, DMA controller, parallel port, and timer chips.
The PC's 62-pin expansion bus was almost identical to DataMaster's.

<https://en.wikipedia.org/wiki/Industry_Standard_Architecture>

The IBM DataMaster System/23 was a microcomputer announced in 1981
just a month before the IBM PC.

<http://static.righto.com/images/terminal/datamaster-w400.jpg>

The drawing below is part of an early design plan for the IBM PC. In particular, the IBM PC was going to use the 80x24 display of the
DataMaster (codenamed LOMA), as well as 40x16 and 60x16 more suitable
for televisions. The drawings also show color graphics with 280x192
pixels, the same resolution as the Apple II. But the IBM PC ended up
not quite matching this plan.

Detail from an early (August 25, 1980) design plan for the IBM PC.
"LOMA" is the code name for the IBM DataMaster. "18 kHz" is the
18.432 kHz horizontal scan frequency used by the MDA card, providing
more resolution than the 15.750 kHz used by NTSC televisions. Scan
courtesy of Dr. Dave Bradley.

<http://static.righto.com/images/terminal/bradley-plan-w550.jpg>

The designers of the IBM PC managed to squeeze a few more pixels onto
the display to get 320x200 pixels. When using an 8x8 character
matrix, the updated graphics mode supported 40x25 text, while the double-resolution graphics mode with 640x200 pixels supported 80x25
text. The monochrome graphics card (MDA) matched this 80x25 size. In
other words, the IBM PC ended up using 80x25 text because the display
provided enough pixels, and it provided differentiation from other
systems, but there wasn't an overriding motivation. In particular,
the designers of the PC weren't constrained by compatibility with
other IBM systems. [31]

<https://www.seasip.info/VintagePC/mda.html>

Conclusion
==========
To summarize, many theories have been proposed giving technical
reasons why 80x24 (or 80x25) is the natural size for a display. I
think the wide variety of display sizes in the early 1970s proves
this technological motivation is mostly wrong. Instead, display sizes
converged on what IBM produced, first with the punch card, then the
IBM 2260 terminal, the IBM 3270, and finally the IBM PC. The
72-column Teletype had some influence on terminal sizes at first, but
this size was also swept away by IBM compatibility. The result is the
current situation with an uneasy split between 80x24 and 80x25
standards.

Thanks to Dr. Dave Bradley, Prof. Mark Dean, and IBM engineer Iggy
Menendez for information.

Notes and References
====================
[1]
Punch cards have a longer history than you might think. The standard
80-column IBM punch card was introduced in 1928, improving on punch
cards used for the 1890 census. Before the modern computer, punch
cards were processed with electromechanical sorters and accounting
machines. The punch card remained a keystone of data processing until
the 1970s, and its impact still remains.

<http://www.righto.com/2016/05/inside-card-sorters-1920s-data.html>

<http://www.righto.com/2017/11/identifying-early-ibm-computer-in.html>

An IBM punch card holds 80 characters, printed along the top. The
hole pattern in each column encodes the character.

<http://static.righto.com/images/terminal/card-w400.jpg>

[2]
By 1986, the DEC VT100 was "an acknowledged standard in the terminal
industry" and "the most popular ASCII terminal ever produced, with
1,000,000 units sold since its introduction in 1978."

<http://www.bitsavers.org/pdf/datapro/alphanumeric_terminals/ Datapro_C25_Digital.pdf>

[3]
For information on the internals of the VT100 see the Technical
Manual. The VT100 had 3K of memory, of which about 2.3K was used for
the screen while the 8080 microprocessor used the remainder. Each
line was stored in memory with 3 additional bytes on the end, used as
pointers for scrolling.

<http://bitsavers.org/pdf/dec/terminal/vt100/ EK-VT100-TM-003_VT100_Technical_Manual_Jul82.pdf>

[4]
It should be clear that IBM's 80-column punch cards were the
motivation for 80-column displays, but I wanted to find contemporary
sources to confirm that. One example is All About CRT Display
Terminals (1974, page 11) stating that terminals with an 80-column
line gave compatibility with punched cards while the 72-column line
provided compatibility with Teletypes. Also see Big Screen,
132-Column Units Setting Trend, Computerworld, Oct 26, 1981. Although
the article focuses on 132-column terminals to replace printers, the
article also describes how earlier terminals had an 80-column format
like the punch cards they replaced.

<http://www.bitsavers.org/pdf/datapro/datapro_70/ 70D-010-20_All_About_CRT_Display_Terminals_Apr1974.pdf>

<https://books.google.com/books?id=1REkdf3I86oC&lpg=RA2-PA41 &pg=RA2-PA41#v=onepage&q&f=false>

[5]
Controversy over the reason for 80x24 displays goes way back. An
editorial in Infoworld (Nov 2, 1981) argued that microcomputers
shouldn't be locked into the "arbitrary" 80x24 size. This led to
angry letters to the editor in Infoworld, Nov 30, 1981, arguing that
80x24 wasn't arbitrary. Writers explained that 80-columns were
motivated by punch cards, 24 (or sometimes 25) lines were motivated
by tradeoffs in CRT technology, and memory size didn't have much to
do with it.

<https://books.google.com/books?id=SD0EAAAAMBAJ&ppis=_c&lpg=PA45 &pg=PA44#v=onepage&q&f=false>

[6]
A detailed source of information on terminals is a 1975 report
Alphanumeric and Graphic CRT Terminals.

<http://bitsavers.org/pdf/ventureDevelCorp/ Alphanumeric_and_Graphic_CRT_Terminals_1975-1980_Nov1975.pdf>

[7]
The CRT's aspect ratio matters less than people think. The first
reason is that even on a CRT with a 4:3 aspect ratio, many terminals
displayed text with a very different aspect ratio by leaving part of
the screen blank. Although most terminals used a CRT with the
standard 4:3 aspect ratio, the actual text could have a very
different aspect ratio. The second reason is that rminals could use a
custom CRT size if they wanted. For instance, the Datapoint 2200 had
an unusually wide CRT, designed to match the shape of a punch card.
(Reference: Datapoint: The lost story of the Texans who invented the
personal computer revolution chapter 4.) The popular Teletype Model
40 also had an unusually wide CRT, with an aspect ratio over 2:1
(photos), which was used for an 80x24 display.

<https://en.wikipedia.org/wiki/Datapoint_2200>

Datapoint: The Lost Story of the Texans Who Invented The Personal
Computer Revolution

<https://amzn.to/2Wv9NBb>

[8]
A raster-scan terminal makes each character out of a matrix of dots.
In 1975, a 5x7 or 7x9 matrix was most common. [6] (The matrix was
often padded with space between characters. For instance, the Apple
II used a 5x7 dot matrix padded to a 7x8 field.) Some systems (such
as IBM's CGA card) used an 8x8 matrix without padding to supporting
graphical characters that touched. Other systems used a much larger
character matrix; the IBM Datamaster used 7x9 characters in a 10x14
field, while the Quotron 800 had a 16x20 matrix. The point is that
80x24 terminals can require a wildly varying number of pixels,
depending on the matrix selected. This is the flaw in the argument
that the bandwidth and scanlines of a display motivated 80x24
terminals; you get a completely different answer depending on the
matrix size you pick.

<http://www.classiccmp.org/cini/pdf/Apple/ Apple%20II%20Reference%20Manual%20-%20Woz.pdf>

[9]
Home computers in the 1980s often used standard NTSC televisions as
displays, so they had to deal with more constraints that terminals.
As a result, they often had 40- or 64-character lines, rather than
80, as shown by the Wikipedia list. Also see a Retrocomputing
StackExchange discussion.

<https://en.wikipedia.org/wiki/
List_of_home_computers_by_video_hardware #The_list_of_home_computers,_and_their_video_capabilities>

<https://retrocomputing.stackexchange.com/questions/6862/ columns-of-text-in-early-microcomputers>

[10]
One Retrocomputing StackExchange answer claims that terminals with
72-character lines show "the struggle for 80 characters", with
72-character terminals falling short of the 80-character goal.
However, 72-character lines were a deliberate choice to capture the
lucrative Teletype market; teleprinters such as the Teletype Model 33
printed 72-character lines. (The model number of the Datapoint 3300
(1969), for instance, reflects the Teletype Model 33.)

<https://retrocomputing.stackexchange.com/a/5634/4158>

<https://en.wikipedia.org/wiki/Datapoint_3300>

[11]
For an extremely detailed look at the terminal industry from 1974 to
1991, see the Datapro reports on Bitsavers. These reports discuss the
overall market, as well as thoroughly describing every terminal being
marketed.

<http://www.bitsavers.org/pdf/datapro>

[12]
AT&T's Teletype Model 40 is mostly forgotten now, but it had a
significant impact at the time. AT&T combined the Model 40 with a
new, faster communications network called "Dataspeed 40", raising
fears that AT&T would monopolize data communications. It is said that
this "spread waves of apprehension that penetrated the very
foundation of the communications terminal industry." AT&T targeted
IBM's 3270 terminals with the Model 40/4 (which probably explains
Model 40's 80x24 display). Complex antitrust litigation against AT&T
resulted, which I think blunted the long-term impact of the Model 40.

<http://www.bitsavers.org/pdf/datapro/datapro_70/ 70D-010-20_All_About_CRT_Display_Terminals_Apr1974.pdf>

<http://www.bitsavers.org/pdf/datapro/alphanumeric_terminals/ Datapro_C25-010_198004.pdf>

[13]
The IBM 2260 terminal reused the keyboard of the IBM 26 keypunch
(1949). To convert a keypress into a hole pattern, the keypunch
keyboard used a complex system of pull-bars, permutation bars (which
encode key values in metal tabs), bails, contacts, interlock disks,
and restoring electromagnet. Each key triggers 12 contacts; in the
keypunch these controlled the 12 holes in each card column, while in
the terminal these encode two 6-bit codes, one for shifted and one
for non-shifted. This mechanism was much more complex than a "modern"
keyboard but it had the advantage of generating key codes without
requiring any electronics. (I've written about keypunch internals
before.)

<http://www.righto.com/2017/12/repairing-1960s-era-ibm-keypunch.html>

[14]
Vector graphics displays predate video terminals by many years, used
on systems such as Whirlwind (1951) and SAGE (1958) and later the IBM
2250 Graphics Display Unit (1964). These systems drew arbitrary lines
on the screen, rather than pixels. Although these systems could
display characters (drawn from line segments), they were very
expensive and usually used for graphics, not as character-based
terminals.

<https://en.wikipedia.org/wiki/IBM_2250>

[15]
The CRT/keyboard unit was called the IBM 2260 Display Station, while
the large cabinet with the circuitry was called the IBM 2848 Display
Control. People often referred to the complete system as the 2260;
I'll follow this usage.

[16]
I'll explain more about the delay line buffers in this footnote. A
delay line provided a bit every 500 nanoseconds. Two delay lines were interleaved in a buffer to provide bits twice as fast: every 250
nanoseconds. Data was formatted as 256 "slots", one per vertical scan
line. (These slots were purely conceptual since the delay line
provided an undifferentiated stream of bits.) 240 slots held data,
while 16 were blank for horizontal retrace time. Each slot held 86
bits: 7 bits for 12 rows of characters, along with two parity bits.
(Since each scan line was split across two displays, the slot
corresponded to 6 characters on the even display and 6 on the odd
display.) Six slots made up a vertical line of characters: one slot
holding the "BCD" character value, and five slots holding pixels.
Thus, each buffer holds data for 480 characters and supported two
40x6 displays. Two buffers supported a pair of 40x12 displays and
four buffers supported a pair of 80x12 displays. Details are in the
2260 Field Engineering Theory of Operation Manual, page 2-14.

<http://www.bitsavers.org/pdf/ibm/2260/
Y27-2046-3_2260_2848_FETOM_Mar68.pdf>

[17]
A delay line can't be paused--the bits keep flowing, even during
vertical and horizontal refresh times. The problem is that you can't
display anything during refresh, since the electron beam is swinging
back to the start, so what do you do with the pixels the display line
provides during that time. The 2260 used two solutions. Horizontal
refresh was straightforward, "wasting" delay line bits during the
horizontal refresh time. Specifically, a pair of buffers held 512
scan lines; 480 were used for character data while 32 were unusable
because horizontal refresh happened while they were being read.


[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 29 Apr 2024 21:23:22 -0000 (UTC), Ben Collver wrote:

The DEC VT100 terminal had an 80x24 display.

So did the VT52 before it. One of the innovations in the VT100 was it also
had a 132-column mode. In this mode, the number of displayable lines
shrank to 14, as I recall; unless you had the extra-cost “AVO” (“Advanced Video Option”) addon, one of the features of which was enough video RAM to keep displaying 24 lines in this mode.

It was not really a comfortable mode to use. I kept thinking something was squeezing my eyes together ...

Punch cards have a longer history than you might think.

Right back to about 1804, in fact. Trivia question: what were they being
used for then?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Collver <bencollver@tilde.pink> wrote at 21:23 this Monday (GMT):

IBM, sonic delay lines, and the history of the 80x24 display
============================================================
by Ken Shirriff

[snip]


Thanks for (re)posting these here! They're interesting reads.
--
user <candycane> is generated from /dev/urandom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-04-30, Dan Espen <dan1espen@gmail.com> wrote:

Ben Collver <bencollver@tilde.pink> writes:

Some theories about the 80x24 and 80x25 sizes
=============================================
Arguments about terminal sizes go back decades, [5] but the article
80x25 presented a detailed and interesting theory. To summarize, it
argued that the 80x25 display was used because it was compatible with
IBM's 80-column punch cards, [1] fits nicely on a TV screen with a
4:3 aspect ratio, and just fit into 2K of RAM. This led to the 80x25
size on terminals such as the DEC VT100 terminal (1978). The VT100's
massive popularity led to it becoming a standard, leading to the
ubiquity of 80x25 terminals. At least that's the theory.

It's always be obvious to me that the PC was 80x25 so that it could accurately emulate a 3270 24 line display.

A 3270 HAS a 25th line where is displays some additional information
like whether the keyboard is locked. There were 24 lines of data and a
25th line for status information.

There's something about that in the comments section of the original
article:

The 3277 didn't have a status line, but three status lights next to the display. It had 24 lines in total. The status line (Operator Information
Area) was introduced in the 3278. This can be verified in the manuals,
which are online at bitsavers.

<http://bitsavers.org/pdf/ibm/3270/>

Also, 3270 emulation was not a requirement or goal for the IBM PC, and
didn't lead to the 25th line. I would much prefer to have a tidy story
where the 3270 led to the PC's display, but unfortunately that's not the
case. I talked to two of the original IBM PC engineers to check on this.
The said the IBM PC team felt absolutely no need to be compatible with
other IBM products. In particular, several features of the PC made 3270 compatibility harder: the use of ASCII instead of EBCDIC, little-endian
words, and 10 function keys instead of 12.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 30 Apr 2024 03:36:51 -0000 (UTC), Ben Collver wrote:

The said the IBM PC team felt absolutely no need to be compatible with
other IBM products.

That in itself would seem to be an IBM tradition ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Collver <bencollver@tilde.pink> wrote or quoted:

One Retrocomputing StackExchange answer claims that terminals with >72-character lines show "the struggle for 80 characters", with
72-character terminals falling short of the 80-character goal.
However, 72-character lines were a deliberate choice to capture the
lucrative Teletype market; teleprinters such as the Teletype Model 33
printed 72-character lines. (The model number of the Datapoint 3300
(1969), for instance, reflects the Teletype Model 33.)

Raymond Hettinger (transcribed, shortened and partially paraphrased
by me [Stefan Ram]):

|The line-width part of PEP 8 bugs me.
|
|You have to wrap your commits in seventy-two characters. You have
|to end your lines at seventy-nine characters.
|
|One time it bugs me is when I'm writing unit tests.
|
|When I write unit tests, I have to start with a class, and then
|inside the class there's a "def" for tests, and then the test
|starts with a "self.assertEqual", and by then most of my line
|is gone. So by the time I get to any business logic in my test,
|I'm near the end of the line.
|
|If I go over seventy-nine characters, somebody will come and
|PEP 8 me.
|
|They'll come in and say: "Oh, Raymond's line hit eighty-one
|characters, I'm going to PEP 8 it!". And so, while I'm not
|looking, they come in and reformat my code.
|
|They'll just throw a line break at a really awkward place.
|
|Does that make the code better?
|
|So, to escape that pressure, I think: Maybe I can just commit
|a little atrocity and that way no one will ever come and PEP 8 me.
|I'll just shorten my variable names.
|
|Does that make the code better?
|
freely adapted from Raymond Hettinger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 30 Apr 2024 15:32:48 -0400, Dan Espen wrote:

I read the tech manual and
decided the IBM 3270 was a piece of junk. The protocol to talk to the
thing was ridiculously complicated.

True of a lot of IBM technology, is my impression. Note that their idea of
a networking architecture, SNA, did not actually support peer-to-peer connections until about the mid-1980s.

Their labs produced a lot of research papers and patents, but it seemed to
me very little of the clever stuff actually made it into their products.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30 Apr 2024 15:55:04 GMT, Stefan Ram wrote:

|You have to wrap your commits in seventy-two characters. You have |to
end your lines at seventy-nine characters.

I typically have my editor window widths set at about 100 characters.
And I use them all.

It is true that, in normal text, short lines are easier to read than
long ones (hence why newspapers have so many columns). But in
programming, a lot of my lines is taken up with indentation. So the
nonblank parts are not necessarily that long. E.g.

scallop = Path \
(
[
Path.Segment
(
points =
(
Path.Point((0, 0), False),
Path.Point
(
pt = Vector(1, 1) * (1 - params["fraction"]) / 2 * step,
off = False
),
Path.Point
(
pt =
Vector(1, 1) * step * params["sharpness"] / 2
+
Vector(1, 1) * 2 * params["depth"] * step_normal,
off = True,
),
Path.Point
(
pt =
Vector(1, 1) * step * (1 - params["sharpness"] / 2)
+
Vector(1, 1) * 2 * params["depth"] * step_normal,
off = True,
),
Path.Point
(
pt = Vector(1, 1) * (1 - (1 - params["fraction"]) / 2) * step,
off = False
),
Path.Point
(
pt = Vector(1, 1) * step,
off = False
)
),
closed = False
)
]
).transform(Matrix.scale(scallop_size))

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-04-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Tue, 30 Apr 2024 15:32:48 -0400, Dan Espen wrote:

I read the tech manual and
decided the IBM 3270 was a piece of junk. The protocol to talk to the
thing was ridiculously complicated.

True of a lot of IBM technology, is my impression. Note that their idea of
a networking architecture, SNA, did not actually support peer-to-peer connections until about the mid-1980s.

Ahhh... Memories.

SNA should not 'appen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-04-30, Stefan Ram <ram@zedat.fu-berlin.de> wrote:

Raymond Hettinger (transcribed, shortened and partially paraphrased
by me [Stefan Ram]):

|The line-width part of PEP 8 bugs me.
|
|You have to wrap your commits in seventy-two characters. You have
|to end your lines at seventy-nine characters.
| ...
|So, to escape that pressure, I think: Maybe I can just commit
|a little atrocity and that way no one will ever come and PEP 8 me.
|I'll just shorten my variable names.
|
|Does that make the code better?

Thanks, that was a fun read.

That makes the code better suited for a more chill community.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-04-30, Dan Espen <dan1espen@gmail.com> wrote:

All true.

The IBM PC was 1981. The IBM 3270 PC was 1983.

It could have been a lucky accident that the 25 line proved useful 2 years later.

The first online system I wrote was for IBM 2260s. After I was done my
boss asked me my opinion of the IBM 3270. I read the tech manual and
decided the IBM 3270 was a piece of junk. The protocol to talk to the
thing was ridiculously complicated.

Interesting! Those were before my time. The original article states
that the Enter key was left over from times when it was too expensive to
stream individual characters between all terminals. So the terminals
were smart enough to collect an entire record of data and send it all in
one batch when the user pressed the Enter key. This made me wonder
about the details. What format did they use to draw a form on the
terminal and define the fields in a record? I bookmarked that for a
later deep dive down the rabbit hole at bitsavers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dan Espen <dan1espen@gmail.com> wrote:

Ben Collver <bencollver@tilde.pink> writes:

Also, 3270 emulation was not a requirement or goal for the IBM PC,
and didn't lead to the 25th line.

All true.

The IBM PC was 1981. The IBM 3270 PC was 1983.

It could have been a lucky accident that the 25 line proved
useful 2 years later.

Knowing IBM, I would say selecting a monitor with 25 lines
was because it was the cheapest option at the time :)

<snip>

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 30 Apr 2024 21:32:12 -0000 (UTC), Ben Collver wrote:

The original article states that the Enter key was left over from times
when it was too expensive to stream individual characters between all terminals.

Funny, users of minicomputers were doing exactly that with ASR-33
teletypes since the early 1960s, if not before.

The Enter key would have come from electric typewriters, where it was
needed because they didn’t have manual carriage-return levers any more.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 30 Apr 2024 20:52:29 -0400, Dan Espen wrote:

It sure looked like IBM refused to release simple solutions because they
were afraid the competition could produce something compatible.

I think Hanlon’s Razor applies: “never attribute to malevolence that which can be explained by stupidity”.

In other words, the complexity comes from Conway’s Law: “any piece of software reflects the organizational structure that produced it”. Or in
more general form, “any engineering endeavour reflects the organizational structure that produced it” (including both software and hardware). So the complexity and inflexibility in IBM’s products comes directly from the labyrinth that was its internal corporate culture.

The S32/S34 line had a nice design until they decided to make it
complicated with the S/38 AS/400 stuff.

System/38 was the first (only?) commercial product that implemented capabilities and also built a database into the OS.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dan Espen <dan1espen@gmail.com> wrote:

It's always be obvious to me that the PC was 80x25 so that it could >accurately emulate a 3270 24 line display.

A 3270 HAS a 25th line where is displays some additional information
like whether the keyboard is locked. There were 24 lines of data and a
25th line for status information.

Yes. 3270 emulation was one of the applications delivered with the machine when it was first introduced, with a coax interface card being available.
It was expected to be one of the major uses of the machine.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)