19

I'm working on an alternate history story in which the protagonists, Silicon Valley computer entrepreneurs, are trying to release a graphical workstation in 1980, with the capability of displaying 640x480, 60 Hz noninterlaced, 64 colors. (Basically in the ballpark of VGA, which was released several years later OTL.)

The electronics side of this would be doable, albeit of course more expensive in terms of memory and bandwidth than a typical display at that time. The key component will be the monitor.

How much would a picture tube capable of such a display cost at that time?

Who would be the most likely supplier capable of providing it? One of the Japanese manufacturers such as Sony or Toshiba?

Edit: Thanks to everyone who has provided references confirming the feasibility of the proposed display. More than one person has correctly commented that the electronics side would be very challenging the way I phrased it. To clarify, the intent is that the machine will have two modes:

  • 640x480 monochrome.

  • 320x240 16 colors from a palette of at least 64, maybe 512 or even 4096 if the required DACs can be made cheap enough.

If I'm calculating it correctly, both of these require 38K of video RAM, which by 1980 standards is generous but within the bounds of practicality.

It's a bit like the Atari ST, released in the mid eighties, where you had a similar choice - but you had to choose at the time you bought the machine. You couldn't switch on the fly. To my way of thinking, this is a really big disadvantage, and if it comes to it, I think it's worth paying four figures for a picture tube that can do both high resolution and color, even if you'll only use one of those capabilities at any given moment.

  • 3
    The monitor probably wouldn't have been the problem (just make the dot mask small enough, analog tubes can handle everything else), the graphics itself would have been difficult: The Hercules monochrome graphics card came out in 1982 and was 720×348 for $500. Multiply VRAM by 6 for 64 colors, and add enough parallel CPU power or some sort of acceleration to draw stuff fast enough at 1980s CPU speeds (even the VGA in 1987 had to use special architecture), and you have what makes the price/performance ratio a bad sell. – dirkt Jun 11 '17 at 18:16
  • 4
    And as another data point: The Apollo DN300 (earlier than 1983, $10.000) used 2 68000 CPUs and had a 17 inch 1024x800 monochrome display. The Apollo DN600 (earlier than 1982, $60.000) had a 19 inch 1024x1024 or 512x512 color display with 4/8/24 planes. So your alternate history is not that alternate, just a few years early. – dirkt Jun 11 '17 at 18:55
  • 3
    And even more data points: (1) Tektronix 4027 Raster Graphics Terminal, 640x350 pixels, pseudocolor, ~$9000 in 1978 or (2) Intergraph monochrome raster graphics terminal, 1280x1024(!), 1980, >$10000(?). – tofro Jun 11 '17 at 19:41
  • 4
    The monitor is unusual because it doesn't use TV (NTSC or PAL) timings, but I think you're under estimating the difficulty making the electronics. Graphics in personal computers in 1980 were constrained by various limitations because of the difficulties involved. The IBM PC's CGA card, released in 1981, was a full length card, too big to fit in most cases today. It only supported 320x200 with 4 colours (or 640x200 with 2) and from a limited palette. You probably couldn't use anything off the shelf, except 16Kx1 DRAM chips. It would probably the size of a PC motherboard just for the graphics. – Ross Ridge Jun 11 '17 at 19:45
  • 4
    I'm not sure the DAC is such a problem for 6-bit colour; with an RGB monitor there's no need ever to intermingle the channels so you're talking about two-bit colour, times three. Resistor ladders would do. If necessary, give the computer separate graphics cards for R, G and B with fixed timings and a shared reset line. The problem parallelises so easily that total cost and the feasibility of putting anything interesting onto the screen in a sensible amount of time are the main burdens, surely? – Tommy Jun 12 '17 at 18:21

10 Answers 10

11

