I am not sure so I just ask. If during ldir a interrupt occurs will the CPU first finish the entire instruction or will it jump to the interrupt adress and continues after return?
Login or register to post comments
I am not sure so I just ask. If during ldir a interrupt occurs will the CPU first finish the entire instruction or will it jump to the interrupt adress and continues after return?
Yes. The latter.
LDIR is exactly like LDI except it deducts 2 from PC if P/V is set. Then as usual the next instruction is fetched if there is no interrupt (which happens to be itself).
good to know. many thanks. So it is good practice to keep ints disabled if your ldir something important like a jump to a interrupthandler.
And now for mucho bonus points:
Write a VDP access routine that does not disable interrupts, but still allows interrupt routines to access the VDP as well. 
The trick is to let the interrupt handler figure out how to 'gracefully abort' the access routine code that is currently talking to the VDP, then do its own stuff and signal to the interrupted access routine to 'try again'.
Hint: You can 'terminate' an OTIR by 'mutilating' register B in the interrupt handler, and (if needed) divert data that should no longer be written to the VDP by 'mutilating' register C.
I think I had something like this stable a long long time ago, thinking that it would allow me to blit sprite data from the 'main thread' while an 'interrupt thread' would handle all on-screen effects in parallel. If I am not mistaken I abandoned it in the end because the code is very messy and actually increases the interrupt handler's overhead to such an extend that screen splits become too unstable. But it was an interesting experiment nonetheless
And now for mucho bonus points:
Write a VDP access routine that does not disable interrupts, but still allows interrupt routines to access the VDP as well. 
The trick is to let the interrupt handler figure out how to 'gracefully abort' the access routine code that is currently talking to the VDP, then do its own stuff and signal to the interrupted access routine to 'try again'.
Hint: You can 'terminate' an OTIR by 'mutilating' register B in the interrupt handler, and (if needed) divert data that should no longer be written to the VDP by 'mutilating' register C.
I think I had something like this stable a long long time ago, thinking that it would allow me to blit sprite data from the 'main thread' while an 'interrupt thread' would handle all on-screen effects in parallel. If I am not mistaken I abandoned it in the end because the code is very messy and actually increases the interrupt handler's overhead to such an extend that screen splits become too unstable. But it was an interesting experiment nonetheless 
>>>> If I am not mistaken I abandoned it in the end because the code is very messy and actually increases the interrupt handler's overhead to such an extend that screen splits become too unstable. <<<<
That I thought when start reading... is more cost the overhead needed than just execute DI / EI.
And how the hell you reset what the VDP is waiting, reading the status register?.
Don't you have an account yet? Become an MSX-friend and register an account!
