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

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

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.

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

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.

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

Quote:

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

Quote:

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.

ok

@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

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

--------------------------------------------------------------------------
Quote:
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
--------------------------------------------------------------------------

reply:
When exectly does one use the BIOS (because I don't think I DO)???
I guess that whenever a call (or jp) to the BIOS ($0000-$4000??) is made
the BIOS is activated.....
What other ways are there to activate the BIOS, or to use the BIOS?
(I just want to make sure I'm NOT using the BIOS.....)


another question:
Using $fd9a for my interrupt or using $fd9f??? whats the biggest difference????

I'm using $fd9a for my lineint.(EI1 set, and r#23=19)

the lineint starts at y=19 and on the lineint:
page 0 or 1 (the game page) is displayed.
the screen is scrolled horizontaly (with r#18)
sprites are enabled


I'm using $fd9f for the normal int. (this starts at y=212??)
on the normal int. at y=212:
page 2 is displayed (for the scoreboard which is in the top of the screen)
the sprites are disabled
and r#18 is set to 0 (don't scroll)

However, the lineint. also generates an interrupt at y=212,
but I can't seem to put that what I now have on the normal int. on this lineint.

So, now I'm using both interrupts, but I want to use only one (the lineinterrupt)

why is this???

I can to answer one

IF you in your interrupt handler routine does:


HOOK: bla bla
bla bla
RET

that "RET" returns to the BIOS routine and the BIOS routine is normaly executed processing all MSXBIOS tasks.

now if your routine is like

HOOK: bla bla
bla bla

pop hl
pop hl
pop de
pop bc
ret

those POPs will avoid to return to the normal BIOS routine and the RET will return to the program interrupted.

NOTICE: as I no more programs for MSXBIOS I forget how many POPs are needed. and in wich sort.

(to start with: thanx for all the replies about sprite collision, and gameoverview, Great new tips to start
working again)

I've got a question for the lineint.
The normal int starts at VBLANK and I immediately start building up the new page in VRAM.
Now, when line y=19 is reached, the LINEINT interrupts everything which is running on the VBLANK int.
(the LINEINT only sets the r#18 to scroll and sets page 2 or 3, which is the background page)
(after this the LINEINT does a RET, so the LINEINT is a real small routine, just making sure there is
the pagesplit !!
Does this mean that:

*In the VBLANK I have to DI and EI when writing to registers (because the LINTINT interrupts the VBLANK)????

*The Lineint interrupts the VRAM building up the new page????

*There will be an interrupt (the LINEINT) inside an interrupt (VBLANK INT), this seems to give me problems...

(the pagesplit is not making things easier, haha) what to do with this, for what traps should I be extra carefull???

AND: the game, like movement sprites etc. is done OUTSIDE the interrupts,
should I then DI (in some special way) also for the LINEINT when writing to registers???

Quote:

*In the VBLANK I have to DI and EI when writing to registers (because the LINTINT interrupts the VBLANK)????

Line int does not interrupt the vblank, it interrupts at line 19. However, interrupts can occur for more reasons at any time. (although they usually don't). So technically, you always have to DI/EI register writes.

Quote:

*The Lineint interrupts the VRAM building up the new page????

Only you can find that out.

Quote:

*There will be an interrupt (the LINEINT) inside an interrupt (VBLANK INT), this seems to give me problems...

It can, but it doesn't have to if you take the right precautions.

Quote:

(the pagesplit is not making things easier, haha) what to do with this, for what traps should I be extra carefull???

The are countless traps. And you *will* be caught by some of them. There's no substitute for experience and determination there. The key is to keep everything predictable. Know how much time is spent in certain routines and try to keep things consistent. It's no use to optimise certain routines which happen once in a while. The speed of your game will always be dictated by the worst case, which you must know and keep under control.

Quote:

AND: the game, like movement sprites etc. is done OUTSIDE the interrupts, should I then DI (in some special way) also for the LINEINT when writing to registers???

Any interrupt routine that accesses the VDP (which any interrupt handler will do) *will* destroy a VDP write if it interrupts it.