Normally we change the colour of the border to indicate the amount of time used by some code:
ld bc,&7f10 ;; select border
out (c),c
ld bc,&7f4b ;; set colour
out (c),c
... code
ld bc,&7f10 ;; select border
out (c),c
ld bc,&7f54 ;; set colour (different from first in this case black)
out (c),c
This changes the border colour, executes the code and changes the border back to black. The thickness of the colour in the border indicates the time taken.
We can then change the code to make it faster. When the code is faster the thickness becomes thinner. When the code is slower the thickness becomes larger.
This is great if:
- we have borders on our screen (not good if we are using overscan)
- we are timing something that takes less than a frame.
- In addition to take advantage of this, the coloured bar should start at roughly the same place every frame so that we can find it and see it easily on the screen.
How can we time something that takes more than 1 frame?
Simple, increment a number in the interrupt. The number of interrupts gives us the time taken by the function. If we make the code faster then less interrupts will have passed before it completes, if we make the code slower then more interrupts will pass.
example:
;; ensure timer is not enabled
ld a,0
ld (timer_enabled),a
;; reset timer and activate it
ld a,0
ld (timer),a
ld a,1
ld (timer_enabled),a
;; execute code
ld a,0
ld (timer_enabled),a
ld a,(timer)
;; A = number of interrupts passed during execution of code.
;;
ret
our_interrupt:
;; ...
;; interrupt code
;; ...
;; timer activated?
ld a,(timer_enabled)
or a
jr z,our_int2
;; yes, try to increment our timer variable
;; limit at 255 increments
ld a,(timer)
cp 255
jr z,our_int2
;; increment
inc a
;; store new number
ld (timer),a
our_int2:
;;...
;; interrupt code
;;...
ret
timer:
defb 0
timer_enabled:
defb 0
This method can work quite well but has the following problems:
* timing is not completely accurate, it is at worse out by 2 interrupts time (52 lines, 64 us per line).
there is time between activating the timer and the first interrupt comes.
when the code has finished executing there is some time between the last interrupt that occured and the next. so in effect we need to add 1 to the timer
to take this into account.
* timing is in 52 line sizes so any changes within that will not make a difference to the timer count.
But, if the code takes a long time, it is still useful because you can still make changes and see the timer number change.
I have used this method to help me to improve the speed of my 3d game.