Why did IBM PC have horizontal cursor instead of vertical or block cursor?

Question

Most 8 bit machines, like C-64, seem to have block cursors, while modern user interfaces often have vertical cursors. PC has horizontal cursor of two (or 3) scanlines by default, and block cursor for special cases (such as INSERT mode).

I know this is a feature of video chip, but since it is custom functionality anyways, what would be the reason to choose horizontal vs vertical for this functionality? I'm assuming having thin vertical lines would not be exactly optimal for composite monitors, but was there any other technical or historical reasons for this?

Answer 1

The horizontal-line cursor was standard on the video terminals I used. The DEC VT50/VT52 series of terminals had only an horizontal-line cursor. The VT100 (and, I assume, subsequent terminals) had a user-selectable horizontal-line or block cursor, with as far as I recall the line being the default.

The IBM 3277, a hugely popular block-mode terminal for IBM mainframes, also used a horizontal-line cursor. See page 13 in this user manual.

Thus the answer for "why" is probably "because that was the usual thing".

Answer 2

TL;DR:

Available Hardware + Capabilities + Compatibility + User Expectation

Text mode cursor on PC Hardware allows only a full character cell width cursor that may cover any amount of a character cell height (e.g. anything between a single line and a full block). As that is what the used chip (6845) provided. For anything else a graphics based display and (usually) a GUI is needed.

Further, in an 8 pixel wide charset there is not enough space to add a vertical cursor without degrading readability (*1). It wasn't like with today's high res displays giving 20+ pixels or more per character.

Next, having underline (or block) cursor was the common way since the very first terminal screens. Any user would expect them that way. So why should any chip developer (*2) invest in building a chip to provide a feature not asked for or any computer developer build an additional circuitry to add such- especially for a middle-of-the-road development like the IBM PC?

It wasn't until the GUI invented a new view onto text that a vertical cursor did make sense (*3). Still, any GUI offering a DOS compatible/alike interface (window) will of curse try hard to emulate DOS behaviour as close as possible to provide the expected DOS experience - including the underline cursor.

---

while modern user interfaces often have vertical cursors.

Keyword here is "modern". To my understanding the vertical caret type cursor came only to be with bitmap based video. The basic PC (and DOS) is not of that kind. DOS and all basic DOS applications are character mode.

PC has horizontal cursor of two (or 3) scanlines by default, and block cursor for special cases (such as INSERT mode).

Here "default" is again the keyword. To be as portable as possible DOS tries to expect as little as possible from its underlying hardware. In fact, it does not even assume a cursor to exist. Only by using additional drivers (like ANSI.SYS) cursor handling became a feature for DOS - at least clean ones, not accessing ROM-BIOS or Hardware directly.

Most DOS applications kept it that way, just adding the full cursor shape for insert mode. Anything inbetween wouldn't make much sense, or would it? (*4)

In addition the ability of some applications to change the shape shows that the cursor is software defined. In fact, already the very next BIOS function implemented, right after setting a video mode (Int 10h Function 00h), is setting the text mode cursors attributes: INT 10h Function 01h : Set Text-Mode Cursor Shape. It essentially sets the 6845's registers 10 and 11 directly:

Int 10h
AH = 01h
CH = Mode and Start Line
     Bit 7,6 Cursor Mode
         00 = Steady
         01 = No Cursor
         10 = Fast (flip every 16 frames)
         11 = Slow (Flip every 32 frames ~= once per second)
     Bit 5..1 Top Scan Line of Cursor
CL = End Scan Line
     Bit 5..1 Bottom Scan Line of Cursor

I know this is a feature of video chip, but since it is custom functionality anyways, what would be the reason to choose horizontal vs vertical for this functionality?

First of all, the 6845 does not allow a vertical cursor. While a cursor may cover any number of lines within a character cell, it will always cover the full width. It can be made static or blinking in two speeds (every 16 or 32 frames).

Second, noone was using, even less expecting a vertical cursor on text mode display.

Third, it would have incurred additional hardware cost as providing one would need hardware external to the 6845 controller. For example by

• programming the cursor to be a full block
• but invisible and
• using the raising CURSOR output (pin 19) to
• set a FF, which
• inverts the signal (or simply setting it to full), to be
• reset after one pixel clock.

