Bueno, Juan, depende de lo que quieras hacer. Para código síncrono, obviamente, tienes que contar de forma exacta los t-states: Seleniak, demos de Dvik & Joyrex, replayers de 1-bit, repayer de samples, Sp8 Invaders, ...
Volviendo al topic, si tu código es asíncrono, lo más práctico es el tradicional cambio de color de borde. Asigna un color a cada rutina y así tendrás una idea gráfica de cómo se reparte el tiempo de frame en cada una de las tareas.
Interesa también que no haya demasiada diferencia de tiempo entre las varias bifurcaciones que puede tomar tu programa, intenta que tus algoritmos estén bien balanceados, sinó puede darse un caso en que varias rutinas tarden más de lo normal y pierdas algún frame. Eso lo puedes ver por la estabilidad de las franjas de color. Si te es posible, es interesante probar el llamado
worst case scenario: la situación en la que todas las rutinas pasan por las bifurcaciones más lentas.
En cuanto a código síncrono, entonces sí que es necesario llevar una contabilidad detallada de los t-states (incluyendo las esperas extra en los ciclos M1). En el caso de Firelite, la rutina de música del Seleniak, el bucle generador de audio siempre tarda los mismos t-states, y se ejecuta en en bucle sin fin. La interrupción se encarga de, rápidamente, automodificar el bucle para que vayan sonando las diferentes notas, samples y modulaciones, así como la lectura de los dispositivos de control y animaciones.
