Belated response to the above. The indicated instruction should be executed before the playmusic subroutine is called. In any wired-OR interrupt circuit, a finite amount of time will elapse after the cause of an IRQ is cleared before the microprocessor will see that no IRQ is pending. If you wait too long to clear the IRQ the MPU may still think it's being interrupted when the RTI is executed at the end of your interrupt service routine (IS). The result will be a spurious interrupt—an interrupt with no apparent cause, which in some cases can result in system fatality. It wouldn't be a problem with the above code, but may become a problem once you add more to your ISR.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for pointing that out BDD!

I’ve ANDed all interrupt lines in the CPLD.


I added a second IRQ, in this case from the VDP. It creates an IRQ when scan line 200 has reached. The IS routine scrolls the screen one pixel to the left and one pixel up, each 60th of a second.

So there are two interrupts independently going on. I’m amazed how well this works, SID music is playing without hick-ups, and the screen scrolls completely smooth.

Sorry for the blurry picture, but it was uhm, in motion.
At the beginning of the scroll screen routine I changed the background color of the screen to green, at the end of the routine I changed it back to black. As a result you can see how much (little) raster time it takes to scroll the screen. The green raster line is visible at the bottom of the screen underneath the text “Test Screen”.
I did the same thing for the playmusic routine by changing the background color of the screen to red. Because the music isn’t playing in sync with the refresh rate of the screen, the red bars appear randomly on the screen. You can also see that the playmusic routine takes a little more time.

Here is the interrupt routine I'm using:

_________________
Marco