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

Страница 2/3
1 | | 3

By norakomi

Paragon (1123)

Аватар пользователя norakomi

03-08-2005, 20:12

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

By flyguille

Prophet (3028)

Аватар пользователя flyguille

03-08-2005, 20:25

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.

By norakomi

Paragon (1123)

Аватар пользователя norakomi

04-08-2005, 19:04

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

By Edwin

Paragon (1182)

Аватар пользователя Edwin

04-08-2005, 22:11

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

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

Only you can find that out.

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

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

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.

By mth

Champion (507)

Аватар пользователя mth

04-08-2005, 22:40

$FD9A is called on every interrupt, $FD9F is only called on VBLANK interrupts.

It is good practice to keep your interrupt routines small and use flags and counters to synchronise your code to the interrupt, like Flyguille did in his example. That way, you can get slowdown if your code runs longer than it should, but it will not hang.

By norakomi

Paragon (1123)

Аватар пользователя norakomi

06-08-2005, 21:55

What about this:

On the VLANKint:

Musix,
SFX,
Background scroll (this is fastest to do on VBLANK)
put 32 sprite in screen (don't do this halfway screenbuildup)
Set Sprites colors

do you think having only the above routines ON the int,
and ALL THE REST OF THE GAME outside, is a good idea ????

By Sonic_aka_T

Enlighted (4130)

Аватар пользователя Sonic_aka_T

06-08-2005, 22:39

Like mentioned before, you're best off using 2 separate sets of sprite tables. Prepare each set in your main program, on the interrupt, just switch the address. Be sure to do screen-related stuff first. You music routine may well take '30 lines' of CPU time, in which case you'd would notice any VDP18/sprite changes and whatnot. If your music/sfx routines take more time to complete than the time it takes for the screen to reach the line on which your line-interrupt occurs, you will either need to enable interrupts, or call your music routine from the line interrupt. Either will work.

By norakomi

Paragon (1123)

Аватар пользователя norakomi

07-08-2005, 15:53

all sprites have a table with y,x,sprite number, reserved (not used in screen 5)
Like mentioned before, you're best off using 2 separate sets of sprite tables. Prepare each set in your main program, on the interrupt, just switch the address. Do you mean one table with the
y,x,sprite number,reserved
and one table with the
y+r#23,y+r#18,sprite number,reserved
???

By Sonic_aka_T

Enlighted (4130)

Аватар пользователя Sonic_aka_T

07-08-2005, 18:20

No, I mean have two sprite-tables ready in VRAM, call them 0 and 1. During the main loop of your game, table0 will be visible... Start updating spritetable1, so it has the correct data for the next frame. Then, at VBLANK, set the VDP's pointers to spritetable1 and return after all your vblank routines are done. This time, instead of updating spritetable1 in VRAM, you update spritetable0 in VRAM. Wait for vblank, and switch again... etc, etc... This way, you won't have to write to VRAM during the VBLANK period. You can neatly update all your coordinates in VRAM, without this being visible, and when VBLANK comes, all you'll have to do is update the pointers, not the tables themselves. Mind you, you'll prolly need to do some pre-processing on these tables in RAM tho, I guess...

By norakomi

Paragon (1123)

Аватар пользователя norakomi

07-08-2005, 19:14


I'll guess that writing to VRAM DIRECTLY instead of writing to my table in RAM is
a smarter idea, and yes, in that case it's better to do this with 2 tables.

This means that I update sprite coordinates (x,y) outside the interrupt...
I guess that right there I should also add the values of r#18 and r#23 to them coordinates???

Страница 2/3
1 | | 3