This source states that introduction of raster graphics display began in mid-1970s only after affordable semiconductor memory had become available on the market.

Would it be at all possible to make a raster graphics display by using the types of memory widely available in early 1970s (ferrite, I guess)?

  • 10
    I think that instead of asking would it be possible (probably, yes,) you should be asking, "what would it cost?" Lots of things are, have been, and will be possible; but there aren't as many things that somebody would be willing to pay for. Jun 17, 2020 at 12:19
  • 5
    I remember reading about a magnetic drum based framebuffer from the late 1960s. There is no technical problem using magnetic drum, delay line or core memory, "just" cost. Jun 17, 2020 at 13:17
  • I thought frame buffers were around a decade or two before that, but maybe frame buffers and raster displays have independent histories... Jun 18, 2020 at 1:41
  • @hippietrail Maybe it's a matter of definition, but doesn't having a (digital) frame buffer always imply a raster display? Jun 18, 2020 at 6:12
  • 1
    @hippietrail Yes, you can have a raster display without a framebuffer -- that's basically analog television --, but you can't have a digital framebuffer without a raster display. You could build an analog framebuffer though, e.g. from a rotating magnetic drum carrying an analog video signal. Jun 18, 2020 at 19:09

5 Answers 5


[Note, this is about raster graphics displays. The situation with raster based text display is similar but different, see below the divider]

This source states that introduction of raster graphics display began in mid-1970s only after affordable semiconductor memory had become available on the market.

True. Alas, one could add some restrictions as raster was tried and done before.

Would it be at all possible to make a raster graphics display by using the types of memory widely available in early 1970s (ferrite, I guess)?

Possible? For sure. Core was fast enough and could be done large enough.

Economic? For sure not.

A raster display needs a storage cell for each and every possible dot to be displayed, whereas a vector display only need to hold two pairs of coordinates for every line that will be displayed. So for example with a diplay of only 256x256 dots, the bitmap will needs 8KiB of core. Doesn't sound much, but then again, in the 60s even mainframes started with RAM of similar size.

A vector display with the same 256x256 addressable locations needs just 4 bytes per line (two if connected) to be displayed- so a grapic with 100 lines (quite a lot on a rough 256x256 screen) will need less than 400 bytes, 1/20th of a similar capable raster display.

But already the very first (widespread, commercial) graphics display, the IBM 2250 of 1964 could address 1024x1024 positions. For a raster display this would mean the needs of one megabit or 128 KiB - keep in mind, the basic model 360/30 was sold with 8 KiB memory and expandable to 64, while the top end 360/50 offered 64-512 KiB.

A vector display in contrast needs for a 1024x1024 position display only 21 bit per data word (display list entry). So a list with 1,000 entries needs only 21 kbit or ~3 KiB storage. These 10,000 entries are good for anywhere between 500 and 1,000 lines on screen. already quite complex and about the same memory as needed for a 80x24 display (~4 KiB including format information).

With using vector instead of raster, memory cost was still a limiting factor, that's why Tektronix could position their storage tube based terminals (4002/4010 series) in 1969/70 as a cheap alternative. By using a storage tube virtually unlimited vectors could be displayed without any RAM to hold them.

So bottom line, it wasn't about technology but cost.

Oh, and on a side note, a vector display line is a line, no matter what angle, on a raster display it's mostly a flight of steps. So raster is inherent ugly. Another reason why vector displays kept being the device used for CAD way until the late 80s. A line was a line and any transformation (rotation, sliding etc) could be done qute fast, as the CPU didn't have to recalculate every pixel, but only start and end of each line, which is a simple 3D to 2D transformation.

Now, for text displays the situation was the same but different. Text is primary defined by the characters to be displayed. For 80x24 this means the need of 1920 character words plus necessary format information, so usually ca 3-4,000 words - words, because at that time using only 7 bit per character was a substantial saving. After having the text in (some) memory, it doesn't really matter if it's displayed as raster or vector. In fact, vector has slight advantages when processing as a character is read once, then displayed and done, essentially lowering speed requirement for RAM by a factor of 8-12. Also, characters drawn in vector again look better on screen than the pixelation a raster display offers. That's why mainframe systems still offered vector based text terminals up to ca. 1980, only to be replaced when raster based systems offered higher resolutions.

  • 1
    "A raster display needs a storage cell for each and every possible dot to be displayed" except for Atari-style "racing the beam". Jun 17, 2020 at 23:13
  • 2
    I was kinda horrified in about 1985 (when I got a VAXstation II) at the amount of memory being "wasted" just on sitting there holding pixels :-) Jun 17, 2020 at 23:34
  • 2
    @another-dave These are terrifying days we live in. XD
    – Vilx-
    Jun 18, 2020 at 6:43
  • 2
    A related note: CAD printing also stuck with large format (as in paper several feet wide) plotters drawing vectors with colored pens on paper long after everyone else had dot matrix and laser printers. The output of those was spectacular at the time.
    – Olivier
    Jun 18, 2020 at 12:45
  • 2
    Similar to why the initial laser printers were so expensive - you needed enough RAM to hold the bitmap representing the page (plus a powerful CPU to manipulate them "fast enough") Jun 18, 2020 at 13:12

Some of NASA's early displays in the control rooms were generated by computers with core memory.

  • A pair of GE 635 computers generated up to 40 channels of telemetry displays at Cape Canaveral. These computers had 2 microsecond ferrite core memory. They were used for launches at Canaveral from 1965 to 1983.

  • During the Apollo program, the displays in the firing rooms at Kennedy were driven by a DDP-224 computer. The DDP-24/224/124 architecture used magnetic core memory.

    For Saturn Vs at Complex 39, one RCA 110A was located in each of the four firing rooms in the Saturn Launch Control Center, which was attached to the Vehicle Assembly Building in which the Saturns would be stacked. Each of four mobile launchers also contained a computer. In addition to the 110As, the firing rooms also had a DDP-224 minicomputer as a display driver for the CRTs showing output data to the engineers, as well as a controller for slides and other visuals.

    Computers in Spaceflight: The NASA Experience, p. 214

As far as the cost goes, NASA could afford it.

  • Ain't that always the case? "Affordable" depends on who's paying. Jun 17, 2020 at 23:27
  • 1
    but were they raster displays (as opposed to vector displays)?
    – davidbak
    Jun 18, 2020 at 23:07

Not only would it be possible, it was, in fact, done. In three different ways.

Magnetic Drum Memory: BRAD and the IBM 1500 Instructional System, 1966

BRAD, the Brookhaven RAster Display, used magnetic drum memory in 1966:

Each [...] console can plot tens of thousands of points, or up to 4000 characters at 30 frames per second. [...]
The technique employed is that of programmatically generating a binary image of the desired display in a computer. The image is written on a rotating drum memory. Independent read heads continuously display the picture, which is generated by swept horizontal lines. A standard TV monitor serves as the display device.

In other words, BRAD implemented dual-ported video memory by using two heads for each track on the drum. The drum could hold more than one track, hence serve more than one terminal. This is reflected in the cost structure - BRAD wasn't cheap:

After an initial display system investment of $50,000, each display, with teletype, cost less than $3,000.

While the article on BRAD appeared in the Communications of the ACM in June 1968, The Froehlich/Kent Encyclopedia of Telecommunications notes that BRAD was introduced in 1966.

In the same year, the IBM 1500 instructional system was first prototyped at an elementary school (!) in as an experiment in computer-assisted teaching. Its terminals also received their video signal from drum memory.

Core Memory: Honeywell DDP-224 based framebuffers, 1970 or earlier

A. Michael Noll at Bell Labs described a raster display based on a magnetic core framebuffer and a Honeywell DDP-224 in 1970:

The scanned image is stored in the core memory of the computer, and software scan conversion is used to convert the rectangular coordinates of a point to the appropriate word and bit in an output display array in core storage. Results thus far indicate that flicker-free displays of large amounts of data are possible with reasonably fast graphical interaction. A scanned image of size 240 X 254 points is displayed at a 30 frame-per-second rate.

