How much an ISR should do is of course application dependent. If the application is real time control, and if the response time is very tight relative to the clock speed, then every instruction is going to have to count. But this is not the only situation!

In Acorn's MOS, IRQ is relatively pedestrian - for good engineering reasons it indirects through RAM. On the other hand, NMI is absolutely minimal, because it is used solely for interacting with the floppy controller, which is very much a real time subsystem.

Rules are made to be broken. There is always the exception.
As for copying a frame buffer, this is where hardware should
replace program. A DMA transfer would have been the right
way, in general.
It sounds as though there wasn't much else to do anyway.
It is just that over the years I've seen cases where too much processing
was done in the interrupts.
I saw one that they read an A/D, offset the value ( dangerous to do without care )
and multiplied by a ratio. All in the interrupt.
If there are more than one critical operation to handle, one needs to look
carefully at how it will handle multiple events. This is hard to do while locked
in an interrupt.
Dwight

Not sure if it is helpful, but to change JSR addresses I just edit the address bytes.
This is an example used to dynamically specify the JSR address of a SID file...

_________________
8bit-Slicks is coming out soon, register for the closed-beta!

That's a valid technique if you can tolerate self-modifying code. It disqualifies that code from running from ROM. A more universal technique, which is one byte shorter but slightly slower:

(Don't forget to adjust those addresses by 1!)

Or, having set up the address in RAM, just make indirectEntry be a simple JMP (target).

Right.

Or, if you find adjusting the address to be inconvenient -- and you have a byte to spare -- use PHP RTI to conclude the sequence (instead of RTS).

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Oh, I like that!

Happy to entertain you. Here's a related trick which could in some cases be an attractive way of returning altered flags to a bios caller, without relying on stack gymnastics. In this thread (whose context is 65816), ...

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hmm. I have used this subroutine in the past to get indirect JSR:


Its slow, but the macro reuses the code, so it only requires 6 bytes per indirect JSR after the first one.

It looks like you're duplicating and modifying a copy of the return address on the stack, using NMOS instructions only (CMOS has direct PLX/Y). That *will* be slow, especially compared to the six bytes *total* required for a JSR to a simple indirect-jump trampoline.

Yes I use a 6502, but it works on a 65C02 as well. Its fairly easy to get 65c02-only code:



Slightly faster...

If you simply want a fast method, just use the direct modification of the JSR instruction: