A.D.A. Amiga Demoscene Archive

I've started work on a first little project.

- i'm using P61 replayer routine, with cia and level6 interrupt and using the testmodule included.
- my main loop just waits until the beam reaches position #255, then executes my routines and waits again...
- i have a sprite routine with 1 sprite, 8 times reused.

After experimenting, i've got some questions:
- i have some stuttering in the sprites (sprite moving slower for a very short time). When i don't play the music, it doesn't happen. What could be the cause (it has something to do with the P61 replayer routine)? How to solve this problem?
- i have another routine to show some text on screen, using a 1 byte wide font and using the cpu instead of the blitter to copy the font to the screen. Also, i have a blitter routine to clear the screen. Both routines cause my sprite to move slower until the text/clear routine is finished. How can i solve this?
- another question: i'm waiting for the beam to reach the end of the screen, then execute all my routines. But how can i predict that all routines will be executed before the beam again reaches the first visible lines of the screen? And more subroutines => more time needed. Can it be that the routines aren't finished before the beam reaches the visible area?

vbi and lev6 having priority. the wait of beam use the rest, the routine is slow sometimes in main loop.
put all anim in vbl interrupt or copper interrupt or use a timer in vbi, and test it in main loop for synchro.

to clear the screen, blitter is not the faster, use cpu with movem (or both sometimes are used).

and if more time needed, when anim problem even in vbi, it's time to use Double Buffering !

@Cyf:
Can you give me a bit more info on this? Are you telling me that i need to setup vbi interrupt just to be able to move sprites without any stuttering (which apparently comes from the level 6 interrupt generated by the P61 replayer routine, right?).

I don't even need timing to the music, so could i get away with using the normal vblank P61 instead of the lev6 and cia timer combination?

