The invention and spread of interrupts in the 1950s is reasonably well known but I am curious: were there any systems after which didn't support them?
The Wang 2200 series of minicomputers (Apr 1973 to Jul 1989) was implemented without hardware interrupts. All peripheral interaction was handled via polling.
These machines were fitted with a BASIC interpreter which also served as the operating system. Users were not given access to the underlying machine code, and Wang did not publish the assembler etc. For all practical purposes the "machine code" of the Wang 2200 was compressed BASIC.
The interpreter carefully polled for peripheral activity before each BASIC statement, and even during some of the longer statements. The interpreter was completely robust, but it was possible (though quite difficult) to confuse it into delaying any polling for several minutes, giving the impression that the 2200 had crashed.
Sharp pocket computers based on the ESR-H SC61860 micro-controller (PC-12xx, 13xx and 14xx) did not have interrupts. No instructions like
rti, nothing. Everything was done by polling (it had for example two instructions
CDN which would poll the
Xi pin of the cassette interface a given number of times of a loop counter or stopping when the pin gets the waited state).
Would embedded systems count?
If yes, there were GI's PIC1600 MCUs (http://bitsavers.org/components/gi/PIC/1983_PIC_Series_Microcomputer_Data_Manual.pdf), predecessors of PIC microcontrollers by Microchip, some of them had no interrupts.
From that time, the legacy PIC12C Microchip's microcontrollers, (for example PIC12C508 https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/40139e.pdf) did not have interrupts either.
Lots of examples could be found among many of USSR era home computers based on the KR580VM80 chip (a clone of i8080).
In a normal i8080 system, the CPU is supposed to work with companion (or 'chipset') chips, like i8228 and i8259, as to have interrupts, IO space and control of the bus drivers.
However, it was quickly understood, that it is still possible to build a working system by dropping all of those companion chips and using an absolute minimum of glue logic ICs. As the result, interrupts and IO space were unused. Some home computers of the era even used INTE output to generate sound.
Although the Apple II family of computers allows I/O cards to use interrupts, none of the internal hardware on the Apple II nor the Apple //e offers any support for them beyond making the pins available on the card-slot connectors, nor is there any documented means by which multiple cards wanting to use interrupts should coordinate such efforts. While some I/O cards did make use of interrupts, the majority of Apple II systems have never used any hardware or software that employed them [the most common I/O boards by far were a Disk II controller, a generic parallel printer interface, and an 80-column card, none of which used interrupts; relatively few systems ever had anything else installed].
Another example from the embedded world: the Parallax Propeller uses multiple CPU cores to service events instead of interrupts.
The Atari 2600 Video Computer System draws its entire screen using techniques that on other systems would be accomplished via raster interrupts, but its 6502 die is in a 28-pin package that omits both /IRQ and /NMI. Timing is accomplished by polling the RIOT chip to wait for a moment near the start of the desired scan line (if code doesn't already know within a scan line where the beam is) and then writing any value to address 2 (or any address having the bit pattern xxx0 xxxx 0x00 0010), which causes the Television Interface Adapter (TIA) chip to assert the READY line until the start of the next scan line, which will stall the first read (which will usually be the next cycle) after the store. While there are some situations where having a raster-split interrupt might have been nice, even code which will take an unknown amount of time to execute can usually be punctuated with calls to a routine that starts like:
This will return immediately if the TIA's counter is within six counts of reaching the value 124 (about 384 cycles if using divide-by-64 mode), but otherwise allow the code to start executing precisely at the scan line where it reaches the proper count. If game logic never goes more than about 350 cycles without a call to this routine, it can take any number of cycles in total without disrupting video display. If the display logic includes frame-counted animations, and the main game logic waits for animations as appropriate, the system can run games smoothly even if the logic would take multiple frames.
The performance degradation from having game logic poll for the display was significant, and having a timer interrupt would have allowed the game logic to run somewhat more efficiently and compactly, but scattering a
JSR DispPoll throughout parts of the code that weren't time critical, or
BIT INTIM / BMI $+5 / JSR DispPoll throughout those parts that were [reducing the time penalty from 18 cycles to 7 or 8] wasn't especially onerous. Having interrupts will allow many tasks to be accomplished more efficiently than would otherwise be possible, but when efficiency isn't critical, polling can often be sufficient.
The Parallax Propeller processor for quadcopters has (I write has because it's in production today for its intended purpose) no interrupts, and this is an advertised feature (so that execution performance is predictable).
I found this most expedient when working in assembly language. I could do without a clock by balancing the instruction costs on both sides of an if/else operation.
Yeah, the higher perfromance CP/M computers (either an 8080 or Z80 processor) had interrupts but some had to poll the devices. These used a BIOS so your CP/M applications could access the screen, disk(s), serial ports and (if it had any) networking through standardized calls. This allowed implementation from a cheap cheap setup with bare minimum auxilalry hardware using polling up to high performance with interrupts, DMA, and a coprocessor speeding up the device in question, with everything in between depending on the system.