It wouldn't have been outside the realm of consideration at the time, but your guys would face threefold problems in terms of cost and practicality:

  1. As others have stated, the cost of DACs and other high speed circuitry with which to build the image out of memory, especially if you want to combine high horizontal resolution AND high vertical resolution AND a decent scan rate. This is not insurmountable, real-world manufacturers found ways around the issue, but usually with methods that caused their own limitations on video modes.

  2. Ditto, cost and availability of high frequency scanning monitors. The vast majority of everything, even in applications wholly divorced from broadcast video like DEC's terminals, was just based off regular TV innards (either colour or b/w) as they were cheap and plentiful. Which put a hard limit on usable vertical resolution of around 200~240 lines progressive and 400~480 interlaced (for 60hz; 50hz rises to 256~288 and 512~576), and why you see those numbers so often. Bear in mind that 60hz progressive was only really tolerated on medium-persistence-phospor colour monitors because it was the least flickery mode possible on common equipment; 50p was sort of bearable but 50/60hz mode switchers were common on 16-bit computers for more than just the stretched out image height. 60hz interlace was a flickery mess, and 50hz even worse. IBM's MDA was something of a watershed in its introduction of a non-TV-compatible 18khz scan rate and general use of radar-like long-persistence phosphor in the image tubes to make its 50hz scan appear more stable (something they later did with the original XGA, which had an 87hz scan interlaced to 43.5hz effective and would have otherwise been unusable). So if you want to do 640x480 you're going to either have to put up with interlace flicker (how many people used the interlace mode of their Amiga long-term without a flicker fixer and high-frequency monitor? not many...), or have an expensive HF (and probably dual-frequency, which makes it even pricier) monitor, or at least specify long-persistence phosphors for the inside of the tube (which then have their own problem of unavoidable afterglow and "traces" across the screen with any moving image).

  3. MEMORY. RAM was expensive in 1980. 32kb wasn't simply a small indulgence, a luxury paid for by those who wanted a small upgrade to their computer. It was one of if not the most expensive component out of the whole machine, and a prime reason why, at the time, if you had a 16k computer you were quite the flash Harry. Atari, Apple and Commodore's 8-bit offerings offered typically 4 or 8k, the Sinclair ZX80 had just launched with ONE kb onboard (which the ZX81 would then replicate a year later, but with the option of a 16k upgrade cartridge that cost essentially as much as the entire main computer), and 16k wasn't really established as the bare minimum until '81-'82 when that became the baseline for the IBM PC, Sinclair Spectrum, and various other 8-bits... Commodore then causing a riot with the C64 at the end of '82, which they could only afford to do both because the price of memory had taken a severe tumble over the previous 18 months, and also because they owned a chip manufacturer (MOS tech). Giving over a good 32kb to video (which is the more likely thing that anyone trying to make a display of the class you describe would do, instead of 37.5kb - so, the then-common 320x200 and 640x400, not x240 and x480, though there's an alternative in the guise of the wide-pixeled 256x256 and 512x512 modes) would have been unheard of. IBM were pushing the boat out somewhat by cramming 16k onto their CGA board (which seemed a sensible alternative to installing 32k into the PC and then having half of it eaten by video), but their budget offering was the MDA with only 4k.

I mean, it would still have been doable. As others have mentioned, there are existing "graphics workstations" (and more commonly, graphics terminals ) with that kind of definition and memory space. But they were expensive, specialist things. Sort of like the IBM PGC in '82, which was a full-on graphics terminal crammed into a triple-width expansion card, complete with a humongous 320kb RAM... and a $5000+ price tag just for the graphics adapter, never mind the rest of the computer (oh, and the external expansion bay the card had to go in).

Your guys basically are caught in an odd position. On the one hand, the thing you're imagining them "inventing" already existed. On the other, it only exists in the guise of ruinously expensive pieces of niche, technical, corporate (or more likely institutional) equipment. But the price tags on them aren't really all that gougey... a surprisingly large slice of the cost went directly into a) the memory buffers needed to support that large a bitmap (which is why vector based and high-resolution text-mode terminals were about as common - they could give as good a display or better, for the tasks to which they were optimised, as a bitmap model with probably 8~10x the RAM), b) the fancy high-resolution and/or long persistence display needed to display that many raster lines at a high enough speed to avoid flickering, and c) the uncommonly high frequency, wide data path electronics needed to connect the other two components.

...

But, hey, let's think about how the circle can be squared a little.

First up, choice of modes. You've essentially preempted the Atari ST, AT&T 6300, unexpanded EGA card, etc. Or a double RAM, double frequency CGA. But added extra scan lines to make it more VGA (or MDA)-like.

Well, let's say, first step... ditch the extra lines. You don't need that extra 20% height to impress anyone, and if you do, you can compromise on horizontal resolution a little without going full VIC20. So we have modes along the lines of 320x200/640x200 (or 320x400)/640x400 (may as well have the medium-resolution, it can be useful), 288x224/576x224 (or 288x448)/576x448, or 256x256/512x256/512x512, with 4 bits, 2 bits, and 1 bit per pixel, fitting neatly within 32kb in all nine (eleven?) cases. That makes a whole load of things a hell of a lot easier from a 1980 electronics perspective, particularly limiting how many address lines are needed, and keeping a sensible lid on the capacity and number of RAM chips and on the required bandwidth (which also has implications for how fast the memory has to be, and/or how wide a data path you need to pull data out of it quickly).

Next up, the tube itself, or more accurately its drive circuitry. The faster you go, the better quality parts you need in order to deal with maintaining sharp, steady deflection yoke voltage waveforms and stronger drive voltages (including for the electron gun as it needs to be more intense due to moving faster side to side), as well as dealing with the usual effect of higher frequencies in electronics burning more power due to inductive filtering. If we were after full VGA (or PGC) resolution, and that same 60hz refresh rate, we'd need double the normal scan frequency, or about 31khz instead of 15-1/2. And there'd also be the issue of supporting two entirely different scan rates for the high and low line counts, as well as a pretty high pixel clock (25mHz in the VGA and PGC).

However, the limiting of the memory size and thus pixel dimensions has a nice side effect; we don't need to go all the way up to 31k (or the unusually high 36k of the ST's high-resolution which was possibly one reason that the original NEC Multisync tapped out there). Nor will we have to interlace, or have quite as high a pixel clock. We will need to exceed the 18kHz (and 16.3MHz) of MDA, though, and even the 22kHz of both EGA (1984 I think?) and the original Mac and Lisa (also all ~16MHz), because we need a higher line count and/or refresh rate than those variously supported. But, there's a middle ground that is exhibited by a now largely forgotten brace of early to mid-80s computers, especially those hailing from Japan (which needed high bitmap resolution to show Kanji alongside graphics) and 50hz areas (where a slightly less flickery image was desired, in combination with even more scan lines) as well as a lot of arcade machines and the Mac LC... the "25kHz" monitor (actually anywhere from 24.5 to 26.5k IRL, but the name stuck). 1980 is maybe a little early for the introduction of an affordable example of the breed, but, heck, your guys can be the ones to introduce the idea maybe.

