What happens when all which occurs within the interrupt exceeds the frame period?

By norakomi

Paragon (1123)

31-07-2005, 17:25

I asked this question because my game started to HANG when more than 4 enemies entered screen...

everything was running ON the interrupt,
(right now I'm putting a lot of routines OUTside of the interrupt.....)

By Sonic_aka_T

Enlighted (4130)

31-07-2005, 18:32

idd, if your interrupt routine takes long than one interrupt period, and you have interrupts enabled the stack will fill up the whole memory and the system will hang. You probably use BIOS routines in your interrupt routines, which enable the interrupt at some point.

By SKiLLa

Expert (97)

31-07-2005, 23:25

Calling BIOS routines would - performance wise - always be a bad idea and will definitely hang your app.
Whenever your routines take longer than the interrupt-interval you would (first) see 'stuttering' (aka frame-skipping),
and when you continue to 'skip interrupts' things can get messy. With 100% DI code an occasional interrupt-skip would
only be annoying but should not lock-up your system. Mind the stack though

By Edwin

Paragon (1182)

31-07-2005, 23:53

In the above example, you code should not be interrupted before the end. Assuming that none of the calls enable the interrupt again. If EI is the last instruction before the RET, then an interrupt can not occur until after the RET.

However. The VDP is somewhat tricky. It will keep the VBLANK interrupt active until the status register is read again. If you don't read it and the code takes more than a full frame, then a new interrupt will be triggered immediately after the RET. This basically blocks any excution of the code not in the interrupt. Which could be just as bad.

If you want to check this, then read status register 0 before you EI (you don't need to do anything with it though). If this is the problem, then it will work again. Either slowly or with stutters.

By flyguille

Prophet (3028)

01-08-2005, 00:00

nesting interrupts is always a problem

you can use a flag to avoid nesting

INT_HOOK: ld a, ( flag)
and a
ret nz
ld a, $FF
ld (flag),a
....
your interrupt work
....
xor a
ld (flag),a
ret

in that way you do not needs to care about DI/EI ...

By flyguille

Prophet (3028)

01-08-2005, 00:02

In the above example, you code should not be interrupted before the end. Assuming that none of the calls enable the interrupt again. If EI is the last instruction before the RET, then an interrupt can not occur until after the RET.

However. The VDP is somewhat tricky. It will keep the VBLANK interrupt active until the status register is read again. If you don't read it and the code takes more than a full frame, then a new interrupt will be triggered immediately after the RET. This basically blocks any excution of the code not in the interrupt. Which could be just as bad.

If you want to check this, then read status register 0 before you EI (you don't need to do anything with it though). If this is the problem, then it will work again. Either slowly or with stutters.

include can happen that the new interrupt will be executed before of the RET

By Edwin

Paragon (1182)

01-08-2005, 00:39

include can happen that the new interrupt will be executed before of the RET

No it can't. There's at least 1 instruction executed after the EI. Maybe even for this reason. Anyway, it's in the z80 docs.

By flyguille

Prophet (3028)

01-08-2005, 00:55

ok

By ARTRAG

Enlighted (6845)

01-08-2005, 23:15

@norakomi

wellcome to the Z80 word!!

Now I think you could start to understand all the
talk about halfrate scrolling and full rate scrolling...

Actually the solutions for keeping all the processing within ONE frame are:

1) optimize your z80 code and your alghoritms
2) run all the VDP commands in parallel to the z80 trying to avoid wait loops

By Grauw

Ascended (10582)

01-08-2005, 23:44

I’ll just confirm that EI waits one instruction before re-enabling the interrupts , this afaik done specifically for the purpose of allowing an ISR to return after enabling the interrupts, preventing a stack overflow. Nevertheless, if the interrupts keep on being too long, they will still be executed continuously, leaving no time for the main loop.

Anyways, I’m sure the routines can be optimised . Use some clever coding and lookup-tables, and avoid the BIOS, that’ll usually do the trick.

~Grauw