Rendering a screen full of text as a video signal required a substantial amount of circuitry, especially in the era before LSI semiconductors. A device to generate display signals for a moderate number of text displays (e.g. 12) could share a lot of circuitry among them, and from my understanding some computers were designed to connect to a number of CRTs. Additionally, common RF modulated broadcast-style video was designed to allow multiple video signals be robustly transmitted over large distances via one simple coax.

If one wanted to have twelve display terminals scattered through a few different rooms, it would seem like having a centralized text display generator which feeds broadcast video to a dozen (possibly disguised) television receivers tuned to different channels could eliminate the need for any of the terminals to include any of the text-rendering circuitry that would be required by conventional serial display terminals, while at the same time offering better performance than serial display terminals could offer.

Did any notable systems or installations exploit the ability of broadcast video technology to multiplex terminal displays?

  • 3
    But you couldn't share circuitry to generate 12 text displays, because the circuitry was already working at the speed limit. Add in the extra effort for the multiplexer and demultiplexer, and it's cheaper (and more flexible) to just combine text generation circuitry with the video display.
    – dirkt
    Jun 5, 2023 at 17:14
  • 1
    @dirkt: Circuitry to show one e.g. 40-column text display would need to fetch 40 bytes in about 40 microseconds, and then use those 40 bytes six more times times over the course of the next six scan lines. Circuitry to show twelve 40-column text displays could simultaneously render all seven scan lines associated with each row, passing six of them through analog delay lines that were 1-6 scan lines long. If the character output rate was 1/60 of the horizontal frequency, the speed of memory that was required would seem like it would be the same as would be needed to handle one display...
    – supercat
    Jun 5, 2023 at 17:51
  • 1
    ...without the analog delay lines.
    – supercat
    Jun 5, 2023 at 17:51
  • 1
    @supercat ‒ aren't you forgetting the character generator? So you'd still need the display memory and the character generator for each channel - unless you wanted all screens to display the same text - and you'd need an extra delay line and lot of extra complexity. Jun 5, 2023 at 17:58
  • 1
    @dirkt: If the character generator were a 64x35 core rope memory, I wouldn't think grabbing all seven rows at once would be much harder than grabbing any one row at a time. One may need seven copies of the circuitry to to serially output the bits for each row, but after that glass delay lines could be used to hold the lower six lines of each character until it was time to display it.
    – supercat
    Jun 5, 2023 at 18:05

3 Answers 3


The closest thing I know of is the IBM 2848 Display Controller in combination with IBM 2260 terminals. The 2848 generated, transmitted and stored video signals for up to 24 terminals. It did, however, not use any broadcast standard ‒ the displays scanned vertically, not horizontally ‒, it did not use RF, and it did so not to save on circuitry, but because the circuitry at the time (1964) was simply too big to go into individual terminals. Instead, you had one big box (5 ft wide, weighing 1000 pounds) sitting somewhere nearby.

More pictures are in Ken Shirriff's article here (scroll down a bit).


Well, if custom build devices also count, I would present the SLS-Guckies :))

It was a quite unusual terminal system custom build based on telephone keyboards and TV sets, build for a none existing in house solution with no budget:))

By the mid 1970s the mainframe service department for Bavaria of a major manufacturer had already outgrown management by paper records, punch cards, card tables and electro-mechanical clocks (*1). So why not using one of the machines they are familiar with? Except, there was no budget and no way to get one the size needed. Getting a machine wasn't an issue as big, as by the mid 1970 early machines low end were already taken out of service - in this case a 4004/15, about the same class as an equivalent of an IBM 360/20, was found. Together with two 7 MiB Disk drives and the usual (dated) peripherals.

A harder to crack issue was the user side as terminals were still a new thing far from being decommissioned. A new mainframe terminal had a price of a basic VW Bug of the same time, so a clear no-go. For programming this was resolved by using the machines console (*2), but a solution was needed for the user side.

At that point it's important that the head of that department was an engineer and tinkerer by heart (*3) well versed in radio/TV technology. He came up with the idea of using an inexpensive TV and phone based solution:

  • A numeric, telephone keyboard based input station.
  • A controller
    • connected as standard blockmux to mainframe channel,
    • forwarding the input to the mainframe
    • receivng output from the mainframe
    • storing that in TV cards
    • which in turn fed modulators connected to coax cables
  • Cheap B&W TV sets.

The first part was based of a (back then) brand new touch tone encoder chip which only has been recently finished at the semiconductor plant in Munich - he had gathered a tube during a visit, which might have been the origin of he whole idea. Those chips scanned a 4x4 keyboards, buffered up to 16 key presses (*4) and released them according to touch tone timing rules. Those chips combined with a 12 key keypad were made into the input devices, connected via a two wire telephone line. Well, also with a cranked up clock, so input was send out at typing speed (*5). The controller would listen to all input channels, collect one message at a time and forward it via a device interrupt to the mainframe. All hard wired TTL logic, no microprocessor involved.

For output purpose there were video buffer boards, one per channel. They were as well build without any microprocessor, but a common set of counters to fill them as well one to generate display. They were based 256x1 static RAM devices building a 768 by 6 memory (*6) and one of those brand new monolithic character generators. A bit like what Wozniak did with the Apple II not much later. Display was 24 lines and 32 characters per line at 50 Hz.