25kHz horizontal (nominal...) is just enough to squeeze in 400 active lines at 60hz, with the remainder between that and the 24kHz you might think it'd require disappearing into a fairly minimal blanking and sync/flyback area. You can also get away with a somewhat reduced pixel clock, in the region of 19 to 24MHz depending on how much blanking your horizontal sync circuitry requires. Realistically, though, it's a 21MHz minimum for safety; it might work to go for 21.48M, which is 6x the NTSC colourburst and so part of a fairly common and widely co-opted line of clock crystals, but maybe a cuspier compromise - on the edge of tolerance for everything involved, just from different directions depending on part - to use 20MHz, which would still give as much blanking as VGA and the Amiga or ST on full overscan, and bring it within the spec of a greater range of existing hardware including the very fastest Motorola CRTCs, if used with a set of quick 8-bit shift registers and slightly over-driving some then-cutting-edge 250ns memory chips.

Thing is that then also causes problems if we want to use the lower resolutions with more colours; the lines have to be doubled up (by simply reading the same memory block twice) to preserve the sync rate. Which as it also doubles the necessary pixel clock at the same Hrez defeats the general tactic of having a steady data rate but dividing it up differently, trading off a lower pixel clock for more colour. For example in the CGA and more particularly PCjr we have 14.3MHz for 640x200 in 1bpp, 7.2MHz for 320x200 in 2bpp, and later 3.6MHz for 160x200 in 4bpp. For the ST it's similar with 32/16/8MHz and 640x400/640x200/320x200, with the different syncs required being covered by the requirement to use either two wholly separate monitors, or a multisync (or at least a dual sync, which is what the EGA and MCGA do). Other machines that have varying vertical resolutions but only one hsync rate suffer the same problem, which is why the VGA only has two colour depths (and it depends solely on the Hrez - 4bpp for 640, 8bpp for 320), and the AT&T exhibits similar just at one quarter the depth unless you add an expander card that progressively widens the effective data bus width with every additional 32k bank you install.

So that would make it look like we either need to rearrange the memory to form a wider bus (using a larger number of lower density chips, though our practical minimum is 16x (single-bit) 2kb 4116s anyway; maybe we could use 32x 4108s, which were their half-functional low-cost cousins?), to provide a doubled 320x200 or raw 320x400 in 4bpp, as well as 640x200/400 in 2bpp instead of mono, or that we'd have to provide no better than 4 colours, or opt for an expensive dual-frequency monitor (which, hey, worked for IBM... several years later).

An alternative does exist, however, in the form of installing a line buffer for the 200-line modes. A small 256-byte SRAM (or 512-nibble; preferably 160 or 192-byte/320 or 384-nibble if they exist... or 2x 128-byte in order to give 16-bit transfer, which then could even just be surplus Atari 2600 RIOT chips), either dual ported or double speed with circuitry providing interleaved R/W access, could work as a very high speed FIFO in a chase fashion, with data being written into it at half the speed it's read out on an approx half line delay (so data for the next line starts being written into the buffer just after the second repeat of the previous one starts being read out, and data for the second half finishes just before the first repeat of the next finishes, with the writes being jittered to start slightly earlier or later depending on whether it's an even or odd line). No idea how much it would cost in 1980, but I do know a lot of early micros used SRAM for their main memory instead of DRAM, so adding a quarter K of it shouldn't be prohibitive, and as far as the main data reading circuitry is concerned little has changed... its output is just being switched down a different path on the way to the actual output stage (essentially either going through the buffer, or bypassing it; similarly the output stage receives its data from a different source but one that's still addressed in much the same manner), and the counter that governs when each line starts being read out has its "2" bit flipped on or off dependent on whether the line counter's "1" bit is active.

This is something I've been thinking of as an addition to an imaginary reworking of the Atari STe, and I think the Amiga included something similar in its own video chip (though only buffering a single line, building it up from a combination of bit planes, sprites and copper commands, and using the small dead area where the system was involved with memory refreshing on each line to start reading out the prepared line just before the next one started being built)... though that was itself a somewhat pricey machine in 1985, and IBM never seemed to bother with the idea even in the VGA, even though that could have made for a 640x200 8-bit and a 320x200 direct-colour 16-bit mode as early as 1987, so I do wonder if there's some part of the construction that makes it impractical for 1980.

Anyway ... assuming that CAN be done, and we now have a base system that has sufficient memory, bandwidth, and buffering to be able to squirt data towards a monitor interface stage at a rate of approx 20Mbit/s (400 line unbuffered, 1 or 2 bits in parallel for an effective 20 or 10Mpixel/s switching rate) or even 40Mbit/s (200 line buffered and repeated, 2 or 4 bits in parallel, but the same 20 or 10Mpixel/s final rate). Where are we going to find a 20, or even 10MHz DAC from in 1980? At the basic level, converting binary data into analogue signal levels is a fairly simple affair, you just need a bunch of resistors in a ladder, but you have to make sure they're all switched at exactly the same time and with enough output power to create a relatively sharp edge to each pixel instead of being blurred by inductive filtering inherent to whole run of wiring between the DAC and the electron guns in the monitor (the same thing that puts an upper limit of about 350MHz on even the best VGA cables, and less than 100 on cheap ones or particularly long runs that don't include a booster & resynchroniser box, with everything higher rez than that suffering smearing and ghosting). At the time, there were precious few applications that demanded such a thing and the quality just wasn't there; even for broadcast video, your upper luminance bandwidth might be around 7 to 9MHz (in wholly analogue systems, equivalent to 14-18MHz digital... which itself was still barely managing half that frequency in the main), and colour information languished around the 4MHz realm. Plus with TV images you could get away with, if indeed you didn't straight up prefer, smoothly varying and smudged-together pixels, to give a more natural appearance to images. Great for photos or live video, not so good for sharp text or diagrams. Like the comparison between JPEG/MPEG and GIF.

