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

Page 1/3
| 2 | 3

By norakomi

Paragon (1123)

norakomi's picture

31-07-2005, 17:24

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

Lets say my interrupt does this:

interr
Di (this is not neccecary, when the int. is called the int is disabled automaticaly,
but i just want to say that I keep the int disabled the whole time)

call putsprites
call scroll
call etc1.
call etc2.
call etc3.
call etc4.
call etc5.

EI

ret

Let's say this takes longer than one frameperiod.
Does that mean that halfway the call to this interr is done again,
resulting in a sort of loop, which hangs (because of possible push and pops)???????

Login or register to post comments

By norakomi

Paragon (1123)

norakomi's picture

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)

Sonic_aka_T's picture

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)

SKiLLa's picture

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 Wink

By Edwin

Paragon (1182)

Edwin's picture

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)

flyguille's picture

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)

flyguille's picture

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)

Edwin's picture

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)

flyguille's picture

01-08-2005, 00:55

ok

By ARTRAG

Enlighted (6845)

ARTRAG's picture

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)

Grauw's picture

01-08-2005, 23:44

I’ll just confirm that EI waits one instruction before re-enabling the interrupts Smile, 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 Smile. Use some clever coding and lookup-tables, and avoid the BIOS, that’ll usually do the trick.

~Grauw

Page 1/3
| 2 | 3