Output of those frame buffers was modulated to a TV channel with up to 16 channels per cable. 'Only' 16 as it had to be within reach of cheap analogue TV of that time. An output message from the mainframe started with an address selecting sub frame and video buffer followed by 768 bytes to be outputted.

One sub frame of the controller consisted of (up to) 32 keyboard input channels and 16 frame buffer cards. Sounds strange, but to increase capacity two users (defined per keyboard) would share one output channel. While high performance users had their own, low thruput users wold share one (*7) It was a great way to keep up with the sudden demand :))

Later one double buffer was added, build from two frame buffers, one supplying the characters, the other adding a colour channel. This was used for a big screen TV to give the call center operators a quick status overview for all open cases.

Bottom Line: Anyway, yes, such stuff was build and I don't think we were the only ones to come up with that idea.

We also tried to sell this to management and marketing as a product idea, but it was flat out rejected every time, as they didn't see a market. After all, 'real' customers wanted 'real' terminals - or possible didn't see the sales bonus generated by selling a solution serving 16 users at the cost of a single terminal :))

The whole setup was not just used until the 1980s when terminals became more affordable, but way into the 1990 (I think it was finally switched of in 1997) as many users wanted to keep their fast little independent Guckies in parallel. By that time it had been extended to three sub frames for 48 output channels (well 47 as the colour screen needed two) and 96 keyboards.

To build all of this he drafted two young engineers to design and build to his idea. One of them was, despite having no formal programming education the best programmer I ever met (*8), who single handily designed the basics for what became one of the largest real time real time applications within the company.

*1 - Even that was a ready a marvel, but that's a different issue.

*2 - It might be important to know that the guys doing this were hardware people and at the time it was strictly forbidden for them to do any programming or even get courses :)) So their base was,'t much how to use a programming environment, but maintenance tools - like patching from the console, so the first program editor was build from patches (the real, hex kind, not source changes) to the OS to add a set of commands that worked like an ED style line editor, which then was used to write the application programs.

*3 - Still today I'm amazed how privileged I was to have learned from that man later on.

*4 - Which is the maximum number of digits a phone number ca have to be routed worldwide, including all escape codes (and yes, I know, this might be relaxed by now).

*5 - Thus all input had to be numeric. Input was terminated by Star (*, caneled by Hash (#)

*6 - 6 bit is more than enough to display all upper case characters, numbers and some symbols, so why spend more?

*7 - think a two desk cubicles sharing a telephone ... yes, that was a common thing in the not so good olde times.

*8 - Again me being the luckiest guy in the universe to have had the chance to work with and learn from for over 20 years. Without, I guess, I would be just an average low payed maintenance engineer firmly believing the C64 is a computer and C a language.

  • 2
    That sounds a lot like what I was envisioning, though I was also curious what efforts had been done to multiplex display circuitry. It sounds like IBM had some ways of multiplexing one display generator to two monitors, each of which could, with the aid of mirrors, serve two people, but I would think that before the advent of monolithic character generators, a character generator that could output all seven scan lines and once, followed by a sequence of analogue delay lines and multiplexing could allow a single character generator to service many displays.
    – supercat
    Jun 6, 2023 at 14:45
  • 2
    Although I didn't mention this as part of the inspiration for this question, I vaguely remember seeing flight displays in an airport in the mid 1970s that looked like black and white TV screens (I don't remember if they had tuning knobs), and wondering why the letters were a bit "dotty" and how they could change instantly without any kind of visible rotation, sliding, etc. Since there were multiple groups of displays, showing the same info, RF modulation would have been a logical way of sharing them.
    – supercat
    Jun 6, 2023 at 15:24
  • 1
    One thing I would have envisioned differently would have been having keyboards connected via current-loop, and keyboards and hosts each having a counter. The keyboard would pass high current except when the counter was zero, or a key identified by the counter was pressed, and while keyboard was passing high current, the host would pulse the current on and off, advancing both host and client counters. A microcomputer could poll counters at any convenient rate slower than the self-count rate. If two consecutive values matched, the microcomputer would observe the value and force a pulse.
    – supercat
    Jun 6, 2023 at 17:10
  • 1
    If the counter stabilizes again at the same value, that would represent a "no keys pressed" state. Otherwise, the difference between a stabilized count and "no keys pressed" would identify a key that was pressed.
    – supercat
    Jun 6, 2023 at 17:12
  • 1
    Believe me, it was way more simple and stable that way. Worked flawless for good 20 years.
    – Raffzahn
    Jun 6, 2023 at 17:45

I think the Knight TV system built at the MIT AI lab fits the bill. A PDP-11 with custom add-on boards generated the video signals for a bunch of regular TV monitors. Separate hardware scanned keyboards.

  • 2
    Do you have any more detailed information?
    – supercat
    Jun 6, 2023 at 17:28
  • 2
    @supercat This has a bit more info. Note "Each of these 16 buffers are now fed into the inputs of the video switch that sends the video signal of every frame buffer to any number of TVs", which probably means each framebuffer had its own video generator - no shared circuitry.
    – dirkt
    Jun 6, 2023 at 17:34

You must log in to answer this question.

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