What was the first OS with the type-ahead capability from a dumb terminal?

Question

In a command-line environment of a contemporary Unix-like system, it is possible to "type ahead", that is, for example, to start a process which runs for a while and does not require any console input, and to type the next shell command while the process is running, including Enter, so that the shell will execute that next command as soon as the currently running process finishes, because the OS would buffer the input even though there was no application waiting for that input while it was keyed in.

That feature was not universal; for example, MS DOS did not have it, as far as I remember.

Which OS featured the type-ahead capability the earliest?

In more detail, this is the desired scenario, in "pseudocode":

[some kind of prompt from the OS or an application] RUN PROGRAM 1 [Enter]
[while the calculation is running, unprompted, may or may not be echoed] RUN PROGRAM 2 [Enter]
[the user goes away for quite a while; after returning, they may see...]
[output from PROGRAM 1]
[optionally, a prompt and (re-)echoed "RUN PROGRAM 2"]
[output from PROGRAM 2]
[a prompt]

Answer 1

Multics, the predecessor to Unix, had type-ahead. It was initially released in 1969. The most common terminal in the beginning was the IBM 2741, but the standard 2741 would lock the keyboard after a carriage return. 2741s for Multics had an extra switch to disable this feature, allowing type-ahead.

Multics also supported model 37 Teletypes, which needed no special modification, as the keyboard and printer were essentially independent mechanisms with no logical connection within the device.

Answer 2

MS-DOS did not have a type-ahead feature, because that function was provided by the BIOS. A typical PC BIOS had a 15 or 16 character typeahead buffer, where keystrokes would be queued until something (perhaps the next DOS prompt) asked to read more. This buffer was a limited size and would typically cause a "beep" if you typed another key after it was full.

Earlier, there were add-on devices for the Apple II that added this functionality. I remember using one called an "Enhancer II" which replaced a lot of keyboard functionality, offering features like lower case, keyboard macros, and a typeahead buffer.

Answer 3

Type-ahead was originally not an operating-system function, but rather a function of a terminal controller that was separate from the CPU and might have either a dedicated buffering subsystem for each terminal port, or a dedicated microcomputer [which may be discrete-logic based or microprocessor-based] to handle multiple terminals. The main CPU could only have one task at a time loaded into memory, and it made more economic sense to buffer typed characters in external hardware than to add enough memory to the main CPU to handle incoming data itself.

As for personal computers, I don't know what the TRS-80 or CP/M based computers did.

I think the Atari personal computers had a POKEY chip which scanned the keyboard and would be asked 50 or 60 times/second by the default interrupt handler to check whether it had a key, and then kept some kind of buffer, but I don't know the details.

The Apple II had a keyboard circuit that would autonomously scan the keyboard and set a latch when a key was available. When it set the latch, it would also capture the ASCII value of the key, and the latch would remain set until software cleared it. On older machines in the family, keyboard repeat was handled by hardware which would periodically re-set this latch while a "repeat" button was held. The Apple //e and later machines used a keyboard controller chip which included repeat functionality when keys were held down.

The Commodore 64 used a 50/60Hz timer tick routine to strobe all eight rows of the keyboard matrix, check what keys were held down, and if appropriate store whatever key was held into a 10-character buffer.

The IBM PC had a dedicated micrcontroller inside the keyboard which would autonomously poll it and record key-press and key-release events. I think a typical keyboard had a buffer that could hold 32 such events. Whenever an event occurred, the BIOS would receive an interrupt, retrieve a press/release event, check whether the keys were modifier keys, and either set/clear bits in a certain pair of bytes if they were, or use the aforementioned byte along with the scan code to generate a character code, which would then be put into a 15-character buffer. If this buffer was full, the system would beep briefly (suspending program execution while it did so).

