5

When a peripheral in an 8080 system generates an interrupt request and the 8080 acknowledges the interrupt, the peripheral is expected to put an instruction opcode on the data bus which the 8080 will execute.

Typically this is an RST n instruction, which cases the PC to be pushed on to the stack and 8*n to be loaded into the PC, running whatever subroutine is located there.

But, as mentioned specifically on page 60 of the Intel 8080 Assembly Language Programming Manual:

Any device may supply an RST instruction (and indeed may supply any 8080 instruction).

Were there any systems that actually used an opcode other than RST n when handling interrupts? (I'm looking for examples of real systems here, ideally, rather than just "here's how you would do it if you wanted to.") What was the reason for doing so?

  • 2
    The companion 8228 system controller was actually designed to be able to push CALL opcodes during the INTA cycle instead of RST. – tofro Aug 23 at 21:31
4

Preface:

The 8080 interrupt system is one of the most simple and straightforward. Instead of having sophisticated built-in mechanics, reacting to interrupts, the 8080 just accepts a single instruction from an external source, marking this cycle with INTA. This opens up many more possibilities for external interaction than fixed handling.

RSTx instructions are just the most simple way, as they are implied subroutine calls encoded in a single byte, thus requiring the least external effort to inject an encapsulated software response.

Using multi-byte instructions (like a call) works as well, but needs a bit more decoding hardware (for call all included within the 8228 system controller (*1)).

What are examples of providing non-RST instructions for 8080 interrupts?

One example (with extended decoding) would be inserting a CALL issuing any possible routine as a response.

But maybe more important is single-byte instruction for tightly coupled interrupt response. For example, an INC instruction could be used to fire a wait loop.

Imagine the main program waiting for an external input in a tight loop like:

  MVI B,FFh
WAIT:
  DCR B
LP:
  JZ  LP
  [...]
  [Interrupt Reaction]
  [...]
  JMP WAIT

This might seem strange at first, as when it runs into LP, it becomes an infinite loop. But now let an interrupting device insert an INR B (04h), and suddenly the CPU will drop out of the loop. The remarkable part here is that its latency is always shorter than 15 clocks (5 for ICR and 10 for JZ) while an RST will take whatever the actual instruction is (at least 4) plus 11 cycles for the RST. In addition, no RET or stack adjustment at the end is needed (*2). For tight reactions, this is close to the optimal way (*3) on an 8080.

In addition, the use of INR/DCR forms a counter catching additional activations during its run time and serializes processing (*4).

Constructions like that are hard to make with other CPUs (*5).

Where there any systems that actually used an opcode other than RST n when handling interrupts?

Yes, using such constructions was almost standard on any embedded system past the most simple applications.

What was the reason for doing so?

Speed, flexibility, speed, integration and ... well ... speed.

Think of a real-time data acquisition system. Here every microsecond may count. At the same time, the data recorded is usually rather simple. Often just bits or a single byte. With the right combination of interrupts and injected code the 8080 can be turned into a multi-channel DMA unit while still running some data management application in the foreground. And so on.


*1 - System Controller is a bit of pompous name for the 8228, as it's basically a data bus buffer and a status latch. In addition, it can also either offer a single RST7 interrupt response, as well as handling an inserted CALL instruction the right way.

When configured for simple RST7 insertion (by pulling the INTA output to +12 (!) Volt) the 8080's interrupt input will work like almost all other manufacturers' interrupt inputs, jumping to 56h.

Otherwise, it can detect an inserted CALL and keep INTA asserted over the next two fetches. Too bad they didn't make it work with any multi-byte instruction, so doing this will still require additional circuitry.

*2 - Not to mention that an RST routine usually has to do some PUSHing and POPping

*3 - There are possible tweaks improving thereon, but they not as simple and beyond the scope here.

*4 - This can also be used with multiple registers and more complex structures for extremely tight-coded reactions.

*5 - Using the 6502's SO input can be used in a somewhat similar fashion, but way less flexible.

  • Fascinating! Do you have any links to detailed technical descriptions of systems that used this technique? – Curt J. Sampson Aug 23 at 22:44
  • No, at least not right away. I would need to search. But not really worth it. That's pretty common stuff in the embedded world - or at least was before way too fast 32 bit CPUs enabled the use of bloadware. – Raffzahn Aug 23 at 22:53
  • If this is impressive, you may want to learn about interrupt systems without foreground process at all. Interrupts issue RSTs, but these routines do never return but end in an infinite loop/halt situation (with stack reset). So effectively turning the CPU in an on request worker replacing various dedicated hardware at once. – Raffzahn Aug 23 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.