That means spending (at least) 2-3 TTL chips for a function noone hast asked for in the first place

---

Which leaves two implied questions

[addition#1] Why underline instead of a block cursor

An underline cursor is way less intrusive to reading (and writing) than a block one filling the full character cell. After all, the most common user is not the programmer, constantly searching where he left the cursor last time, but a secretary writing some letter or an accountant filling in order lists. A cursor should thus be notable but not stopping the flow.

It's the very same reason why many professional systems made it static, not blinking at all, making it even less intrusive.

[addition#2] But why do home computers usually have only a single block cursor?

Because it's the most simple way?

In very basic designs, like the Apple II's video or Commodore's VIC (VC20/C64/...) there is no hardware cursor at all, but is done by software constantly replacing the character at the cursors position by it's inverse counterpart and back (commodore) or a blinking version thereof (Apple).

---

*1 - This is especially harmful due the rather vertical nature of Latin script. Adding horizontal lines to Latin glyphs degrade readability less than adding vertical. We tend to interpret and ignore them when reading similar to lines text is written on.

*2 - The 6845 is a chip Motorola developed to simplify the design of a terminal. When introduced in 1975 it was a marvel, incorporating the equivalent of a dozend TTL into a single 40 pin chip, about the same complexity as a CPU. It revolutionized the way terminals were build due it's flexibility. It took the world by storm and by 1980 next to all terminals and many computers (maybe except pure game systems) used a 6845 or one of it's second source or compatible designs like Commodore's 6545.

When a company invests a considerable amount of money in development and production of a high end chip unlike any other, one can be sure they as well did a thruout market research what features customer would want and put them in - if possible.

Since we can agree that a vertical cursor isn't as hard on chip level, it's safe to assume that none of the potential customers they asked, and none of the terminals they looked at, needed that feature.

*2 - Fixed character cell displays are something rather forgotten. Today using a fixed font is a design decision, something handy for working in columns, like with programming, but already spreadsheets use proportional fonts within their cells. But proportional fonts are something that only arrived in common use with graphical interfaces (GUI) around 1980 (Xerox Star Software) for early adopters and during the mid 1990s for PC users at whole .

In fact, it was the proportional font that made the character cell based cursor impractical and rather odd looking as there were no character cells any more - so the cursor would not only have to change in width all the time, but also, what size should it have at the end of a line, when there was no character to go with?

The invention of the vertical cursor is not only made possible by use of GUI, but also was a direct follow up to this development.

*3 - I do remember at least one application using a half height cursor, stretching from the middle line to base line in search mode. This allowed to search for some text without loosing the writing position. Rather handy in the before-mouse-era (and still faster today:)). The same may as well have been used for marking, but it's really a long time ago.

Answer 3

The functionality of chips available at the time and the implementation difficulty certainly were the main factors. But even without those constraints, vertical cursors do not work that well with low resolution monospace fonts:

The question does note that thin vertical bars get blurred on composite monitors. Even with dedicated high-resolution component display, the text cells just don't have enough space for a vertical cursor. Adding extra space between the text cells would reduce the amount of text that can be fit on screen.

Answer 4

I know this is a feature of video chip, but since it is custom functionality anyways, what would be the reason to choose horizontal vs vertical for this functionality?

The MC 6845, which early IBM PC video cards contained, and which then became the basis for the following cards (and you can see even today video hardware that, for compatibility reasons, has the very same register layout somewhere), only allowed you to specify the character scanline where the cursor would start resp. end.

This made for an easy "underscore" and an easy "block" cursor, which is exactly what you observed to be used (the other variants are not that visually appealing).

So it wasn't "custom functionality", they used what hardware functionality they had.

I'm assuming having thin vertical lines would not be exactly optimal for composite monitors

It's also more difficult to implement in hardware. The 6845 went for the easy variant that used less transistors.

---

Why is it more difficult to implement vertical vs horizontal cursor in hardware?

This is due to the way the 6845 works with a character generator. Please read through the datasheet, note the way it interacts with a character ROM (or RAM), and then ask yourself the question what circuitry you need to implement a blinking cursor with start and end scanline, and what circuitry you'd need for a vertical bar (where you'd also have to make a decision where this bar should be displayed - between characters?).

