• Please review our updated Terms and Rules here

Interrupt handling on the 8008 CPU

S

smbaker

Experienced Member
Joined
Oct 21, 2016
Messages
436
Location
Oregon, USA
The 8008 supports interrupts. You can raise an interrupt, where you'll get an acknowledgement and the opportunity to insert an arbitrary instruction, such as using a RST<n> to jump to a particular interrupt vector. Easy enough.

The 8008 does not implement arbitrary push and pop, It only implements a special-purpose stack that holds PC. The RST<n> instruction will push PC onto this stack. So you can enter your interrupt service routine, and you can exit your interrupt service routine. (If you have stack space; the stack is only 8 words long)

However, if you cannot save the status of your registers, you can't do much else inside your ISR. You could write them all to temporary RAM locations, but so far as I can tell the only way to write a register to RAM is by using the HL (M) register. At the very minimum you'd have to clobber H and L. Saving the flags would be tricky but doable using a series of conditional jumps.

Am I missing anything? Were interrupts just not used on the 8008, other than waking it from an HLT ?

Scott
 
Researched this for a bit Sunday night.

It seems a well-known limitation of the 8008 that there's no way to save the registers from inside an ISR without destroying the contents of two of them. There were a few articles mentioning this had been overcome by implementing a stack as an IO port. I didn't find a schematic anywhere, but I think a straightforward implementation would be a small static RAM (even 64x8 or 16x8 would do) together with a counter. Connect it such that when the port is written, the value is saved to the SRAM and the counter is incremented. When the port is read, decrement the counter and read the value. This would allow you to save all of the registers. By using branches you could also save the flags. However, it's so cumbersome to do this, that I question whether it was done in practice other than as an exercise or for a hobbyist project.

So why implement interrupts in the CPU with no ability to save the stack inside the ISR? I'm thinking the value of this would be to insert HALT instructions at strategic points in the code where it is known there are two unused registers and the flag bits don't matter. Only raise interrupts if the CPU is in the stopped state. If there's an interrupt pending, then jam in an RST<n> instruction and service the interrupt. If there is no interrupt pending, then jam in a NOP and the CPU should exit the stopped state. Assuming this is the way the CPU was meant to be used, I might give it a shot.
 
Thanks. That's what I was looking for! I had envisioned using the 193 as a counter, but it's nice to also get an implementation of the timing, and the article also has code for the stack save with control flags too!

I'm going to have to put my own spin on it, and try it out.
 
Old story here; skip over this post if you're not interested in old iron.

This brings to mind the problem of saving all the registers on a CDC 6400/6600. Loads and stores are done by placing an address into an A register; if the register is 1-5, the corresponding X register is loaded from that address. If 6 or 7, the X register is stored to the address. There is no stack.
So how does one save all of the registers without clobbering any? This was a classical problem used to sort out the wheat from the chaff on folks applying for a programming position.

The solution was to use a series of conditional branches, based on the sign of a register; if the sign was not set, you branched around what was essentially a "CALL" instruction, which deposited a word at the indicated location (in the instruction) forming a RETURN. So you did 60 of these, shifting a selected X register one bit to the left each time. When you were done, you had a series of return instructions that mapped out the contents of that register. Once you had one register saved in this way, the rest was easy. I'm skipping over a bunch of details, but that's the gist.

Of course, there was a system call available to do this by switching context to monitor mode, but it was one of those interesting problems.

The pleasures of a RISC instruction set.
 
>>> I'm going to have to put my own spin on it, and try it out.

Of course. That's half the fun these days!

Dave
 
You must log in or register to reply here.
Back
Top