But, again, we have a fairly simple answer, which was adopted by pretty much every IRL manufacturer of high-ish-end display equipment, including even the non-TV outputs of computers like the BBC Micro and, again, the IBM PC (including with CGA): TTL signalling, in Mono, RGB, RGBI, or RrGgBb mode. That is, we literally just send binary data out of the port, and let the monitor deal with it. With monochrome and straight 8-colour RGB (as used by the BBC, NEC PC88, and a few others), there's not even really anything to decode; the signal received is a simple gate saying "turn the beam on" or "turn the beam off". The signal received is interpreted by a flip-flop transistor gate inside the monitor as being either above a certain voltage threshold ("1", so "on") or below it ("0", so "off") and triggers the appropriate electron gun(s) accordingly, making for a very sharp image even with a relatively fuzzy input signal. So long as it's able to reliably get the output from one state to the other within about half a pixel time, and without too much variation on how long it takes to move from one level to the other, it'll appear on screen with sharp and acceptably straight (in the vertical dimension; the raster beam takes care of the horizontal) edges from one line to the next. Of course, this rather restricts the range of colours we can produce. A monochrome monitor is exactly that - a single beam that's either on or off. RGB colour only offers 8 colours including black and white. No greyscales, no intermediates.

Of course that wasn't really deemed acceptable so a little extra processing was off-boarded to the monitor's drive circuitry, in the form of the "intensity" bit, making most monochrome systems actually 2-bit, and most colour ones 4-bit. It wasn't exactly what you'd call an artist's palette (usually mono monitors only had three levels of brightness; 00 was off, 10 was "on", 11 was "even more on" with the intensity bit causing the beam's drive voltage to be set a bit higher, and 01 caused a cursor-speed blinking effect between normal-voltage on and off... colour used a variation of this where turning intensity on just added about 50% of "normal" voltage to all three guns at once, so you had a bunch of slightly dim primary colours joined by a similar number of slightly desaturated bright pastels, as well as there being two shades of grey below white... IBM opting for a variation on this where non-intensified yellow also had its green channel attenuated by 50% to make brown), but it did the job in an age where any colour at all was pretty good going (and CGA's output was still a little more versatile than, e.g. the analogue output of a Sinclair Spectrum, and it sort-of still worked over composite video even though the actual clarity with colour encoding turned on was rather less than 320 pixels). And you could even get away without needing a palette register, which would either demand extra silicon die area in your custom display chip, or an additional small SRAM on the board; this is the reason why CGA's palettes are so weird - they're the best combinations the designers were able to come up with within the limitation of directly feeding bits from memory into the output drivers; essentially, in low rez, the memory bits go straight into the R and G lines, with B and I being controlled by a combination of the palette choice (4 officially, but a fifth could be glitched in through a certain setting of other registers meant more for use with monochrome composite displays) and a single 4-bit-wide discrete-logic register that controlled the background colour (i.e. what appears when both memory bits are 0). In that way, they avoided having to find space for another 15 or even just 3 4-bit entries. Presumably if they'd had just a little more time, budget, or board space, they'd have included a mode which divided the clock down still further and put either 3 or 4 bits directly onto the RGB or RGBI lines to give a freer choice of colour at the expense of resolution on the TTL monitors (something that can be done over composite, but actually uses a tweaked version of the hi-rez mono mode)...

So if you don't mind losing the ability to choose from 64 colours, you can achieve 16-colour output rather more simply and elegantly by just sending the 4bpp data directly down four wires in the monitor plug, and maybe instead allowing the choice of any 4 of those 16 in the medium resolution modes (particularly useful to have 4 greyscales, 3 plus a highlight colour, or B/W plus 2 highlights, which is what a lot of interfaces on the ST and Amiga did in their 640x200 4c modes) with a relatively simple 4x4 bit SRAM or other register. Monochrome would most likely use a fifth wire, or re-use one (or two, in medrez or in a hirez text mode - possible, as demonstrated with the MDA and many older terminals, because pulling a character out of ROM at the same time as setting a few attribute bits for the whole cell is more practical than trying to do the whole thing as a bitmap) of the existing ones alongside a simpler signal wire that sets the monitor into mono or colour mode. Actual monochrome monitors of course could follow AT&T's example of, instead of operating exclusively in on/off (plus optional intensity) mode, being able to interpret incoming colour data into 4, 8 or 16 greyscales - which still needs a DAC tied to the electron gun, but it's a) only working on one channel, and b) has a much more direct line to the driven load, so can be engineered specifically to work well with it and doesn't have to deal with all the extra impedence of the wires between it and the video card.

If the 64-colour thing is a absolute deal-breaker for you, then you can go with the EGA setup; two wires per colour channel, essentially making each one into a separate monochrome TTL system, but in this case each bit contributes a certain amount of voltage to the connected gun (ie we have three very simple 2-bit DACs in the monitor, splitting the difference between the true monochrome or the RGBI systems which were on/off with a booster, and the multilevel monochrome reinterpretation of colour input), one twice that of the other, so it's either off, 33%, 67% or 100% - though each could still be quite discriminate over its own input and still produce a pretty sharp pixel without much blurring due to the cable. It's about the practical limit for TTL signalling, so for 1980 it'd be on the bleeding edge and you'd be unlikely to do better without brewing up your own high-speed, high-output DACs to connect to an analogue RGB monitor. You'd have a small advantage over EGA at least; whilst you'd still need a 16x6 register (or a 16x8 SRAM with two bits unused for each colour), and 6 lines in the cable (all being simple, robust TTL), you wouldn't need the additional circuitry the monitor contained to not only switch frequencies, but also change its colour mode according to said frequency... each EGA monitor contained both RrGgBb decoding circuitry, but also an RGBI stage, which emulated the CGA behaviour by putting certain bit patterns onto the RrGgBb part. For a connected monochrome monitor, we'd likely do away with the 64-colour palette and just use 4 (or 2, or 1) of the wires as straight intensity. Picking 16 greyscales out of 64 isn't the most useful thing in the world unless you really like doing smooth fades between different screens in your software, and even with only 16 greys you can produce remarkably photographic images with a bit of dithering, same as you can do the same for colour with only 4096 colours (and do an OK job with 64, though being limited to 16 out of those, or just 4 greys, does hamper you somewhat).

The last unspoken thing is actually having enough storage and processing power in your machine to deal with those high colour, high rez displays. It didn't really become practical to move beyond the CGA or even C64 (which is only 8kb per screen) level until proper 16-bit processors (like 7~8MHz 68000 or 8086, not the 5MHz 8088 of the PC and certainly not the 1-2MHz 6502s or 3-4MHz Z80s that would be your 1980 targets), large amounts of system RAM (at least 128k, preferably 256 or 512, as per the Mac and original design layouts of the Amiga and ST, and the base level of most XTs and juiced-up PC/XT clones), and guaranteed floppy disc availability for storage (again, that's about 1982/83 onwards, with the arrival of the XT, as Cassette was still an option for the PC). You just need too much processor time, and too much backing store (and bandwidth of such) plus temporary memory space to hold and manipulate the graphics. A halfway house could be stringy floppies (i.e. high speed medium capacity endless loop tapes) and putting twice as much memory on the video system itself to allow multiple pages, or just allowing a reduction in colour depth in the lower resolutions to allow double buffering within the 32k - or, most particularly, building in a character-based (ie, text) mode, which for any application that's mainly text rather than graphics focussed can offer a huge saving in terms of memory and bandwidth (e.g. the MDA has a quarter the memory of CGA, but it can produce the exact same amount of text in terms of characters x rows, and does so with higher quality, smoother looking lettering as the character cells are 9x14 pixels instead of 8x8, making for a total of approx twice as many pixels painted to the screen; thus, about an 8x saving)... you're likely going to want to include a character ROM of some kind anyway so it doesn't have to be loaded from disc into RAM each time, and the output will almost certainly be mediated by some kind of CRTC (which can do graphics, but would have almost certainly have been mainly engineered for text mode output), so the majority of the work will have been done for you, so you just need to set up the alternative way of addressing and translating memory.

