Editing Text mode (section)

== Benefits ==
{{refimprove section|date=December 2012}}

The advantages of text modes as compared to graphics modes include lower memory consumption and faster screen manipulation.<ref name="Bosch">{{cite journal|last1=Bosch|first1=Winn L.|title=The Perfect PC|journal=PC Magazine|date=July 1992|volume=11|issue=13|page=186|url=https://books.google.com/books?id=X4152M1DLygC&pg=PA186|access-date=15 December 2015}}</ref>  At the time text terminals were beginning to replace teleprinters in the 1970s, the extremely high cost of [[random-access memory]] in that period made it exorbitantly expensive to install enough memory for a computer to simultaneously store the current value of ''every'' pixel on a screen, to form what would now be called a [[framebuffer]].  Early framebuffers were standalone devices which cost tens of thousands of dollars, in addition to the expense of the advanced high-resolution displays to which they were connected.<ref name="Smith_Page_363">{{cite book |last1=Smith |first1=Alvy Ray |author1-link=Alvy Ray Smith |title=A Biography of the Pixel |date=2021 |publisher=MIT Press |location=Cambridge |isbn=9780262365215 |page=363 |url=https://books.google.com/books?id=1ukGEAAAQBAJ&pg=PA363 |access-date=1 October 2022}} In this book, Smith recalls that his first framebuffer at the [[New York Institute of Technology Computer Graphics Lab]] cost $80,000 in the mid-1970s. It could store a 512 x 512 array of pixels at 256 colors per pixel (that is, 8-bit [[color depth]]). [[Alexander Schure]] soon bought five more framebuffers for the Lab for $60,000 each. The Lab quickly combined its six framebuffers together, in two groups of three each, to create the first two true 24-bit [[RGB color model|RGB color]] framebuffers. Thus, the first had cost $200,000 and the second had cost $180,000; as Smith points out, adjusting for inflation, these numbers add up to roughly $1.7 million in 2021 dollars, which explains why the Lab's researchers were "thrilled" with Schure's generosity.</ref>  For applications that required simple line graphics but for which the expense of a framebuffer could not be justified, [[vector display]]s were a popular workaround.  But there were many computer applications (e.g., data entry into a database) for which all that was required was the ability to render ordinary text in a quick and cost-effective fashion to a [[cathode-ray tube]].

Text mode avoids the problem of expensive memory by having dedicated display hardware re-render each line of text from characters into pixels with ''each'' scan of the screen by the cathode ray.  In turn, the display hardware needs only enough memory to store the pixels equivalent to one line of text (or even less) at a time.  Thus, the computer's [[screen buffer]] only stores and knows about the underlying text characters (hence the name "text mode") and the only location where the actual pixels representing those characters exist as a single unified image is the screen itself, as viewed by the user (thanks to the phenomenon of [[persistence of vision]]).

For example, a screen buffer sufficient to hold a standard grid of 80 by 25 characters requires at least 2,000 bytes.<ref name="Bosch" />  Assuming a [[monochrome monitor|monochrome display]], 8 bits per byte, and a standard size of 8 times 8 bits for each character, a framebuffer large enough to hold every pixel on the resulting screen would require at least 128,000 bits, 16,000 bytes, or just under 16 kilobytes. By the standards of modern computers, these may seem like trivial amounts of memory, but to put them in context, the original [[Apple II]] was released in 1977 with only four kilobytes of memory and a price of $1,300 in U.S. dollars (at a time when the [[minimum wage in the United States]] was only $2.30 per hour). Furthermore, from a business perspective, the [[business case]] for text terminals made no sense unless they could be produced and operated more cheaply than the paper-hungry teleprinters they were supposed to replace.

Another advantage of text mode is that it has relatively low bandwidth requirements in remote terminal use. Thus, a text mode remote terminal can necessarily update the screen much faster than a graphics mode remote terminal linked to the same amount of bandwidth (and in turn will seem more responsive), since the remote server may only need to transmit a few dozen bytes for each screen update in text mode, as opposed to complex raster graphics [[remote procedure call]]s that may require the transmission and rendering of entire [[bitmap]]s.