Measuring the CPU
consumption of
Chipmusic
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.
The
BG-Colour Method
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.
The
Scanline Counter
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.
How
do we measure
these interrupts?
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.
Method 1 - VBL
Overflow
Measurement
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.
Method 2
VBL
Idle Measurement
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
|