2 replies to this topic

[xucaen]

I've been playing around with using the timer instead of using an index. Since they both seem to produce the same results, when would I want to use a timer and when would I not want to use a timer?

;Overscan using index
OverScan LDX #30
O1       STA WSYNC
         DEX
         BNE O1

;Overscan using TIM64T
OverScan LDA #35
         STA TIM64T
O1       STA WSYNC
         LDA INTIM
         BNE O1

[supercat]

xucaen, on Mon Aug 8, 2005 11:46 PM, said:

I've been playing around with using the timer instead of using an index. Since they both seem to produce the same results, when would I want to use a timer and when would I not want to use a timer?

The timer is useful when you aren't sure how long a particular piece of code is going to take to execute. If you know precisely how long a piece of code will take to execute, adding "manually-coded" delays may be more compact than using the timer.

As a simple example, imagine that you're trying to write your own version of Adventure. You have a list of objects, and for each object you have the number of the room in which it appears. You want to select the "next" two objects that are in the current room. If you know how many objects there are, you can figure out the maximum amount of time the search can take, but if it finds two objects immediately the search may take much less time than that. Although it would be possible to code the search routine so as to take a fixed amount of time, it's much more practical to use the timer. That way, you don't care exactly how long the search routine takes--you only care that it gets done soon enough.

Note that in some cases there may not be a nice upper bound on the length of time a piece of code may take to execute. You may have a loop which will take at most 150 cycles per iteration, but you may have no idea how many iterations the loop will require. In this case, it's necessary to take a somewhat different approach to program organization and timer handling.

What you need to do is create a routine (called something like "doframe") which waits for the timer to count down to 124, then generates vsync and draws a frame, then sets the timer with a value such that it will reach 124 when it's time for the next vsync. Then not only do you call doframe within your main loop, but you also include something like this in the time-consuming parts of the program:

...
  bit INTIM
  bmi ..nothingnew
  jsr doframe
..nothingnew
  ...

In this way, your routine may take a long time to execute, and if it's updating display variables the display may show the results of some partial updates, but the system won't lose sync. This can be a good approach to use in something like a "Columns" game where the color matching procedure is reasonably fast, but not fast enough to reliably execute within one frame's vbl.

Note, btw, that if you're really tight on space, it may be useful to have a second entry point for the "doframe" routine entitled "maybeframe". This routine would perform the 'bit' operation and return immediately if INTIM>=128. Including those instructions within the routine will add an extra twelve-cycle performance hit every time the routine is called and returns immediately, but will save five bytes per call.

[Thomas Jentzsch]

My rule of thumb:
- always use timer during VBlank and Overscan
- only use timer during VSync if you really have too
- use timer during the display kernel only in early development, remove when your kernel becomes stable

Edited by Thomas Jentzsch, Tue Aug 9, 2005 1:27 AM.