I posted an update on my CNC-64 project to YouTube yesterday and got a very interesting tip from Stephen White. One tip he provided was to store the A, X, Y registers in zero page instead of the traditional pha, tya, etc. Since my NMI ISR runs at a 1kHz rate on a 1mHz 6510 (C64) every cycle in the ISR counts. Indeed this saved a precious 9 cycles in entry and 10 on exit of the ISR!

His other tip had to do with some redundant bits in my buffer read macro and the ISR, removing those saved another 5 cycles. So another 24,000 cycles are available every second!

Just thought I would pass this along as I did not find it just now when searching the forum.

WAS


NOW

If this code is at the start of an interrupt routine then the PHP is redundant, it's pushed automatically by the processor.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I did not think the PHP was done automatically for NMIs?

EDIT:
Don't know how I got that idea into my head, just found this: http://6502.org/tutorials/interrupts.html which says of course, just as you said the PHP is not needed. So, two more cycles saved!

EDIT #2, that is actually 7 cycles save, 3 for PHP and 4 for PLP!

Thanks

IRQ, BRK and NMI all push the PC and status register. A power on reset goes through the same internal operations BUT does not enable the memory writes - If you connect a logic analyser you can see the stack addresses being generated.

https://en.wikipedia.org/wiki/Interrupts_in_65xx_processors

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

If you are using memory to save registers in interrupts and using both IRQ/BRK and NMI then they must save to different areas as your IRQ/BRK code could be interrupted by an NMI.

Many systems try to minimise the foot print of the firmware to leave as much as possible for the users application. Pushing to the stack is normally a reasonable thing to do but in your case saving to memory may be better if timing is very tight.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Overall good idea, but I'm not sure why you bother saving A to ZP - it wastes a byte in the code, a byte in ZP, and saves you no cycles.

It saves 1 cycled on exit. A lda from zero page is 3 cycles, a pla is 4 cycles...

Ah.

Did you switch out the C64's kernel ROM after setting up your own interupt and reset vectors ( and any other routines needed) or did you hook into the C64's NMI handler at $318-$319?

I overwrote the NMI handler address at $0318-$0319 which has drawbacks but is simpler for now. I do not pass through to the kernel handler.

Just a note on your initial post: TXA, TAX, TYA & TAY take only 2 cycles and you are comparing saving Y to not saving Y. So the saving is just 2 cycles and on restore probably just 4 cycles.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Good catch! I was able to get rid of the php as well so now my entry and exit code is below.

@JimBoyd mentioned the kernel's NMI functionality and looking at it this morning this is the code that the NMI vector at $FFFA points to:



So it seems that since I am hijacking the NMI after the indirect jump I should be adding a CLI upon exit though I don't see this in the kernel disassembly, it just ends with RTI.

my entry:


and exit:

Since RTI includes PLP a CLI is not required.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Ah, OK. That had not occured to me before but makes sense. Thanks!

Also, the SEI that the Commodore kernel inserts into the beginning of the NMI handler is unnecessary. IRQs are automatically disabled as part of the response to any interrupt.

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