But on the whole, what we're looking at here is something that would be installed into a minicomputer or a professional/institutional rackmount micro, such as the DEC PDP series, rather than something that's going to go into the home, or even into a premium professional desktop machine. All up I'd be surprised if you could put the entire system together for less than $10,000 in 1980 dollars, which would get you a pretty nice car at the time. You'd have to have been extremely committed to high quality computer graphics to consider buying such a thing.

I mean, maybe that's your protagonists' intended market. But like I said, if that's the case, there were already competing systems with similar specifications out there. They'd not have been so much inventing anything, instead they'd have had to try and undercut the existing big players with some kind of innovation that meant they could do everything for a much lower price. Like, less Apple or Intel, more Commodore/MOS...

  • 1
    Expanding on your comments about the costs (at least at retail) of everything involved: 250ns 16K DRAMs were approximately $8 per chip, so framebuffer memory is going to cost about $128, which isn't exactly expensive; your 320x200x6-bit mode with an SRAM buffer gives you a 10MHz pixel clock = 7.5MB/s access rate = 133ns if you use 16-bit wide memory or 66ns if you use 8-bit wide. 70ns static RAM was available at about $5/kbit (that's based on 2147-type chips which are 4Kx1 bit, smaller and wider chips may have cost more), but I haven't found a retail price for anything faster than that. – Jules Jul 18 '18 at 23:46
  • 1
    CRT controller chips would be an issue - the fastest I know that was available at the time was the MC68B45, which was 2MHz max, so couldn't have managed a 20MHz pixel clock. As to target system types: they may not have made it into popular consumer oriented systems, but 8MHz 8086 systems based the S100 bus were available, reasonably priced, and would have been ideal for a display of the type described. E.g. looking through the December 1980 Byte, I find an S100 CPU + IO board set for $600, including operating system (which, amusingly, is SCP 86-DOS). Full systems would have cost $1500-$2000. – Jules Jul 19 '18 at 0:09
  • 1
    Bear in mind any price that isn't specifically 1979/80 isn't going to be relevant in this case given how much the cost per byte fell over the next few years; by 1985, Atari could offer a 1MB machine for under $1000 and a 512k for under $700 (having given up on their initial idea for 128 and 256k models, as the divebombing cost of RAM made them economically pointless) and that was major news at the time. The C64 in 1982 was the first time that a 64k machine was at all affordable - still $600 on launch day (suggesting 32k = approx $150?) vs the ~$250, 5k VIC20 with otherwise similar architecture – tahrey Jul 26 '18 at 12:29
  • 1
    As for the SRAMs, I wonder even who had a use for something that fast in 1980? That's enough to run happily in a 16, even 32MHz system. Processors and buses of that high speed simply didn't exist outside of minicomputers and mainframes. Suspicious. You don't need anything nearly as fast to make a contemporary 80-column display because you take wider bitdepth data from memory at a low speed and then dump it into a shift register that runs at the target frequency (in fact, I've since learned of early-80s Japanese machines that produced hi-rez 3-bit RGB by running three such systems in parallel) – tahrey Jul 26 '18 at 12:34
  • 1
    Regarding CRTCs, you've hit a common confusion. Their rated frequency is character rate; they don't generate video themselves, merely act as address counters and sync sources. You divide the clock by however many pixels wide your character cells are, feed that into the CRTC, then independently count through pixel positions read from the ROM (and/or add in blank spaces between cells, etc), change colours according to cell attributes etc, just using the CRTC output as a coarse pointer. In graphics modes, a cell is usually set as 8 or 16 pixels, so 2MHz is ample (20MHz pixels / 16 = 1.25MHz). – tahrey Jul 26 '18 at 12:40
15

Well Cromenco have something on page 2 of this issue of byte. https://archive.org/stream/byte-magazine-1980-11/1980_11_BYTE_05-11_High-Resolution_Graphics#page/n1/mode/2up 756x482 in 16 colors, and on page 70ish there's an article which talks about max raster screen resolutions of 1024x1024.

Also worth looking at is the HP9845C with a cost of $39,500 according to Wikipedia and a screen resolution of 560x455.

  • 2
    The Cromemco SDI graphics card used NTSC timings though. You can read a bit more about here: en.wikipedia.org/wiki/Cromemco_Dazzler#Super_Dazzler – Ross Ridge Jun 11 '17 at 22:27
  • 4
    I picked on it as an example (that particular byte issue is all about hi-res graphics) just to show that it wasn't out of range for 1980. – PeterI Jun 11 '17 at 22:38
  • 1
    What a blast from the past! I started paging through that Byte issue and found, among other things, a very early ad for Vedit - which I still use today (well, the Windows version supporting multi-gigabyte files, but still called Vedit and in many ways the same). And plenty of other products and companies that have long since disappeared. 10 Meg. hard drives. Heathkit. CompuPro. MicroPro. etc. etc. etc. Memories... (not just RAM) – manassehkatz-Reinstate Monica Jul 18 '18 at 18:33
11