On most or all of the aforementioned personal computers (I'm not sure about the TRS-80 or CP/M) there were separate system routines to for "read one character" and "read line of input", with the latter routine generally offering some forms of editing capability beyond just backspace. On the PC, many popular utilities could replace the default line editor (which was rather crude) with a better one. A nice benefit of having a dedicated line-input function is that code which called it could indicate how many characters were desired, and provide feedback if that number was exceeded. This was not possible on Unix-based or other systems that would accept lines of input before knowing what needed to be done with them.

Answer 4

First? Don't know, but from personal knowledge TOPS-10 had it, around 1974, in the 5-series monitor. Probably before that, but I wasn't using it.

A 1989 course on TOPS-10 internals, while way too recent to qualify as evidence for early implementation, has this to say about mechanism:

Characters from a terminal keyboard are stored in an input chunk stream until they are requested as input by the program or as a command by the monitor.

i.e., it describes typeahead. I recall the same tty chunks structure from the mid-1970s.

RSX-11D on PDP-11 likewise had typeahead at around the same time, as did RSTS/E and possibly RSTS-11.

---

I suspect this is an 'obvious' feature for interactive timesharing systems. The job/process/task may not be in core, you've got to accumulate characters somewhere, so why not accumulate them even in the absence of an outstanding read? (If there is even an explicit 'read' from the command interpreter; sometimes there's just a cosy arrangement with the terminal driver).

It makes for smoother user interaction on a loaded system if you don't have to wait for the next prompt before touching the keyboard.

---

I can scour the manuals later to push the date back some more, but certainly microprocessor-based systems did not invent this.

Answer 5

On the DEC minicomputers, Typeahead was indeed an OS function, as it could be turned off in certain circumstances, at least by the time of VMS. I'm pretty sure that was the case on the major PDP timesharing -- RSX and RSTS.

DEC minicomputers normally did not use block mode terminals. All terminal I/O was character at a time (a gross oversimplification, but okay for this discussion).

Some DEC OS's (the only ones I "grew up" on) did the immediate echo, while others, e.g., VMS, buffered the echo until there was a read request, as mentioned above.

Answer 6

While not a direct answer, the first systems with type ahead capability would likely have been ones which used a fairly smart terminal. If I remember correctly, the VT-100 (etc) had a type ahead mode which would internally buffer a line of text until the system was ready for it. It's been decades, so I don't really remember this feature; I just sort of remember that it was there, but I never used it.

Sorry for the non "dumb-terminal" answer, but a lot of terminals from the day were not completely dumb.

Answer 7

That feature was not universal; for example, MS DOS did not have it, as far as I remember.

Well, it did not, as it used the type ahead buffer the BIOS provided. By default that would be 16 bytes. It was quite useful to work at acceptable speed with diskette drives. Already these 16 bytes were quite useful and allowed to enter at least one command ahead, while the last was still processed. More so when extended by a TSR to 60 or 100 bytes. They showed up quite early. I could have never used a 4.77 MHz PC without.

The PC-BIOS was not the first to do so. Similar was offered by many BIOS for CPM, or other computers.

Furthermore, MS-DOS offered a read line function (Int 21h/0Ah, Buffered Input) to improve responsiveness for line input. This is not only handy for tool development, but guarantees shortest possible response between hitting a key, displaying it and executing edit commands (BS at least), independent of existence of buffers or buffer depth.

Just keep in mind how slow early computers were. If each character typed had to be handled all the way up to application level, usability for office application might not always be possible.

Which OS featured the type-ahead capability the earliest?

It's not really an OS feature, but usually located at the hard/software boundary. Many computers offered a type ahead. From the Apple II's 1 character deep buffer all the way to keyboard controllers like Intel's 8279 offering an 8 character buffer in hardware.

Likewise, back in the age of mainframe terminals, the whole character based handling was offloaded not only to I/O hardware but to external terminals/terminal controllers. A Block mode terminal, like the ubiquitous 3270 allowed complete local editing of not only a line but many thereof complete without OS (or application) intervention.

Similar for printing terminals like the 2740 family. Here a line is collected by I/O (not CPU) until finished by pressing Return or ATentioN. Only then the CPU is alerted and the line handed over for processing to whatever program (OS or an application using direct I/O) takes it from there.

After all, mainframes were block orientated by nature:

• Punch Card In
• Print Line Out

Block orientation is the very foundation of the high thruput these machines provided.

Long story short: Buffered keyboard input was there before unbuffered.

(Excluding experimental systems that is)