(Lack of) identifying IRQ sources in C64 interrupt handlers

To save space and execution time (and partly of necessity, cf. below), interrupt handlers are typically set up for the context they are used in with assumptions on expected system interrupt sources.

If you were to set up a context in which you might be receiving interrupts from both the VIC (maybe raster or sprite collision interrupt) and a CIA (maybe a timer fired, a TOD alarm triggered or a peripheral port signals) you would indeed need to determine the source of the interrupt to handle/acknowledge it correctly.

There is no concept of an interrupt source on the 6502/6510 and the C64 kernal provides no abstractions by itself. So basically, you have to beat about the known bushes and see what falls out. For instance, you can look at $D019 to determine if there's an unacknowledged VIC interrupt. Similarly, you'd look at $DC0D to see if a CIA1 had something to say (CIA2, with interrupt register $DD0D, triggers the NMI instead of the IRQ, but same principle applies to determine the NMI source).

But it gets worse. Because the IRQ (and NMI) can be triggered from anything in the expansion port as well, and who knows where some random cartridge has its I/O space and interrupt registers; there's no plug and play resource manager to track that kind of thing. ;) Fx, add a MIDI interface and it may trigger IRQs (or sometimes NMIs) whenever a MIDI event occurs.

So you will need to explicitly support the specific interrupt sources that are expected to occur and suffer the consequences if unexpected ones occur. :)

Based on my findings above, it seems that there is no need to identify the IRQ source in interrupt handlers, or at least it is not a regular practice. Why?

Because there are no unknown/unexpected interrupts?

The C64 is a rather simple machine, originally developed as a game console. Later usage is still much like one. C64 software assumes to be loaded as the only application and takes control of the whole machine. There is no concept of concurrent applications and extensions, if they exist at all are made specific for one application they extend - like BASIC.

A program loaded owns the machine until power off.

There is always only one program loaded and in charge. It does not need to care for any previous loaded program or its interrupts. Only those interrupts enabled by this program will occur and thus it only needs to care for them.

When a program finishes it should disable all interrupts and restore all previous handlers, but more often than not, program termination is assumed to be done via a power cycle. Where others like Apple, Atari, BBC or MSX try to establish protocols for extensions and limited multi programming, the C64 stays true to its heritage.

Due this one program to rule them all 'feature' chances are slim to find any cooperative example sharing interrupts. Programms using multiple will ido it in custom fashion. In addition, when interrupts are used for screen manipulation timing is essential and cycles are in short supply. This encourages tight programming, including interrupt state machines like mentioned. Depending on the task it may be faster to have every state put the next states routine address into the interrupt vector.

Long story short: Go with whatever pleases you. If your task isn't as tight, using a nice series of detection function, like you suggest, may be good style.