Skip to content

Site map) Home > Hardware > Durango > Durango·X > IRQ

Durango-X IRQ generation


Unlike most computers, where some dedicated peripheral chip works as an interrupt controller, latching the interrupt request until acknowledged by the CPU's ISR (Interrupt Service Routine), Durango-X uses a simple counter (U14, 74HC4040) plus a few Schmitt-trigger gates for the generation of a brief pulse (around 10 µs) for the IRQ input, as long as it's not disabled via the Interrupt Enable Port at $DFAx. Thus, no acknowledge is possible or necessary.

Since the IRQ pulse is not latched, there is an increased risk of losing interrupts whenever some critical code is executed with interrupts masked (via the SEI opcode), as other systems will service the pending request as soon as the interrupt mask is cleared. This, however, shouldn't be a concern, as longer critical code may anyway lose some interrupts even in other computers, as they usually won't queue IRQs.

The real issue, though, is the length of the IRQ pulse, as it's generated in an analogue way thru an RC-network and a Schmitt-trigger gate. Several factors, including component tolerances, may affect actual lenght which, by the way, is by no means constant. The nominal value, 10 µs (about 15 clock cycles) is both long enough for reliable IRQ triggering, and short enough not to be a problem with succint ISRs -- whose overhead is at least 7+6 cycles for the trigger sequence plus the mandatory RTI at the end, adding on top of that whatever time takes to finish the current instruction.

There is definitely quite a bit of tolerance on the IRQ pulse length, although some extreme cases could be troublesome.

Long interrupt pulses

Unless you're dealing with a really short ISR, the IRQ pulse can be way longer than the specified value without too much trouble. Note that the Durango-X Hardware test uses a minimal ISR for testing, thus might fail the test without any other apparent issues. In extreme cases, though, the IRQ pulse may last longer than the ISR itself, thus triggering a second time at once. Again, this is hardly an issue, save for any interrupt-based timing being thrown off.

If you suspect about this, and are able to run EhBASIC, you may RUN the following code to check the interrupt timing:

1 PRINT DEEK($206)/250:GOTO 1

Which should print the system time scrolling in seconds, in a remarkably accurate fashion. A long interrupt pulse would make the count faster!

In order to shorten the IRQ pulse, the value of R26 (nominally 100 K) and/or C8 (68 pF) should be reduced -- usually the former is preferred, as a second resistor in parallel with R26 will do. Note that the use of a 74HCT132 for U8 (instead of the recommended HC) will effectively stretch the pulse to about twice its length.

Nominal IRQ pulse

IRQ pulse with HCT and 100 Kohm, actual length is 11.2 µs as indicated by the cursors; the displayed pulse is stretched by probing the RC network


The IRQ circuit was redesigned in the v2 issue; the functionality of U8 has been replaced by spare gates from U32 (74HC245) which, in case it's the HCT version, will shorten the IRQ pulse instead; for correction, R26 and C8 still operate the same way.

Short interrupt pulses

On the other hand, this is more likely to cause problems. Unlike the NMI, the 6502 samples the IRQ line after the end of each instruction; some opcodes may take up to 7 clock cycles or ~4.6 µs -- anything shorter during the execution of such instructions might be missed. Surprisingly, the current version of Hardware test code runs pretty short opcodes, thus being quite tolerant about this.

Short IRQ pulse

IRQ pulse with HC and 22 Kohm; again actual length is 1.36 µs as indicated by the cursors, which is way too short

As mentioned, losing interrupts frequently might have the effect of impairing (or completely disabling) the keyboard/gamepad response, besides any timing alterations. Once again, running the EhBASIC code above (if you're able to type it!) will confirm this -- too short of a pulse will make the second count slower.

Similarly, the opposite remedies are suitable in this case: augmenting the value of R26 and/or C8 (you may place another capacitor in parallel for that matter).

Acceptable IRQ pulse

IRQ pulse with HC and 39 Kohm; this 2.36 µs pulse is definitely on the short side, but is less likely to cause trouble.