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

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

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.

all sprites have a table with y,x,sprite number, reserved (not used in screen 5)

Quote:

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

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

Quote:

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

Quote:

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

Im a bit slow....
But Now I get it............
So far I have been using a sprite table in RAM, and at VBLANK I wrote this to VRAM......
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.

I get it, thanx for the tip. (you know I have been making an overview/a plan of the whole game), and have not been actively programming for a little month now,
because I noticed that I kept re-writing and re-writing routines, due to the fact that I kept finding ways to update and speedup those routines....

just like the fact that Im looking for good ways do deal with spritecollision, background/foreground collision, what to put where on which interrupt etc etc......

so, thanx again, and I'll keep gathering more and more of these useful tips before I continue with the actual programming......

(I'm hoping to find a way to make a change to Sjasm or Triasm soon as well......
...... this because Wbass2... well, I need not say more