You probably should cut down the resolution to 512x512. I actually worked with a graphics processing system (Earthviews by DBA Systems with the added AIMS (Advanced Image Management System) software). It was designed in the late 1970s, which is just before the time frame you mention. It had two monitors. One was the primary, a serial terminal used for control and text output, and the satellite imagery was displayed on the 512x512 by 16k color monitor, interlaced. It had 16-bit/pixel graphics memory with two bits used for overlay. It used a DEC LSI 11/73 CPU and had 128 kwords program memory. (DEC spec'ed everything for this series in 16-bit words rather than 8-bit bytes, to match the CPU registers.) IIRC, there were four, large graphics memory cards with 16 kbytes on each.

I'm not sure 640x480 @ 60 Hz non-interlaced color monitors were available yet. But maybe this is what your engineers were developing. 1980 was still the analog monitor era, which actually helps in color depth. The monitor wouldn't care whether the video DAC(s) were being fed 6-, 8-, or 24-bit color. Separate RGB signal jacks were common (with separate video DACs), so your 64-color display is very conservative. That would be the R, G, and B DACs being fed 2-bits/pixel/ each. You might as well go for 18-bit "true color" (oh, marketing! 😉), with 6-bits/pixel/color.

10

CRT in IBM 3279 terminal was capable of 640x480 at 72 Hz (p. 85 of maint. manual) in 1980. Relevant IBM SJ article ("Digital System for Convergence of Three-Beam High-Resolution Color Data Displays") is paywalled, and maintenance manual doesn't seem to mention CRT manufacturer; terminal itself sold over $1000 (via http://terminals-wiki.org/wiki/index.php/IBM_3279).

Another (also paywalled) article that could help you: A New High-Resolution Trinitron Color Picture Tube for Display Application. (IEEE Transactions on Consumer Electronics, Volume 26 Issue 3, August 1980).

9

The monitor would be relatively easy to create.

Just make the dot mask small enough, analog tubes can handle everything else – dirkt

The problem is the sheer amount of circuitry required to generate this much graphics, or rather the price thereof.

  • The Hercules monochrome graphics card came out in 1982 and was 720×348 for $500. – dirkt

  • Tektronix 4027 Raster Graphics Terminal, 640x350 pixels, pseudocolor, ~$9000 in 1978. – tofro

  • Intergraph monochrome raster graphics terminal, 1280x1024(!), 1980, >$10000(?). – tofro

  • The Apollo DN300 (earlier than 1983, $10.000) used 2 68000 CPUs and had a 17 inch 1024x800 monochrome display. – dirkt

  • The Apollo DN600 (earlier than 1982, $60.000) had a 19 inch 1024x1024 or 512x512 color display with 4/8/24 planes. – dirkt

The first and second are the only ones that come close to the four-figure price that you wanted. As the Tektronix 4027 has a "pseudocolour" display (a term I don't understand the meaning of), I don't want to work with it - beside the fact that there is not much room for development created by the $9000 price.

The Hercules card currently processes 250560 monochrome pixels (31320 bytes) per frame at 50Hz,[3] for a total of 1566000 bytes per second. It needs to process 307200 16-bit colour pixels (minimum of 153600 bytes) per frame at 60Hz, for a total of 9216000 bytes per second.

This is ignoring the complexity involved in a graphics card that supports both monochrome and colour - this revision of the answer will assume that Handwavium Corp™ have solved this problem.

RAM is an issue. 9216000 bytes per second is massive.

You probably couldn't use anything off the shelf, except 16Kx1 DRAM chips. It would probably the size of a PC motherboard just for the graphics. – Ross Ridge

DRAM in 1980 had speeds of 13MiB per second.[1] The graphics card would need to use 9000KiB per second. This is over two-thirds of the available RAM time - there is not a chance that the CPU can render even a hard-coded screen in that time. In order to make this work, the CPU would have to be able to access the non-graphics RAM much more often than this via some sort of addressing filter, but the code running on the CPU would have to be trusted to get its timing right much, much more than in other machines as it wouldn't be able to automatically wait for the video memory to be free. Alternatively, there could be a separate system for addressing video memory, but this would mean that standard processors could not be used, bringing up the price massively. The video data could be interleaved between different RAM chips and their cycles could be offset for the rendering period, allowing the graphics card to effectively double, triple or quadruple the amount of RAM bandwidth available to it; this would require substantial modifications to the RAM addressing system and likely very substantial modifications to the graphics card, meaning that we might as well design our own from scratch. I don't know enough to say how feasible this last option is, but as far as I know it has never been done (which says a lot).

The problem parallelises so easily that total cost and the feasibility of putting anything interesting onto the screen in a sensible amount of time are the main burdens, surely? – Tommy

There is another option. In 1980, IBM Research invented Video RAM: a relatively cheap RAM that allowed a graphics card to read from it at the same time as the CPU was performing I/O on it, completely asynchronously.[2] There is a catch, however. It wasn't patented until 1985. This is a really, really big problem, as its existence wouldn't have been publicly accessible knowledge until the patent application was filed in 1982.[4] In order to make use of this, you would have had to have been owed a significant favour by somebody very high up in IBM. As an author you could arrange this, but in reality this would probably never have happened - the technology was just too valuable.

The first commercial use of VRAM was in a high-resolution graphics adapter introduced in 1986 by IBM for the PC/RT system, which set a new standard for graphics displays. – Wikipedia

There are still other problems left to solve. A back-of-the-envelope calculations says that Austin Semiconductor Inc.'s 70ns VRAM could perform a maximum of 7.3 DRAM Mibioperations/sec with 16-bit words,[5] giving a maximum of 14.7MiB per second - only just enough to write a hard-coded graphic to the video memory per frame. This is certainly not enough leeway to generate a graphical display.

Add enough parallel CPU power or some sort of acceleration to draw stuff fast enough at 1980s CPU speeds (even the VGA in 1987 had to use special architecture), and you have what makes the price/performance ratio a bad sell. – dirkt

In order to do this, you will need at least two CPUs - one for each half of the screen. Each graphical CPU will have to have separate addressing systems for separate VRAM chips, with a time-shared RAM chip that they can use to communicate. Luckily, Handwavium Corp™ have provided a temporary solution to this problem.

Unfortunately, there are still problems with the graphics card.

Graphics in personal computers in 1980 were constrained by various limitations because of the difficulties involved. The IBM PC's CGA card, released in 1981, was a full length card, too big to fit in most cases today. It only supported 320x200 with 4 colours (or 640x200 with 2) and from a limited palette. – Ross Ridge

Popular television protocols NTSC and PAL transmitted the colour as an analogue signal with a brightness value (for compatibility with monochrome televisions) and colour values. To produce these, DACs needed to be used.

DACs were a limiting factor on a lot of technology in the 80's. The 28 MHz RAMDAC in IBM's 1987 VGA card only supported 6-bit colour. Some early CD players, which only needed 44.1 KHz DACs, only used 14-bit DACs to save money, and sometimes only one shared between both left and right channels. You only need 2-bit DACs but you need them to work at 25 MHz, which I suspect wasn't available as a cheap single chip solution in 1980. Still very much possible, just not necessarily cheap and easy. – Ross Ridge

However, this is a workstation, not a home computer - a dedicated monitor can be used instead.

I'm not sure the DAC is such a problem for 6-bit colour; with an RGB monitor there's no need ever to intermingle the channels so you're talking about two-bit colour, times three. Resistor ladders would do. If necessary, give the computer separate graphics cards for R, G and B with fixed timings and a shared reset line. – Tommy

This system would be possible to create using the technology existing in 1980. However, it would be difficult to do so without going above the $10000 mark.

  • 1
    Despite losing the original version of this answer to the bit-bucket yesterday, I am really pleased with it. Special thanks to dirkt, tofro, Ross Ridge and Tommy for posting a substantive amount of information in the comments. – wizzwizz4 Jun 13 '17 at 20:21
  • 1
    "This is over two-thirds of the available RAM time - there is not a chance that the CPU can render even a hard-coded screen in that time." So without a second page of RAM or otherwise a way to double-buffer, there will be some tearing. This isn't a big problem, at least if the image is relatively static like for desktop publishing, image editing, etc. – snips-n-snails Jun 13 '17 at 21:14
  • 1
    @trall There will be an effective refresh rate of 30Hz for a hard-coded screen, and even then there will be some tearing as less than half of the screen can be drawn in a 60Hz timeframe. – wizzwizz4 Jun 14 '17 at 6:12
  • 2
    RAM bandwidth is only a problem if you are writing serially. This is easy to speed up by writing in parallel. Which is exactly what the VGA does, BTW. Another option is to use a second processor to do the writing to VRAM, either a normal CPU, something build discrete or something like the uPD7220 (from 1982). So there are various ways around this problem. – dirkt Jun 19 '17 at 16:27
  • 2
    @dirkt: Writing things in parallel is only helpful if the data paths are placed properly to accomplish what needs to be done. The unusual architecture of the VGA works out well for some access patterns, but offers far less advantage for others. Writes could be accelerated, easily, in ways that reads could not, but the only way to exploit the VGA architecture was with CPU-driven read/modify/write sequences. – supercat Jun 19 '17 at 19:43
8

Television production facilities had equipment with resolution even better than described. The Doctor Who story "The Leisure Hive", broadcast in August 1980, made use of a video processing system called Quantel which could import and export full video-quality images and process them in arbitrary fashion. I don't know whether the system could operate in anything resembling real time, or if it needed to capture individual frames from an analogue video disk, process them, and then later write them back to an analogue video disk, but could certainly achieve the described level of resolution.

Almost any desired level of graphical resolution can be achieved by adding parallel RAM banks, and the cost would be essentially proportional to the amount of memory required. The tricky issue is figuring out how fast things would need to be to be usable. A useful approach, which I've read of some systems using, is to have a system overlay a high-resolution low-color (e.g. 3 colors plus transparent) image on a lower-resolution higher-color image. That would allow an operator to have a responsive user interface while selecting operations to be performed on an image, even if performing operations on the actual color image might take a few seconds.

  • 1
    A Quantel Paintbox couldn't do real-time video playback. It had to chug for a bit loading and saving video frames to disk. So if you wanted to paint a laser blast on some footage, you would draw on the first frame, wait for a while to go to the next frame, etc., then lay it off to tape to see a playback of the result in real-time. But the actual interactive UI was real-time -- it just didn't have enough RAM to hold a whole video sequence in memory. Playing a game on it would have worked fine in terms of framebuffer performance. (It just cost $150,000, so there weren't any games for it!) – wrosecrans Jul 27 '18 at 22:44
  • 1
    @wrosecrans - "It just cost $150,000, so there weren't any games for it" ... that doesn't necessarily follow. The PDP-1 cost more than that in inflation-adjusted dollars, but there were games written for it. – Jules Jul 28 '18 at 11:51
  • 1
    @wrosecrans: Would the Quantel have been used to generate record at a time onto tape, or would an intervening video disk of some form have been required? I've seen pencil and paper animators using a frame-at-a-time video recorder, but such equipment is very specialized. – supercat Jul 28 '18 at 19:46
7

If you target any of the following resolutions:

  • 640 x 480i 60Hz
  • 640 x 240 30Hz (yes that's weird but you might find a use for it)
  • 320 x 240 30Hz

...then you don't need a fancy monitor, you can use any NTSC colour TV. Customers will love the convenience of that. Of course you'd have to switch it to 50/25Hz to sell it in Europe/Australia where they had PAL TVs.

Most computers of the era didn't have enough RAM to do much with bitmaps that large, but people did come up with all kinds of clever ways in the 70s and 80s to use displays that had more pixels than their video cards (and sometimes their entire systems) had bytes. Rendering images one line at a time while the previous line is drawn so the computer never has to remember more than one or two lines, composing images out of pieces stored in a font buffer, etc.

  • 3
    @rwallace, there was a big difference between feeding the video signal directly to a TV studio monitor and feeding it through one of those cheap RF Modulator boxes to a consumer-grade television set. – Solomon Slow Jun 12 '17 at 19:46
  • 1
    That's a fair point, @rwallace. I imagine a 1980 TV CRT would be kinda fuzzy - not the sharpness you'd get from a 90s PC monitor CRT. – Robyn Jun 13 '17 at 11:59
  • 1
    Note that because of overscan and the lines lost due to vertical blanking, actually displaying a full 640x480 image on an NTSC TV would not be particularly helpful (with an effective maximum resolution of 702x483 but ~5% of the displayed image being lost to overscan on each edge, you have an actually useful resolution of 630x430). The situation is a little better for PAL displays (with 625 lines and 49 lost to vertical blanking, and slightly higher horizontal resolution so 720x576, so after overscan you get ~648x518). – Jules Jul 4 '17 at 9:42
  • 1
    Most home computers of the era basically used the same hardware that would be needed for the 320x240 option as presented, albeit usually with 16 fixed colours rather than the 64-colour variable palette OP describes. But they didn't fill the screen, instead just presenting a window inside that area, and filling outside with a solid colour, often with a resolution of 256x192 (in order to make it a convenient power-of-2 size). This way, they avoided the issues of overscan and didn't have people making software that some users couldn't see all of. – Jules Jul 4 '17 at 9:55
  • 1
    NB to clear up any confusion, home computers generally used a 50 or 60Hz progressive output - NOT 25 or 30Hz. Essentially, they output a string of fields structured almost identically to the first of an interlaced pair, except the last scanline was the same as that of the second field. In that way, the lines of each output field directly overlaid those of the last, instead of fitting in-between them; the familiar "scanlined", low-flicker progressive image is the result, instead of a potentially more flickery, non-scanlined interlaced image. 80col was fine on a 15khz monitor; >256 line wasn't. – tahrey Jul 26 '18 at 12:57
4

You could buy such a system off the shelf in (late) 1980. You needed a large-ish S-100 machine like a Horizon, and a couple of MicroAngelo cards.

Each card held a single bitplane of 512 by 480. You could add more cards, one for each bitplane. The data was then read in parallel across the cards to make a multi-bit value, and then that color was displayed for that pixel.

So for your example you need a system with six cards to make 2^6 = 64 colors. The system could use any number of cards, from 1 to 8 cards, with a maximum of 256 colors. 64 was not a problem.

These systems were widely used for making television graphics well into the mid/late-1980s.

2

It's a few years later (1985 for the Original Chipset) but Amigas could display 640x256 or 640x512 interlaced on a normal PAL/NTSC TV (per Robyn's answer). Later ones managed SVGA.

You needed a pretty clear TV to actually see any detail (and interlaced flickered like hell) but it's not outside the realms of 1980 tech.

1

I had friends who worked with a system kind of like that in a computer science lab sometime in the early '80s. I don't remember many details other than that the thing had 16 bits per pixel (5 red, 5 green, 5 blue, and 1 alpha), and it was interlaced. The alpha was because it had a video input, and it was capable of syncing with, and adding graphic overlays to a live video signal.

Since it basically was professional video equipment, they used a professional video monitor made by Sony corp to display the output.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.