ICL 1900 computers were always supplied with 'executive' software tailored to the specific installation. Exec provided simple program load and run facilities. There were no 'lights and switches' on the 1900; instead, the operator communicated with Exec using a console teletype, which was a modified model 33. Commands were at the level of 'load file #PROG from tape unit 3' and 'go at address 120'.

One peculiar thing is that you could not just type a command to Exec. Instead, you needed to press an INPUT button (not a teletype key, a physical switch also mounted in the teletype: see the console teletype picture at the bottom of the page). Having got Exec's attention that way, then you could type a command, followed by the ACCEPT button.

What was the rationale for this? In later systems from other vendors, with console terminals, it was generally the case that there was an outstanding read, so you'd just... type your command.

Was there some underlying hardware reason why this arrangement was necessary? Or something to do with Exec's internal structure? Was it not possible for Exec to do output if it had a pending read?

(I find the INPUT requirement maddening when using a 1900 emulator; it's hard to get into the habit of not 'just typing').

  • 4
    I can see it simplifying hardware & software if the switch caused an interrupt that forced the executive to pay attention and read the TTY through polling. If that switch doubled as "interrupt the currently running program" that'd be a bonus. That's just a guess--I'm very interested in the actual answer. Nov 13, 2023 at 16:14
  • 2
    I think this is possibly the right track, but plain old serial hardware can cause an interrupt, so there has to be more to it. But now I think about it, KDF9 had a similar thing: there was a TINT (typewriter interrupt) button before you could enter a command to Director. On the KDF9, the console flexowriter was on a DMA channel, which probably was half-duplex. Or perhaps the English were just being polite: "Er, excuse me, but might I have a word with you?".
    – dave
    Nov 13, 2023 at 18:00
  • 1
    @another-dave: Unless a system reserves at all times a buffer with enough space for a line of input, responding to input might take a non-trivial fraction of a second while RAM contents are swapped out to disk. Having a button trigger such an event would seem more practical than having it happen with every keystroke.
    – supercat
    Nov 13, 2023 at 22:31
  • 2
    There was a similar thing with 360ish mainframes, a button which opened an input line at the console while putting the CPU into interrupt mode. That way a it was guaranteed that the operator command had priority. Ofc, taking too much time entering a command was not really liked with online systems :))
    – Raffzahn
    Nov 14, 2023 at 3:12
  • @supercat - No writing core to disc (even if there was one), this was a 1900 operator's exec, not a fully-fledged OS like GEORGE. But I'd imagine assemble-a-line (up to 40 ch) being in the fixed core, with the interpreter possibly requiring an exec overlay to be brought down.
    – dave
    Nov 14, 2023 at 22:37

1 Answer 1


I think I have figured out the rationale for this requirement, based on this manual for exec E6RM, unfortunately only available in DjVu format, not PDF.

How it works

Internally, Exec arranges its own activities by (I think) cooperative timesharing between Exec 'processes'. The console typewriter is regarded as a single-user device that is serially shareable.

Exec processes that want to do console typewriter output put themselves on the typewriter access queue. When at the head, they can then issue an output extracode to write a block of text, suspending until I/O completion, but still 'owning' the typewriter.

There is a single console typewriter input process that is normally suspended. In an overlaid exec like E6RM, the input process may be in an overlay, i.e., not necessarily resident when idle.

The INPUT button (or, apparently, any of the Fn buttons) causes an interrupt into Exec, resulting in the input process being resumed. That process then issues an input extracode to read a line of input, typically up to 40 characters. In larger 1900s at least, this is a DMA operation. Chapters 5 and 7 of this 1904A training manual may be instructive.

Why like this?

The follow is all hypothesis by me based on reading available documentation. I think fundamentally this is to do with the 1900 Standard Hardware Interface; the console typewriter is from that point of view just another device.

There is a single I/O channel for the typewriter. It can only do one transfer at a time. For output, this is readily handled by queueing; the typewriter is allocated to an Exec process for the duration of a transfer.

Input, however, comes at an unpredictable time. It is organizationally convenient to cause an interrupt that the Exec can then use to schedule the typewriter input process to get itself into the queue; this automatically arbitrates between all potential output use and the input process.

In other systems, this could be done with a read interrupt along with the first character. However, I suppose that (a) typewriter I/O is modelled as normal I/O, (b) there is a single channel, (c) which is unidirectional when in use, and (d) therefore would be unavailable for output if there was a pending read.

(See flowcharts in sheets 7.1 onwards)

You must log in to answer this question.

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