Should i assume that any oldskool intro is using vbi also simply to move some starfields around... (or do old replay routines don't have this problem)??

Also, i find it hard to believe that sprites move slower because the blitter is doing some copy operations?? Does this mean that, even for simple intros, i have to put all this stuff into the vbi interrupt routine??

depend on which amiga, depend of routine...
I tested blitter wipes in main loop with :
a simple wait of rasterline
wait:
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #$2800,d0 ; wait rasterline $28
bne wait


** EDIT:
or if you have a VBI interrupt, and the famous "Timer" (at the beginning of this thread) : this variable is incremented by 1 each vertical blank of the screen, in main loop :
move.l #0,Timer
wait: cmpi.l #1,Timer
bne.s wait
bsr routineinvbl
move.l #0,Timer
bra wait

the routineinvbl will be also synchronized with vbl. (and better)
No sound Timing here! but you can also use the P61 for timing by using the lev6 interrupt.

some effects works fine if you wait the good lines! and not correctly if no time.
it's a problem encountered with old games using beamwait. on 680x0 : gfx bugs, too fast...

in the p61 doc, with cia version tempo, it's write :
NOTE: If you want to use this in your own program that needs synchronizing to the beam, do one of these:

1. Do your routine in VBlank-interrupt.
2. Do your routine in copper interrupt.
3. If you do NOT have to wait for a specific line, wait for VBlank bit in
INTREQR ($1e) and clear it afterwards.
4. If you have to wait for some specified line, disable Copper-interrupt
from INTENA ($9a), set Copper-interrupt bit in INTREQ ($9c) with Copper at the specified line and wait for the bit in INTREQR ($1e) in our own routine. Clear it afterwards.

I find this an interesting topic. But i need more information on how things actually work.

Let's say i've got a routine, which is only executed when the beam reaches the end of the screen (vpos > 256?).
- How much time is there between this and the moment that the beam appears at the visible top area of the screen again?
- Is this the maximum time allowed for my routines to be finished?
- how can i be sure that my routines will be finshed in that time? (the more routines, the longer it will take to finish them)
- what happens if my routines aren't finished before the beam reaches the visible top area again?
- what is the difference between waiting for the vposr = 256 or the vbi? When just waiting for the vblank in my mainloop, can it be that the cpu is busy with something else and can't run my routine right away? At least, with vbi, i'm sure that my routine will get executed at the vbi (because of the interrupt)
- again, can i just move everything over to my vbi interrupt? The more i put in there, the longer it takes to finsih the interrupt => no time for other things in the meantime?

Can somebody give an explanation on how timing in general works. With timing, i don't mean timing to the sound. Let's not consider sound first. I mean timing in mainloop, how long it takes for the cpu/blitter/... to finish something, how i can control everything,...

how i can control everything : with hardware interrupts

the vbi is the interruption caused when raster have reached the end of screen and restart
at line 0 (start of vertical blank) of the video display frame.
you can test the vbi directly :
wait:
btst #5,$dff01f ; vbl interrupt
beq.s wait
move.w #$20,$dff01e ; vbi ok
bsr routine
bra wait

from the HRM - many things about VBL and timing
The video beam produces, with a PAL system, 312 lines, of which 256 are normally visible. Each complete set of lines (312/PAL) is called a display field. The field time, i.e. the time required for a complete
display field to be produced, is approximately 1/50th of a second for PAL.
Between display fields, the video beam traverses the lines that are not visible on the screen and returns to the top of the screen to produce another display field.

The minimum time of vertical blanking is 25 horizontal scan lines for a PAL system. The range starts at line 0 and ends at line 25. After the minimum vertical blanking range, you can control where the display
actually starts by using the DIWSTRT (display window start) register to extend the effective vertical blanking time.
If you find that you still require additional time during vertical blanking, you can use the Copper to create a level 3 interrupt. This Copper interrupt would be timed to occur just after the last line of display on the screen (after the display window stop which you have defined by using the DIWSTOP register).

some examples of demos with good "timing" :
**EDIT: error about dajormas
DaJormas use a timer incremented in lev6 for synchro parts with music, init of each effect is in mainloop BUT effects are in VBI !.
**

TEK/Rampage demo use another timing using a Software Interruption created with the copper, so vbl synchronized.

err...I dont see many other ways to time with vbl...
now, for timing a specific routine and know how many rasterlines this routine use, try to change background color before start, and restore color at the end of the routine. Or use the timer.device
Or use the timer in vbi (reset timer at start and store the value of timer at the end of the routine) and print the result under cli.

I looked at DaJormas source code and i nearly had a heart attack... i think it's a bit too early for me :) (did like the way how every screen/color/... for every effect was setup though...).

I did a lot of experimenting but i haven't reached a conclusion yet on the vbi/vblank. Damn...why aren't there any good books about these kind of things... :(

Some facts:
- i have programmed a counter in vbi, let's say vbcounter
- i have a routine which waits for the beam to reach the end of the screen (say waitendofscreen), checking for vpos > 255.

- i assume that the end of the screen will be the first to be reached, because vbi only interrupts at line 0 of screen. Is that correct.

In my mainloop, i have several possibilities (don't mind the code, it's just the way of thinking i want to explain):

main:
cmpi.l #1,vbcounter
bne main
clr.l vbcounter
bsr domyspriteroutine
bra main

(in this case, the first use of my sprite stutters, the reuses of that sprite on the next lines are always smooth, and this regardless of music)

other possibility:
main:
waitendofscreen (loops in here until vpos > 255)
cmpi.l #1,vbcounter
bne main
clr.l vbcounter
bsr domyspriteroutine
bra main

last possibility:
main:
cmpi.l #1,vbcounter
bne main
waitendofscreen (loops in here until vpos > 255)
clr.l vbcounter
bsr domyspriteroutine
bra main

(this seems to be the most stupid one because waitendofscreen will happen after vbi interrupt).

Anyone can comment on this or am i way off and completely stupid.
btw. i have encountered the weirdest things. When an interrupt appears from the P61 player routine, my vbcounter never counts again in my level 3 interrupt routine.

if you use waitendofscreen with vbcounter at the same time, you can count between the start of vbi (line 0) and the end of screen reached by the beam, change color and/or put the routine between the 2 waits.

... test the best way according to the type/speed of routines.
if not work fine with a simple wait rasterline, put it in vbi or copper interrupt to speed the display...

it's time I handed over... TDC help ! ^^

hi!!
sorry for the delay, in these days I moved from Zurich to Italy, no time to use the net!

@z5: the last line of the display is not line 255. It depends on the video-mode.
For pal it is 312, if I remember right. For NTSC is something around 270.
Please refer to the HRM.
So, if you wait for line 255, you wait for the video-beam to e in the middle of the display => trouble.
You should try to execute every routine which affects the display, (both sprites and playfield) during the Vertical Blank interval. As Cyf reported it is line 25 of the display. If not, you will notice the changes: i.e. suppose your effect is executed in lines 100-110. Then the display is formed by the visibile lines above 100 before the effect mixed with other lines while the routine is changing them, and with lines already changed.
My advise is to syncronize wuth line 1.
If you need more time than the vblank interrupt, you need buffering, double, triple or more.

on AmyCoders ( http://membres.lycos.fr/amycoders/ ), there is a good tuto about Frame Timing (and lot of others tutos)

and a good tiny startup code for the compos.
it use the cia-a eventcounter for timing display:

move.b $bfe801,d0
wait:
cmp.b $bfe801,d0
beq.s wait