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
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.
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.
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
C8 (you may place another capacitor
in parallel for that matter).