Interrupts of various types play a role in implementing the PiTrex software efficiently, and with reliable Linux operation (taken from an email by Kevin Koster):

!!VIA Interrupts
The 6522 in the Vectrex has an interrupt output that can be triggered
by events including the expiry of the scale timer that controls the
length of lines drawn on the Vectrex screen. I designed the PiTrex
to be able to respond to this by turning off the beam itself after
receiving this signal, thereby allowing the Pi to do other things
because it doesn't have to respond instantly. Malban eventually
convinced me that this wouldn't work because the Vectrex's analogue
circuitry controlled by the 6522 is slow and the PiTrex would react
before the beam position had actually stopped moving. I continued
exploring convoluted solutions to this, but have mostly forgotten what
these were now, and never got any to work.

!!BCM2835 Timer, EDR, etc. Interrupts:
These are hardware interrupts that the Pi's CPU can respond to. With
the PiTrex's own interrupt solution not working because it didn't wait
for enough time that the Vectrex circuitry was ready, this is a similar
solution in software. The Pi's own interrupt system can be triggered
either by the VIA Interrupt corresponding to expiry of its scale timer,
or one of the Pi's internal timers running in parallel with (or
possibly instead of) the 6522's scale timer. So instead of polling to
see if a line has been drawn to the end, the Pi can again do other
things until the interrupt causes it to go into an ISR that waits for
the delay of the Vectrex's analogue circuitry and then turns off the beam.

Also, during read/write operations in pitrexio-gpio, it can use an
interrupt triggered by the RDY input from the PiTrex to allow other
processing to take place during read/write operations to VIA registers
(which are done at the Vectrex's clock rate, so still correspond to a
significant number of Pi CPU cycles at 1GHz).

One issue with this is that I'm yet to find particularly good
documentation for BCM2835 hardware interrupt usage. Though there's
probably enough to get things working with some effort.

Another issue is that with Linux, interrupts can't be caught directly
by user-space programs, and by the time they've filtered down from the
kernel to user-space software, a significant and variable delay has
been added. So we really want to do this bare-metal or with a Linux
kernel driver (if I've got the right impression about how much more
quickly a kernel driver can react to interrupts - still to be
researched further).

!!Linux system interrupts:
I haven't got any experience with Linux internals, so I'm a bit vague
on the exact mechanics of this.

These are software interrupts that break execution of our code so that
the Pi can go off to do some supposably more important Linux business.
We're at the mercy of them because we've (I've) failed to get the
PiTrex hardware to react to VIA interrupts itself, so Linux can suspend
our code at the wrong point and cause it to miss whichever
signal/timer-overflow is used to indicate the end of a line.

Hopefully with a kernel driver, we can boss about the kernel and keep
it from doing anything while our code is polling to see when a draw
operation completes. But better would be if we can use BCM2835
interrupts in the Linux driver, and set the interrupt priority such
that running the ISR for handling end-of-line is a process that's
unable to be suspended. That way the Pi can be running useful code
during a draw operation, and also not getting in the way of Linux's
kernel processes for any longer than we need to.


So at the moment the Pi's CPU is tied up a lot of the time (mainly
during line draw operations, but also during each read/write to the VIA)
with polling inputs or (optionally) internal timers. The first two
interrupt types (the hardware interrupts) offer ways to have the Pi's
CPU spend this time executing more code (eg. an emulator) instead (this
can be especially efficient now that Chris has a buffer system in the
vector drawing library). The third (the software interrupts) sabotages
the polling method when used in Linux, and is best overruled by a Linux
kernel driver that also uses BCM2835 interrupts.

So when talking of the Linux kernel driver as a solution to the Linux
system interrupts, I think also of BCM2835 interrupts as part of a
preferable implementation of that. One that would also permit better
performance, hopefully to counter the added load of the other Linux
kernel processes that cause Chris to doubt that the Pi would be fast
enough to run Linux as well as all of the emulators that we want.
