News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

EI (enable interrupt) how long does it take to enable?

Started by AHack, 18:24, 31 March 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AHack

On interrupt 4 I disable the interrupts and from there on I have various routines that abuse the stack pointer. These blocks of code have predicable timings so when I get to interrupt 5 I know I'm there because of the code I've executed so anything I do with the CRTC still works as should. Then some where through interrupt 5 I want to turn on interrupts again with EI. If I do this near the end of interrupt 5 it all goes wrong. But if I enable interrupts about 16 or 20 scanlines into interrupt 5 it works.


It seems to me EI needs some time to become in effect before the next interrupt. Is this true?


What I'm trying to achieve is Int1, Int2, Int3 and Int6 work from an interrupt handler. While Int4 and Int5 are disabled so that I can abuse the stack. That way I can avoid using Halts so game code can run across boundries of interrupts.


Thanks for any help.

andycadley

EI will re-enable interrupts after the next instruction (this is basically to ensure that EI; RET doesn't cause a stack overflow). The gate array will wait for the Z80 to acknowledge an interrupt, so if interrupts have been disabled for a while you will find that can trigger it unexpectedly. It's probably worth manually resetting it via the gate array (part of the screen mode/rom select register).

keith56

andycadley is correct... it's the command after that it enables in my experience

I would use Stack abuse in ChibiAkumas, and I would use code like this

....
ei
ld sp, &0000 :StackRestore_Plus2


where StackRestore_Plus2 was self-modified with the correct stack pointer.
This relied on interrupts enabling the command AFTER ei (as andy said) otherwise corruption would have occurred - suffice to say it worked fine on real hardware and emulators...

...EXCEPT on CrocoDS on my NDS - which clearly was turning interrupts on immediately with the EI, not the command afterwards - as any sprites read with, or screen written with stack abuse would become progressively more corrupted, as interrupt calls would damage the data!
Chibi Akumas: Comedy-Horror 8-bit Bullet Hell shooter!
Learn ARM, 8086, Z80, 6502 or 68000 with my tutorials: www.assemblytutorial.com
My Assembly programming book is available now on amazon!

AHack

Thanks everyone :) I now have it working! I decided in the end to divide the interrupts in blocks of 3 because I will be doing more stack abuse in intterrupt 6.


I completley removed all Halts from the game loop now. So now, where the first 3 interrupts are I can write code without juggling between Halts, then when I get to the 4th interrupt I turn them off and re-enable them after V-Sync. From there on I can abuse the stack as much as I like with no interrupts getting in the way.


The first 3 interrupts set a flag to 0 while the 4th interrupt sets the flag to 1. Then in the main loop I check if that flag is high (sort of like the V-Sync check) then I know the starting scanline position. From there I can still do my CRTC changes because I have predictable timings from my stack abused code. The other CRTC changes can be done in the enabled interrupts. It all works pretty well and I get the best out of both worlds.

Powered by SMFPacks Menu Editor Mod