19

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?

6
  • 2
    The reason the C64 has a block cursor is it's the easy thing to do on a C64. The same reasoning goes for the ZX's, and all similar machines.
    – Lorraine
    Oct 4, 2022 at 12:52
  • 21
    The vertical bar cursor became popular with the arrival of GUI systems (Lisa and Macintosh, GEM, GEOS, Windows) which use variable-sized fonts and proportional spacing.
    – Nimloth
    Oct 4, 2022 at 13:25
  • 5
    Back in the day when TV monitors were used as display terminals for cheap computers, or the pixel resolution was pushing the bandwidth of monitors, a dot hurled at the screen, at the speed of light would go "splat" or * ;) Vertical bars could get smeared and the horizontal _ symbol was more visible. Oct 5, 2022 at 4:18
  • 1
    I found vertical bars to be almost unusable on VGA graphics. YMMV but that's good enough reason.
    – Joshua
    Oct 5, 2022 at 15:18
  • 2
    I seem to remember what you're calling "vertical cursors" being called the "insertion point". It was a change in UI where it would mean inserting a new letter when you typed - previous (non-GUI) cursors would also sort of select the letter they were on top of and usually overwrite it when you typed. Line vs. block seemed like an earlier thing. Oct 6, 2022 at 15:02

8 Answers 8

30

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".

7
  • 1
    "(and, I assume, subsequent terminals)", You are right, the VT-220 was the same.
    – Lorraine
    Oct 4, 2022 at 12:51
  • 2
    I didn't know terminals had this tradition going on. That would make sense then for "professional computers" to adopt the same look and feel
    – tuomas
    Oct 4, 2022 at 13:03
  • I wonder if any terminals that used an underline cursor used a monitor that was modified to scan button to top? I would think that when designing a terminal with a shift-register-based backing store, generating a cursor at the moment when a character to be updated is fetched from the main backing store to a line buffer would be easier than having to generate a cursor on each scan line of the character row, but if the monitor is right side up, that would yield an over-bar cursor rather than an underline.
    – supercat
    Oct 5, 2022 at 6:07
  • Going back to 1973, DEC made the VT05 terminal. AFAIK, it has a horzontal cursor. There were earlier products in the "glass teletype" class, but they were not from DEC. Oct 6, 2022 at 11:10
  • @WalterMitty - I'm old enough to have used one. Not a good terminal, though, despite the "space-age" case. Oct 6, 2022 at 12:13
19

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.

18
  • 2
    This is backwards. The question is why does the hardware do horizontal rather than vertical.
    – Joshua
    Oct 5, 2022 at 15:16
  • 1
    So why did they design the text mode hardware that way?
    – user253751
    Oct 5, 2022 at 15:24
  • 7
    @tuomas The point is that vertical cursors don't align with the character grid, but go between the characters. The hardware only displayed characters, so it couldn't easily display something between characters. It could, however, replace one of the characters with an underline, of flash back and forth between the character an an underline. Only later did dedicated cursors come around, and so they used the existing way cursors existed. Only in GUIs (with non-fixed width fonts) did they need to come up with a different cursor design. An underline would often be too wide.
    – trlkly
    Oct 5, 2022 at 15:47
  • 1
    @trikly so why can't it flash back and forth between the character and a block?
    – user253751
    Oct 5, 2022 at 15:49
  • 1
    @tuomas In the end the quetsion about why it hasn't been done before GUI is a bit like asking why a coachman uses a rein to steer instead of a much more handy steering wheel.
    – Raffzahn
    Oct 5, 2022 at 16:54
9

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:

Example of different text console cursor styles

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.

7
  • What that image is supposed to simulate? MDA with 9x14 char cell, or EGA with 8x14 char cell, or VGA with 8x16 or 9x16 char cell?
    – Justme
    Oct 5, 2022 at 13:15
  • 1
    @Justme Doesn't really matter, because the 9-wide cells don't use the extra pixel to provide a wider gap before every character. A vertical line in the first column(s) is going to look terrible in any of those modes.
    – TooTea
    Oct 5, 2022 at 14:12
  • For reference, the screenshot I used as the base was 9x16 from some later DOS system, presumably VGA.
    – jpa
    Oct 5, 2022 at 14:17
  • The usability of an insertion point cursor will be dependent upon (1) the amount of extra space above and below each line of text, and (2) a user having some idea of where to look for it. Display systems like the CGA had minimal inter-line spacing, and systems that generally use cursor keys rather than a mouse to set cursor position make it necessary for users to be able to visually find the cursor, without having any advance idea of where it is, before they can know how to move it.
    – supercat
    Oct 5, 2022 at 16:30
  • 1
    @user3840170 Had I pre-applied CRT effects, it would be double-blurred for everyone browsing retrocomputing with Arachne on their IBM PC ;)
    – jpa
    Oct 6, 2022 at 5:47
8

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.

16
  • Why is it more difficult to implement vertical vs horizontal cursor in hardware? Essentially you just need a bitmask for chargen vs comparator for scanline range? Or maybe you could even use comparator for x axis instead of scanlines?
    – tuomas
    Oct 4, 2022 at 13:02
  • 1
    @supercat but then you have the cursor in a fixed position in the character cell. If you want a vertical cursor between characters, then you either have the cursor solidly connecting two characters, or you are restricted to 5-pixel wide characters (3-pixel border). Also, since you either can have the cursor before the character or after the character, you cannot display all n+1 cursor positions for n characters per line, unless you somehow arrange for a "dummy" character. That doesn't mean it's not somehow doable, it's just more effort, and not worth the effort.
    – dirkt
    Oct 5, 2022 at 5:51
  • 1
    @dirkt That is probably a big part of the reason - there simply isn't much space for a vertical cursor in low-resolution monospace text.
    – jpa
    Oct 5, 2022 at 9:52
  • 1
    @another-dave no, the cursor is produced by comparing the character scan line counter with a programmable range. It it completed independent of what is in the character ROM, be it an underline or any other character.
    – dirkt
    Oct 5, 2022 at 12:46
  • 1
    @another-dave there is no "underlining attribute" in the 6845, and again, the hardware cursor doesn't use any attributes. Please do read the datasheet of the 6845, I linked it. It does not work as in the VT100. If you want character attributes, these need external logic independent of the 6845.
    – dirkt
    Oct 6, 2022 at 5:42
3

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.

3
  • 2
    To my understanding the vertical caret type cursor came only to be with bitmap based video. In my experience, the first such cursor was the I-beam input cursor of X Windows, which used different cursors to convey information to the user. Oct 4, 2022 at 17:09
  • 2
    @another-dave: An insertion point is often better than a block cursor or underline when in insert mode, but a block or underline cursor is better when in overwrite mode. In the 1980s, overwrite mode was far more common, so a line cursor made sense.
    – supercat
    Oct 4, 2022 at 17:29
  • Oh, damn. That was supposed to be a comment on @raffzahn's answer (from whence the italicized words came) but I screwed up. Oct 4, 2022 at 22:50
3

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.

1
  • There was plenty of experimentation with things like flipping the character between its value and the "_" character in the high-end top-of-the-shelf graphics in games like Rogue, Nethack, Moria etc. IIRC. Good times.
    – AnoE
    Oct 7, 2022 at 14:36
2

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.

0

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.

4
  • 1
    Teletypes neither had nor needed a cursor, any more than a typewriter had. The positioning is obvious. What software running on teletypes had was a prompt which was displayed when it was the user's turn to type something - exactly as is still done in modern command-line software. Prompts ranged from a simple dot (TOPS-10 monitor) to "READY" followed by a couple of newlines (Dartmouth DTSS). Oct 7, 2022 at 22:23
  • 1
    By weird coincidence, ICL 1900 MOP terminals used a leftward arrow for the command-level prompt; the leftward arrow was an ASCII-1963 character that was replaced by underline in later revisions of the specification. Oct 7, 2022 at 22:25
  • @another-dave You're probably right, but I do have a vague memory of the teletype/printer hooked to our VAX 11/780 that when you typed on it and pressed backspace it would print the _ character so you knew where the cursor was. Maybe a VAX wierdness, or someone did some custom programming??
    – millebi
    Oct 9, 2022 at 16:11
  • Not a "VAX" weirdness, not any DEC I/O device I used. However, it was normal for DEC software to use backspace as delete-last-character, and on hardcopy terminals, deleted characters were echoed between backslashes. So A, B, C, D, backspace, backspace, E would look like ABCD\DC\E. Oct 10, 2022 at 20:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .