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

Pagina 1/3
| 2 | 3

Door norakomi

Paragon (1095)

afbeelding van norakomi

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)???????

Aangemeld of registreer om reacties te plaatsen

Van norakomi

Paragon (1095)

afbeelding van norakomi

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.....)

Van Sonic_aka_T

Enlighted (4130)

afbeelding van Sonic_aka_T

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.

Van SKiLLa

Expert (97)

afbeelding van SKiLLa

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

Van Edwin

Paragon (1182)

afbeelding van Edwin

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.

Van flyguille

Prophet (3028)

afbeelding van flyguille

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 ...

Van flyguille

Prophet (3028)

afbeelding van flyguille

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

Van Edwin

Paragon (1182)

afbeelding van Edwin

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.

Van flyguille

Prophet (3028)

afbeelding van flyguille

01-08-2005, 00:55

ok

Van ARTRAG

Enlighted (6573)

afbeelding van ARTRAG

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

Van Grauw

Ascended (10163)

afbeelding van Grauw

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

Pagina 1/3
| 2 | 3