01 - 02 - SE - 03 - 04 - 05 - 06 - 07 - 08 - 09 - 10 - 11 - 12 - 13 - 14

          This article is resting on my harddisk since ages and I never 
          got around finishing it, now since gwEm released his CPU 
          measurement program for music I decided to release it as a 
          teaser to the forthcoming part containing the example code. 
          Enjoy...

          If you code a demo or a game the amount of CPU time you can 
          consume is divided between logics, rendering and the music 
          player routine. You can easily determine the CPU time which is 
          needed to render a sprite for example because you know exactly 
          when you start the rendering routine and when you exit it. This 
          won't be possible with most of the modern YM players as we will 
          see later. For now let's focus on different methods to measure 
          the CPU consumption of a routine.

          Before digi-drums and SID FX were invented it was pretty easy to 
          determine the CPU-time-consumption of a chip music routine. 
          Heading for the easy way you could for example just change the 
          background colour, call the music routine and switch the 
          background colour back to black. This way you got a rough 
          estimate of the amount of scanlines consumed by the music 
          routine.

          More advanced routines to measure the CPU consumption used the 
          TiB line counter to measure how many scanlines were drawn while 
          the music routine was called. With some tiny adjustments you 
          could also get the maximum and minimum amount of scanlines as 
          well as the average, which might be the most important 
          information.

          However these methods are not sufficient to measure the CPU 
          consumption of decent chip routines because the main player 
          initializes several interrupts which are called more or less 
          often depending on the used frequencies, high SID voices usually 
          eat up more CPU than low ones. Also in many cases you can't use 
          the TiB because the music uses it itself for SID or digital-
          voices.

          Well of course we could add several background colour switches 
          to the SID routines to get a rough estimate, but it will flicker 
          wildly and of course since the routines are called quite often 
          per vbl we will get a false impression because of the additional 
          code used to perform the colour switches. Besides it would be 
          really hard to make a proper guess about the total amount of cpu 
          taken, since the scanlines will be scattered across the whole 
          screen.

          The same refers to our 2nd method; it will simply return results 
          which are much too big because we would need to measure it for 
          each single call of the YM routine. Besides we can only measure 
          scanline-wise which means a huge error factor if you have to add 
          lots of single measurements, like in our case. This disqualifies 
          the latter method.

          We can eradicate this error factor if we could measure the CPU 
          consumption in one go, and this should be really easy to 
          perform. Let's take a look at the circumstances that allow up to 
          measure our value.

          1st of all we need a routine that consumes the whole vbl. It 
          should be quite easy to write one at least on machines without a 
          cache a set of nested DBFs should do the job.

          2nd we need to set up an IRQ system consisting of at least 2 
          different vbl routines.

          VBL1 enables the MFP and calls the YM routine. It's also vital 
          that the "burn all CPU routine" is running while VBL1 is 
          executed. VBL1 will automatically initialize the use of VBL2.

          VBL2 disables the MFP and starts measuring the delay caused on 
          the "burn all CPU routine". Also it will initialize the use of 
          VBL1 for the next vbl.

          This way we will get an awful audible mess since the YM routine 
          is called only every other vbl but we can exactly measure how 
          much CPU it is going to cost. However there is also another 
          method, which doesn't produce such a horrible audio mess.

          You just write a short loop witch uses a given amount of CPU 
          cycles for each execution and count the number of repetitions 
          until the next vbl occurs. To get a reference value you should 
          let it run a few times with all IRQs but the vbl disabled.

          Afterwards you start your music or whatever and measure how much 
          is left of the VBL, with a simple multiplication you can now 
          determine the remaining CPU time and compare that to the CPU 
          eaten by the music.

          I hope this will help coders and chip musicians to base their 
          arguments on facts rather than on assumptions :). With the next 
          issue of Alive I will release some example code.

Cyclone / X-Troll for Alive, 2004-01-17