Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Data General Nova
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Interrupts and interrupt handling=== From the hardware standpoint, the interrupt mechanism was relatively simple, but also less flexible, than current CPU architectures. The backplane supported a single interrupt request line, which all devices capable of interrupting connected to. When a device needed to request an interrupt, it raised this line. The CPU took the interrupt as soon as it completed the current instruction. As stated above, a device was expected to raise its "done" I/O flag when it requested an interrupt, and the convention was that the device would clear its interrupt request when the CPU executed a I/O clear instruction on the device's channel number. The CPU expected the operating system to place the address of its interrupt service routine into memory address 1. When a device interrupted, the CPU did an indirect jump through address 1, placing the return address into memory address 0, and disabling further interrupts. The interrupt handler would then perform an {{code|INTA}} instruction to discover the channel number of the interrupting device. This worked by raising an "acknowledge" signal on the backplane. The acknowledge signal was wired in a daisy-chain format across the backplane, such that it looped through each board on the bus. Any device requesting an interrupt was expected to block the further propagation of the acknowledge signal down the bus, so that if two or more devices had pending interrupts simultaneously, only the first one would see the acknowledge signal. That device then responded by placing its channel number on the data lines on the bus. This meant that, in the case of simultaneous interrupt requests, the device that had priority was determined by which one was physically closest to the CPU in the card cage. The operating system's interrupt service routine then typically performed an indexed jump using the received channel number, to jump to the specific interrupt handling routine for the device. There were a few devices, notably the CPU's power-failure detection circuit, which did not respond to the {{code|INTA}} instruction. If the {{code|INTA}} returned a result of zero, the interrupt service routine had to poll all of the non-INTA-responding devices using the {{code|SKPDZ}}/{{code|SKPDN}} instructions to see which one interrupted. After the interrupt had been processed and the service routine had sent the device an I/O clear, it resumed normal processing by enabling interrupts and then returning via an indirect jump through memory address 0, {{code|JMP@ 0}}. In order to prevent a pending interrupt from interrupting immediately before the return jump (which would cause the return address to be overwritten), the {{code|INTEN}} instruction had a one-instruction-cycle delay. When {{code|INTEN}} was executed, interrupts would not be enabled until after the following instruction was executed; that instruction was expected to be the {{code|JMP@ 0}} instruction. The operating system could somewhat manage the ordering of interrupts by setting an interrupt mask using the {{code|MSKO}} instruction. This was intended to allow the operating system to determine which devices were permitted to interrupt at a given time. When this instruction was issued, a 16-bit interrupt mask was transmitted to all devices on the backplane. It was up to the device to decide what the mask actually meant to it; by convention, a device that was masked out was not supposed to raise the interrupt line, but the CPU had no means of enforcing this. Most devices that were maskable allowed the mask bit to be selected via a jumper on the board. There were devices that ignored the mask altogether. On the systems having magnetic core memory (which retained its contents without power), recovery from a power failure was possible. A power failure detection circuit in the CPU issued an interrupt when loss of the main power coming into the computer was detected; from this point, the CPU had a short amount of time until a capacitor in the power supply lost its charge and the power to the CPU failed. This was enough time to stop I/O in progress, by issuing an {{code|IORST}} instruction, and then save the contents of the four accumulators and the carry bit to memory. When the power returned, if the CPU's front panel key switch was in the LOCK position, the CPU would start and perform an indirect jump through memory address 2. This was expected to be the address of an operating system service routine that would reload the accumulators and carry bit, and then resume normal processing. It was up to the service routine to figure out how to restart I/O operations that were aborted by the power failure.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)