Frame interrupt

The Jupiter ACE only had one interrupt source. It was a 50Hz (presumably, 60Hz in the USA) "frame" interrupt.

The Jupiter ACE ROM listing shows that the ROM uses the HALT instruction to slow down printing of VLIST.

The Reference manual has example of uing the HALT instruction to slow things down, too.

Implementation

We will use a timer on the PIC on the MillRACE IO module to generate the interrupt.

The RC2014 Z80 CPU module uses an external pull-up resistor to keep the interrupt line high. This would mean that, if we wanted to assert the interrupt-line, then an open-drain GPIO output should be used. However, the PIC we're using doesn't have open-drain pins. 

So, to give the same behaviour, we'll do the following to pulse the interrupt line:

• set the pin to input
• latch a 0
• do
  • when timer fires, switch pin to output (assert INT)
  • wait a short time
  • switch pin to input (de-assert INT)
• repeat

How long do we pulse the interrupt line for?

Rough maths: According to this page, we need pulse for at least 23 Z80 clock ticks. As the PIC (running at 16MHz) is running twice as fast as the Z80 (running at 7.3MHz), the PIC will need pulse the INT line at least 51 ((32*16)/7.3) PIC clock cycles. With each PIC NOP instruction taking 4 clock cycles, there will need to be at least 13 (51/4) NOPs between assertion and de-assertion....let's round it to 16.

The future?

If I were to make this a more general purpose module, I would normally like devices to own up to interrupt assertions. if this frame interrupt happened at the same time as, say, a serial interrupt, I would like to know that I need to do something with the frame interrupt.

So, what I would probably do, is program the PIC to place a 1, indicating that the "frame" interrupt has pulsed, on BIT[7] of the input port. This would then be cleared on a read or on a write of 0x80.

Yes, I'm thinking about stretch goals already....