Site map) Home > Hardware > Durango > Durango·X > IRQ
Durango-X IRQ generation
Caveats
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.
Note
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.
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).
