65816 interrupt

fighting

65816 interrupt [Copy link]

65816 Interrupts
There are some oddities with the 65816 interrupts that you should consider. If you are planning to write 65816 native code, you should consider how your interrupt routines are handled. If you have written IRQ routines in native mode, then you have less to consider. However, if you are writing 65816 native code that uses the 16-bit accumulator and/or 16-bit index register, and you are using the core IRQs in emulation mode, then you must write some code to handle errors. In 6502 emulation mode, IRQs are pushed onto the stack first by the high byte of the program pointer, then the low byte of the program pointer, and finally the status register. In native mode, IRQs are pushed onto the stack in the following order: Program Pointer

Buffer (PBR)
Program Pointer High Byte
Program Pointer Low Byte
Status Register
Then, the decimal mode bit (d) of the status register is cleared (setting it to binary mode), the IRQ flags are set (only non-NMI), and finally, the program buffer (PBR) is cleared and the 65816 jumps via the IRQ hardware vector.

This implies that if the 65816 is run in emulation mode from a non-zero ram bucket, the program bucket will be lost (bad). There are two ways to fix this. First, avoid running outside of ram bucket 0 in emulation mode. Second, you can save the current program bucket value to some location in ram, then run in emulation mode beyond bucket 0.

One thing that is still unclear is whether the CMD superprocessor will handle native mode IRQs well. Native mode has a new hardware vector table.

rain

Send me that table, maybe you can find out something.