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)?
[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.
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.
As far as the cost goes, NASA could afford it.
Not only would it be possible, it was, in fact, done. In three different ways.
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.
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.
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.
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.