Or maybe you could even use comparator for x axis instead of scanlines?

Note the shift register in the application diagram, note the overall speed of the system (that's why you need a shift register), note that the 6845 works very much on a character-basis, and then think about how you'd integrate your "x axis comparator" into that.

Also think about the advantages to having this already working on the chip, without additional external logic, vs. the complications (and costs) of doing not so, and needing additional glue logic, or more shift registers, etc.

Answer 5

As noted elsewhere, the 6845 video controller as a "cursor" output which active when three conditions apply:

1. The character address being output matches a specified cursor address.

2. A circuit which turns on every time the current scan line within a row (0-7 for CGA, or 0-13 for MDA) matches a programmed "start" value, and off every time it reaches a programmed "end" value, is presently "on".

3. One of four signal sources chosen from (always high, always low, bit 3 of a frame counter, bit 4 of a frame counter) is high.

The 6485 neither knows nor cares what any surrounding circuitry does with this signal. The CGA effectively ANDs it with IIRC bit 4 of an external frame counter of its own that is also used for flashing text, and then uses it to force the state of the output shift register to make all bits opaque. Although the 6845 includes its own blink logic, it needs to be programmed to be "solid on" in order to yield good results with the CGA. Programming the 6845 for a slow flash may yield a cursor whose "on" time is likely to be less than normal by an unpredictable amount (it may be on for anywhere from 0-16 frames every 32).

Some programs exploited the 6845's design by programming the "end" line to be above the "start" line, which has the effect of causing both the top and bottom of each character to be highlighted. Some devices other than the CGA used the cursor output in other ways such as increasing background intensity without forcing the display "solid on" [so as to e.g. yield a slightly illuminated square behind a character] and many others would XOR the cursor signal with the character output, but an opaque underline cursor probably looked better than an xor-based underline cursor would have, while allowing programs to change the cursor shape to indicate editing modes, a feature which I think was used in the built-in Cassette BASIC to indicate insert mode.

Answer 6

I can answer why they don't on pre-PC hardware like Apple II or Atari or Commodore PET/Vic/C64.

Because those platforms don't have hardware cursors. Well, the Atari and C64 have sprites, but they took some RAM and would be odd to use in a text context. Gosh, now that I think about it, why not? Still, weird. And remember on Atari, there isn't a text mode per se, there's a Display List where any line down the screen can be any text or graphic mode. So figuring out where to put that sprite could be complicated.

They also don't have characters in the very limited character set that amount to "every character, plus an underline". What they do have is "every character inverted white on black".

So the easiest way to make a faux cursor was to flip the character between regular and inverted every few hundred milliseconds.

They could have done the same thing, flipping the character between its value and the "_" character, but I've seen that attempted, and it isn't pretty.

Answer 7

The video chip is not custom, it is a stock MC6845, and that's the only cursor it already provides most easily.

And it can provide any height for the cursor, so block cursor is possible if a program sets it. There is a video BIOS interface for that.

So if you ask why the PC had the cursor it has, it's because it uses a stock MC6845 chip and uses the stock features it has.

As the cursor position is held inside the MC6845 and it outputs a separate signal which needs to be externally processsed, like mixed to the video, the simplest way is just to OR the cursor with video data.

To provide anything else than a cursor with a width of a full character, it would require more external circuitry to delay the cursor start by some amount of pixels and have a some amount of pixels width. Even more if settable amount pixels is wanted. Although it might be simplest to trigger a configurable bit pattern out from a shift register instead of implementing counters.

So certainly possible, but not worth the cost or complexity to design and implement a vertical cursor size adjustment.

This applies to text modes only. In graphics modes you are free to implement any cursor you want by drawing it in software.

Answer 8

A really simple answer is that the cursor is being shown in the space between horizontal lines of text that's required to be able to easily read a line of text.

Having a vertical cursor makes it hard to read the text because it makes the pixels of one character merge into another one on a monochrome screen.

The very first CRT displays (and potentially teletypes) seem to use this because it's a trivially easy way to indicate where the cursor is without impacting the text readability. The only user question then becomes "Is the cursor above or below the character", and I've seen both used (cursor above the character and the more common below the character). Can't remember what model I saw it on though. I suspect the cursor below works better for teletypes, but have no proof of it.