DrSheldon pointed out that a similar setup was used at NASA during the Apollo program, i.e., probably predating the Bell Labs setup.

Delay Line Memory: The IBM 2260 video display terminal, 1965

While I could not find a pixel-addressable delay line based display, Ken Shirriff writes that the IBM 2260 video display terminal (or, more precisely, the IBM 2848 Display Control used to drive it) did store the individual pixels of each character, along with its EBCDIC values, on a 50ft sonic delay line, showing that a delay line based frame buffer would have been feasible.

  • 3
    re using two heads on a drum - I assume that's two heads per track. The same arrangement was often used for swapping drums, so that you could write a "page" out at the same time you were reading a "page' in. Jun 18, 2020 at 0:32

Possible, yes. Affordable, no.

The article abstracted here describes a core-based system.


It is comparatively difficult to build core memories that are fast enough to drive a useful raster display. Remember that core memory has to be re-written after being read, as reads effectively erase the memory cell. This memory cycle typically takes several microseconds (and defined the execution speed of most contemporary computers), so it has to satisfy the data required by the display during that cycle time, and additionally is unavailable for use by the computer it's attached to until a blanking period in the raster.

To provide a flicker-free display with a moderately long-persistence phosphor, a CRT has to be refreshed several tens of times a second; broadcast TV settled on 50Hz in Europe and 60Hz in the US. A computer display has relatively free choice of the number of lines and the number of pixels per line; reducing these figures reduces the frequency at which data is needed from the memory, as well as the total amount of memory required.

Assuming a modest 240x128 display at 50Hz, 12-bit memory words, and typical blanking periods, I estimate a 250 kHz memory read speed would be needed to provide one bit per pixel, with the pixels themselves being shifted out of a semiconductor-based register at 3MHz. The framebuffer would require 2.5 kilowords of storage, separate from the main memory of the computer to avoid impeding the latter's performance.

A 4-microsecond memory cycle is indeed achievable with core memory, but it's towards the upper end of the performance curve. This would significantly increase its cost relative to a slower memory, such as that found in the PDP-8/S with an 18-microsecond cycle.

There is the further practical obstacle that a raster display is inherently a single-user device, whereas most computers of the core-memory era were multi-user due to their purchase/rental and running costs. Hence it would have been used only for specialised applications where dedicating such an expensive device to a single user was actually appropriate. Vector-based terminals were more cost-effective in this regard.

  • 2
    Older systems just used longer persisting phosphors so that they could have a very low refresh rate without flicker.
    – user
    Jun 17, 2020 at 15:00
  • @user: I wonder if any systems combined a storage tube, a conventional CRT, and a 45-degree half-silvered mirror? If most screen content was on the storage tube, that would only have to be refreshed once every few minutes, but a conventional CRT would allow parts of the screen content to be readily editable.
    – supercat
    Jun 17, 2020 at 16:27
  • 2
    But see Michael Graf's answer: Rotating magnetic media and delay line memories are well suited for an application that needs the same bits to be continually read and re-read, always in the same order. Jun 17, 2020 at 16:36
  • 1
    @supercat: Having used a Tektronix 4051, I found its storage tube display more than good enough for editing. You can overwrite; deleted characters get overwritten with a block. When it gets too confusing, you let the system redraw. Somehow (by modulating the beam current?) Tektronix even manages to generate a movable cursor, or short non-persistent messages. Definitely not worth the trouble of two tubes and a mirror. Jun 17, 2020 at 20:06
  • 2
    Mainframe core memory of the 60s already worked below the required 4 µs and at 0.9..1.5 µs in the 1970s. There's also no reason to use 12 bit. words. A bitmap buffer word of 18 or 36 bit (16/32 with parity) would be way more appropriate and in fact a standard size of the late 60s. Such a standard stack of 18 planes with 32x32 cores can store a bitmap for a 256x256 display and deliver with a 2µs cycle time. Then again, word size is defined by stack height, which is easy to be customized per application. So no problem to tun this indo astack with 72 planes of 16x16 cores, not only needing 8 µs.
    – Raffzahn
    Jun 17, 2020 at 21:04

You must log in to answer this question.

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