How can a C64 interrupt let the KERNAL keep operating?

Question

I am working on a loading screen, and what I wanted was a simple raster trick (just change the border colour on the bottom half of the screen), and also call the KERNAL to load some more data from a disk. Easy peasy, right?

Here is my code. It loads with LOAD"*",8,1.

; The following is a short BASIC program;
; 10 SYS 2304
; and causes the machine to jump to the machine code include later on.
; 2304 decimal is 900 hex.
        .byt $01, $08, $0C, $08, $0A, $00, $9E, $20
        .byt $32, $33, $30, $34, $00, $00, $00

; Fill up with no-ops until the start of the program.
        .dsb 242,$EA

* = $0900
        sei

; Turn BASIC off but leave KERNAL and IO on.
        lda #$36
        sta $01

; Enable raster interrupt signals from VIC
        lda #%00000001
        sta $d01a

; Set the irqserve routine to start when raster line 0 hits.
        lda #0
        sta $d012
        lda #<irqserve
        sta $0314
        lda #>irqserve
        sta $0315

; enable interrupts again
        cli

; Infinite loop.
stop:
        jmp stop

As you can see, it ends in an infinite loop, which means the program should end there, right? That's not how this program behaves. This program will eventually return the user to the BASIC prompt. I'm trying to figure out why, and the problem appears to be in the routine irqserve:

irqserve:
; Look at the raster counter to see how far down the screen we are
        lda $d012
        beq bluborder
        cmp #116
        bcc blackborder
        jmp irqend

bluborder:
        lda #$01
; change border colour
        sta $d020
; Next interrupt should fire at raster line 116.
        lda #116
        sta $d012
        jmp irqend

blackborder:
        lda #$00
; change border colour
        sta $d020
; Next interrupt should fire at raster line 0.
        sta $d012
irqend:
        rts

But what I can't figure out though is what to do at the end of my interrupt handler. Should it jump back to the KERNAL? Or do rti or rts?

Answer 1

Assuming you're not actually going to chain the existing interrupt handler to your own, I think you should end with rti and more besides.

A disassembly of the C64 firmware shows that IRQs jump to FF48, which pushes A, X and Y to the stack in that order, loads the value that was at the top of the stack and if it does not have $10 set — i.e. if the triggering event was presumably an interrupt — it JMPs to your (0314).

So at the end of your routine you should pull Y, X and A from the stack, then perform an rti to pull the status register and the old program counter.

Or just jump to EA81, where the normal IRQ routine that started at EA31 does that.

Addendum: the safest way, assuming you're not trying to usurp the kernal, would be just to keep hold of whatever was in (0314) before you installed yourself, and jump to that. Dynamically writing it into your own code is a decent way of doing that without worrying about storage — end with a dummy JMP $0000 and then copy whatever is currently in 0314 to the argument of that instruction before writing in your own code's address.

Answer 2

RTS un-stacks the caller address (Program Counter) and resumes at the instruction following the original JSR So, in your interrupt handler returns to an undefined location because it is loading the processor flags (The three registers and the CPU flags) put there by the Interrupt trigger.

You must use RTI for an interrupt handler.

Since the question has changed, here's some more comments.

You'll want to wedge your interrupt handler in front of the existing one. That's what @Tommy is explaining.

Also the C64 architecture overloads the IRQ line with several triggers:

• VIC raster interrupt (what you want to do)
• CIA clock
• CIA timer 1
• CIA timer 2
• CIA serial I/O
• CIA cassette I/O

So an interrupt handler has to determine which of these has been triggered and act accordingly.