Ps 2

Arquitectura PlayStation2
Nosotros
Indice general
1. Denicion de objetivos y especicaciones 1
1.1. Denicion de objetivos y especicaciones . . . . . . . . . . . . . . . . . 1
1.1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2. Proyecto a realizar . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3. Especicacion de la aplicacion . . . . . . . . . . . . . . . . . . 3
1.1.4. Estado actual y antecedentes . . . . . . . . . . . . . . . . . . . 3
1.1.5. Antecedentes bibliogracos disponibles . . . . . . . . . . . . . . 5
1.2. Introduccion a la arquitectura de la PlayStation2 . . . . . . . . . . . . 6
1.2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. La consola de juegos PlayStation 2 . . . . . . . . . . . . . . . . 6
1.2.3. La arquitectura de la PlayStation 2 . . . . . . . . . . . . . . . . 8
1.2.4. El Emotion Engine (EE) . . . . . . . . . . . . . . . . . . . . . 13
1.3. La consola de videojuegos PlayStation2 . . . . . . . . . . . . . . . . . 17
1.3.1. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.2. Expansion y accesorios . . . . . . . . . . . . . . . . . . . . . . 20
1.3.3. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.4. Que le falta a la consola . . . . . . . . . . . . . . . . . . . . . 22
1.3.5. Algunos comentarios sobre la PlayStation2 . . . . . . . . . . . . 25
1.3.6. Curiosidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2. Estudio del hardware: el Emotion Engine 29
2.1. Apendice. El EE a fondo . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2. Mapa de memoria . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.3. El EE Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.4. El Controlador de interrupciones (Interrupt Controller, INTC) . 40
2.1.5. TIMER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.1.6. El controlador de DMA (DMA Controller, DMAC) . . . . . . . 41
2.1.7. Interfaz del GS (GIF, GS Interface . . . . . . . . . . . . . . . . 43
2.1.8. Unidad de procesamiento de imagenes (IPU, Image Data Processor 45
2.1.9. SIF, Sub-CPU Infertace . . . . . . . . . . . . . . . . . . . . . . 47
3. Desarrollo del proyecto 49
3.1. Desarrollo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.1. Especicacion de las tareas . . . . . . . . . . . . . . . . . . . . 49
3.1.2. Metodo de programacion de la consola . . . . . . . . . . . . . . 50
3.1.3. Programacion de las unidades . . . . . . . . . . . . . . . . . . 52
3.1.4. Distribucion en las unidades . . . . . . . . . . . . . . . . . . . 54
3.2. Implementacion del proyecto . . . . . . . . . . . . . . . . . . . . . . . 54
i
ii

INDICE GENERAL
3.2.1. Decodicacion de sonido . . . . . . . . . . . . . . . . . . . . . 54
3.2.2. Reproduccion de sonido . . . . . . . . . . . . . . . . . . . . . . 58
3.2.3. Modelo graco. Procesamiento de audio . . . . . . . . . . . . . 58
3.2.4. Deteccion de la cadencia de la cancion . . . . . . . . . . . . . . 66
3.2.5. Reimplementacion del plugin graco . . . . . . . . . . . . . . . 67
4. Optimizacion del programa sobre el hardware 89
4.1. Uso de la VU0 como ayuda del MIPS . . . . . . . . . . . . . . . . . . 89
4.1.1. Programacion in line de la VU0 como preprocesador . . . . . . 89
4.2. Secciones de codigo a optimizar . . . . . . . . . . . . . . . . . . . . . 92
4.2.1. Procesamiento de frecuencias a conjuntos de frecuencias . . . . 93
4.2.2. Procesamiento de los conjuntos de frecuencias . . . . . . . . . . 96
4.3. Analisis de la ganancia obtenida . . . . . . . . . . . . . . . . . . . . . 97
5. Formato Ogg Vorbis 99
5.1. Introduccion al formato . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.2. Funcionamiento general del decodicador . . . . . . . . . . . . . . . . 100
5.2.1. Conguracion del decodicador . . . . . . . . . . . . . . . . . . 100
5.2.2. Pasos de la decodicacion . . . . . . . . . . . . . . . . . . . . 101
5.3. Conguracion del codec y decodicacion del paquete . . . . . . . . . . 103
5.3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.2. Decodicacion de la cabecera y conguracion del decodicador . 103
5.3.3. Decodicacion y sntesis de paquetes de audio . . . . . . . . . . 107
5.4. Floor 0: conguracion y decodicacion . . . . . . . . . . . . . . . . . . 112
5.4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.4.2. Formato Floor 0 . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.5. Floor 1: conguracion y decodicacion . . . . . . . . . . . . . . . . . . 115
5.5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.5.2. Formato Floor 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.5.3. Decodicacion de la cabecera . . . . . . . . . . . . . . . . . . . 117
5.5.4. Decodicacion del paquete . . . . . . . . . . . . . . . . . . . . 119
5.5.5. Calculo de la curva . . . . . . . . . . . . . . . . . . . . . . . . 120
5.6. Conguracion y decodicacion de los residuos . . . . . . . . . . . . . . 122
5.6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6.2. Formato de residuos . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6.3. Decodicacion de los residuos . . . . . . . . . . . . . . . . . . 124
5.7. Funciones auxiliares de la implementacion . . . . . . . . . . . . . . . . 129
5.7.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6. Apendices 133
6.1. Principios de la Informatica Graca . . . . . . . . . . . . . . . . . . . . 133
6.1.1. Transformaciones en 2D . . . . . . . . . . . . . . . . . . . . . . 133
6.1.2. Transformaciones en 3D . . . . . . . . . . . . . . . . . . . . . . 136
6.1.3. Proyecciones de visualizacion . . . . . . . . . . . . . . . . . . . 137
Glosario I
Bibliografa V
Indice de cuadros
1.1. Rendimiento del GS para las distintas primitivas y opciones disponibles . 12
1.2. Principales caractersticas de la consola comparada con las que ofrecen
sus mas directas competidoras en el mercado. . . . . . . . . . . . . . . 23
2.1. Organizacion de la memoria cache. . . . . . . . . . . . . . . . . . . . . 34
2.2. Signicado de las siglas de las etapas del cauce de la FPU. . . . . . . . 39
2.3. Signicado de las siglas de las etapas de los cauces del EECore. . . . . 39
2.4. Interrupciones que es capaz de controlar el modulo INTC. . . . . . . . . 40
2.5. Disponemos de diez canales DMA para realizar transferencias. . . . . . 41
3.1. Antes de especicar la lista de informacion, se debe denir el tipo de
primitiva y las caractersticas que tendra. . . . . . . . . . . . . . . . . . 82
3.2. Registros existentes para especicar informacion asociada a un vertice. . 83
iii
iv

INDICE DE CUADROS
Indice de guras
1.1. Arquitectura interna del Emotion Engine de la PlayStation2 . . . . . . . 2
1.2. Diagrama de dependencia entre las principales tareas . . . . . . . . . . 3
1.3. Onda de audio digitalizada . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Plugin de visualizacion ((Iris)) para XMMS . . . . . . . . . . . . . . . . 5
1.5. Esquema de la disposicion de las unidades, junto a las entradas/salidas 10
1.6. Arquitectura del sintetizador graco . . . . . . . . . . . . . . . . . . . 11
1.7. Estructura del EE, a nivel de unidades y buses entre las mismas . . . . 14
1.8. Esquema de memoria de la PlayStation2 . . . . . . . . . . . . . . . . . 16
1.9. Arquitectura de las memorias de la PlayStation2 . . . . . . . . . . . . . 17
1.10. Imagen de una PlayStation2 . . . . . . . . . . . . . . . . . . . . . . . 18
1.11. Imagen de los componentes del kit de linux . . . . . . . . . . . . . . . 20
1.12. PlayStation2 conectada al kit de desarrollo DTL-T10000. . . . . . . . . 24
1.13. Planta de fabricacion de Sony en Nagasaki. . . . . . . . . . . . . . . . 25
1.14. Resultado de un modding por parte de un usuario de PlayStation2. . . . 27
2.1. Cauce de renderizado y asociacion a una unidad funcional de la consola 29
2.2. Reparto de las tareas mas habituales entre el hardware de la consola. . . 30
2.3. Estructura interna del Emotion Engine . . . . . . . . . . . . . . . . . . 31
2.4. Mapa de memoria del Emotion Engine . . . . . . . . . . . . . . . . . . 31
2.5. Estructura interna del EECore . . . . . . . . . . . . . . . . . . . . . . 33
2.6. Organizacion de la cache de datos y la cache de instrucciones. . . . . . 34
2.7. (a) La conexion de la SPR con la CPU y con la memoria externa a
traves de DMA, (b) la CPU y la memoria accediendo concurrentemente
al SPR para grabar y leer datos respectivamente. . . . . . . . . . . . . 35
2.8. Disposicion de distintos tipos de transmision a memoria. . . . . . . . . 36
2.9. Registros que conforman la Unidad de Punto Flotante . . . . . . . . . . 38
2.10. Cauce de la Unidad de Punto Flotante . . . . . . . . . . . . . . . . . . 38
2.11. Etapas de los cauces del EECore. . . . . . . . . . . . . . . . . . . . . . 39
2.12. Ejemplo de transferencia de una region rectangular de entre la memoria
principal y la SPR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.13. Posibles caminos hacia el GIF, seg un la unidad funcional de origen. . . . 43
2.14. Estructura de la Unidad de Procesamiento de Imagenes . . . . . . . . . 45
2.15. Con un n umero reducido de colores se puede conseguir una textura de
gran calidad, como se puede comprobar. Cada textura usa tan solo 4
bits de color. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.16. Proceso de decodicacion de MPEG2 empleando el IPU. . . . . . . . . 46
2.17. Estructura del SIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
v
vi

INDICE DE FIGURAS
2.18. Flujo en una transferencia de datos entre el IOP y la memoria del Emo-
tion Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1. Uso normal de los procesadores que conforman el Emotion Engine . . . 49
3.2. Cable PL2301 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3. Esquema para la ejecucion de un programa en las unidades vectoriales . 53
3.4. Criterio a seguir para la distribucion inicial de las tareas . . . . . . . . . 54
3.5. Tareas de las que se compone la decodicacion de Ogg Vorbis . . . . . 55
3.6. Entrelazado de los canales . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7. Un ejemplo de la salida mostrada por top . . . . . . . . . . . . . . . . 57
3.8. Orden de conguracion del dispositivo . . . . . . . . . . . . . . . . . . 59
3.9. Ejemplo de espectograma (abajo) y se nal de origen (arriba) . . . . . . . 59
3.10. Se nal en el dominio en tiempo y en el dominio en frecuencia . . . . . . 60
3.11. La funcion original (a) es distinta de cero en un intervalo T de tiem-
po. Su transformada de Fourier (b) no tiene limitacion por ancho de
banda, pero tiene amplitud en todas sus frecuencias. Si muestreamos
con el intervalo como aparece en (a), la transformada de Fourier (c)
esta denida entre f
c
. La potencia fuera de ese rango se desplaza a
dicho rango. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.12. Reordenacion de un vector (longitud 8 en este caso) por inversion de
bits, (a) entre dos vectores, (b) en un vector . . . . . . . . . . . . . . . 64
3.13. Para poder considerar un espectro de frecuencia sucientemente amplio
con un n umero bastante reducido de barras a representar, necesitamos
denir unas ((bandas de frecuencia)), considerando que cualquier frecuen-
cia contenida en dichas bandas pertenece a un ((conjunto de frecuencia)) 66
3.14. De una onda (rojo) se puede estimar los golpes de ritmo (verde).
Aqu hemos representado todo el buer de 1024 muestras como gol-
pe de ritmo, ya que calculamos la existencia o no de cadencia para cada
uno de ellos, y no para muestras concretas. . . . . . . . . . . . . . . . 68
3.15. Arquitectura de las VU dentro del Emotion Engine . . . . . . . . . . . 71
3.16. Arquitectura de las VU en profundidad . . . . . . . . . . . . . . . . . . 72
3.17. Proceso necesario para obtener el codigo objeto desde el chero ensam-
blador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.18. Descomposicion en bloques del sintetizador graco. . . . . . . . . . . . 78
3.19. Flujo de datos del sintetizador graco. . . . . . . . . . . . . . . . . . . 80
3.20. Desplazamiento realizado en la cola de vertices como consecuencia de
un vertex kick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1. Flujo de datos que sigue la implementacion del clasicador de frecuen-
cias en conjuntos de frecuencias: (a) en el MIPS, (b) el ujo de datos
perteneciente a la implementacion en la VU0. . . . . . . . . . . . . . . 95
4.2. Flujo de datos que sigue la implementacion del procesamiento de con-
juntos de frecuencias: (a) en el MIPS, (b) el ujo de datos perteneciente
a la implementacion en la VU0. . . . . . . . . . . . . . . . . . . . . . . 97
5.1. Componentes del decodicador de Ogg Vorbis . . . . . . . . . . . . . . 99
5.2. Tipo de solapamiento entre ventanas consecutivas. . . . . . . . . . . . 102
5.3. Reconstruccion del oor con dos puntos, y calculo de la diferencia en
Y con respecto a la estimacion inicial. . . . . . . . . . . . . . . . . . . 116
5.4. Realizamos la correccion de la Y anterior y calculamos las nuevas para
32 y 96. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
INDICE DE FIGURAS vii

5.5. Proseguimos renando la curva con los valores asociados, corrigiendo
cuando es necesario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.6. Cuando todos los valores se han calculado, tenemos la reconstruccion
de la curva original. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.7. Empaquetamiento de los residuos. . . . . . . . . . . . . . . . . . . . . 123
5.8. Codicacion y decodicacion de un residuo de tipo 2. . . . . . . . . . . 125
6.1. El espacio de coordenadas XY W, con el plano W = 1 y el punto
P(X, Y, W) proyectado en el. . . . . . . . . . . . . . . . . . . . . . . . 135
6.2. Sistema de coordenadas de la mano derecha. . . . . . . . . . . . . . . 136
6.3. Tipos de proyecciones: paralela, conservando angulos y distancias, y
perspectiva, conservando solo angulos. . . . . . . . . . . . . . . . . . . 137
6.4. Calculo de la proyeccion en perspectiva P
del punto P. . . . . . . . . 138

6.5. Proyeccion perspectiva y proyeccion paralela, y objetos reales que pro-
ducen dicha proyeccion. . . . . . . . . . . . . . . . . . . . . . . . . . . 139
viii

INDICE DE FIGURAS
Captulo 1
Denicion de objetivos y
especicaciones
En este captulo comentaremos lo que se pretende con este proyecto, as como
las opciones que se barajan inicialmente, el panorama actual en el que se encuentra el
campo al que afecta este proyecto de forma directa o indirecta, y la informacion que a
este efecto se puede obtener por los distintos medios.
1.1. Denicion de objetivos y especicaciones
1.1.1. Objetivo
El principal objetivo de este proyecto es demostrar la validez de la arquitectura de
la PlayStation2 como plataforma didactica sobre la que desarrollar los conocimientos
recibidos sobre distintas arquitecturas.
Tras haber recibido una formacion variada sobre la arquitectura x86 principalmente
como maximo exponente de los procesadores de proposito general, se ha recibido un
complemento practico acorde debido a la gran cantidad de procesadores basados en
dicha arquitectura que existen tanto en los hogares como en los centros de estudio,
pues se trata de la arquitectura mas difundida y usada entre los usuarios. La carencia
radica en el resto de arquitecturas difciles de conseguir, ya que las microarquitecturas
como PIC, o las FPGA s disponen de asignaturas en las que se recibe la pertinente
instruccion practica en la que se ponen de maniesto las ventajas y desventajas de
dichas arquitecturas. Sin embargo, hay un conjunto de arquitecturas sobre las que no
se realiza ninguna taera practica para hacer comprender que realmente existen en el
mercado actual, y no son meros dise nos posibles en los que no se trabaja.
Es un hecho comprobado que un ejercicio practico sobre los contenidos teori-
cos ayudan a rearmar y aclarar conceptos. La PlayStation esta compuesta de varias
unidades, con distintas arquitecturas, como se representa en la Figura 1.1. Su proce-
sador principal, un procesador de proposito general, no forma parte de la familia de
los x86, pues es un derivado del MIPS III. Esto implica poseer un repertorio distinto
de instrucciones, ademas de ser un procesador RISC puro, reejando tambien dichas
caractersticas en su repertorio. Ademas, posee un par de unidades vectoriales VLIW,
que aporta un paradigma de programacion distinto al habitual cuando se programa un
procesador de proposito general, ya sea programando al nivel mas bajo o bien a un
nivel superior de abstraccion. Estas tres unidades, junto a un coprocesador matemati-
1
2 CAP
ITULO 1. DEFINICI
ON DE OBJETIVOS Y ESPECIFICACIONES
Figura 1.1: Arquitectura interna del Emotion Engine de la PlayStation2
co de apoyo al procesador MIPS, forman el centro de procesamiento de calculo de la
maquina.
Aparte posee un MIPS I como procesador de gestion de entrada/salida y un pro-
cesador graco totalmente independiente dedicado exclusivamente a la representacion
graca, liberando de dicha tarea al resto de componentes y logrando un procesamiento
paralelo mayor.
1.1.2. Proyecto a realizar
Disponiendo de una variedad de unidades de procesamiento interconectadas para
realizar tareas en paralelo, optamos por intentar aprovechar la mayor cantidad posible
para distribuir la carga de una aplicacion en tiempo real, con lo que deberamos usar
tanto el procesador principal de proposito general como las unidades VLIW, a nadiendo
la ejecucion de todas de forma sincronizada y en paralelo.
La apliacion elegida fue un reproductor con una visualizacion sincronizada del
formato Ogg Vorbis [23] de compresion de audio, por una serie de razones que expon-
dremos a continuacion:
la descompresion de sonido es algo muy habitual hoy en da: consideramos que es
un tema de bastante relevancia en el sentido de ser algo practico, interesante y
sucientemente motivante para tener una vala didactica frente a otras posibles
aplicaciones que llamen menos la atencion del alumnado.
posee unos requisitos de tiempo real bastante importantes: es una aplicacion
de tiempo real crtico, ya que un retraso de menos de un segundo provoca una
interrupcion en el sonido, siendo facil su deteccion durante las pruebas, y una
prioridad ante todo.
se debe generar una salida auditiva: hace uso del dispositivo de sonido, aumen-
tando la vision practica del proyecto al aportar una caracterstica esencial del
mundo multimedia.
hace uso de la unidad graca: no solo necesita el procesamiento de calculo y
la reproduccion del sonido, sino que se necesita profundizar mnimamente en
el funcionamiento de la unidad graca para poder mostrar la evolucion de la
cancion, tambien en tiempo real y de forma sincronizada con la salida de audio.
1.1. DEFINICI
ON DE OBJETIVOS Y ESPECIFICACIONES 3
uso del formato ogg vorbis frente a otros formatos de compresion: nos centramos
en el soporte de un formato de compresion libre y sin patentes al contrario que
el resto de formatos de compresion con perdidas de audio, que estan sujetos a
patentes, como es el caso del popular MP3.
1.1.3. Especicacion de la aplicacion
Como hemos esbozado, se trata de realizar una aplicacion que sincroniza la repro-
duccion de audio con la visualizacion de dicho audio. Por tanto, podemos distinguir
tres tareas basicas:
decodicacion del chero ogg vorbis en muestras de audio: realiza todo el
proceso de decodicacion del chero comprimido, transformando las tramas de
ogg vorbis en formato de codicacion por pulsos interpretables por el sistema de
audio.
reproduccion del sonido decodicado: una vez decodicado, hay que enviarlo
a la salida de audio a la correspondiente frecuencia, canales y tipo de dato.
visualizacion del sonido decodicado: con el sonido a reproducir se debe calcu-
lar una serie de propiedades de ese fragmento que sean representables de forma
graca, para crear una imagen que se corresponda con dicho fragmento.
Es inmediato ver la dependencia de las tareas que tenemos a nuestra disposicion.
Si representamos de forma graca dicha dependencia, obtenemos el arbol de la Figura
1.2. Cada tarea se descompondra en subtareas mas detalladas como se mostrara pos-
teriormente en secciones siguientes y en apendices a nal del documento. En este
apartado trabajaremos desde el punto de vista global de la aplicacion, sin profundizar
en los distintos aspectos que la componen.
Figura 1.2: Diagrama de dependencia entre las principales tareas
1.1.4. Estado actual y antecedentes
Ya expusimos la actualidad de este tipo de aplicaciones como uno de los motivos
que nos llevaron a su eleccion. En el uso habitual de cualquier ordenador domestico entra
como tarea la reproduccion de audio. Aunque este proyecto no trata de la compresion
de una se nal de audio, es un hecho de vital relevancia y diaria investigaci on. Es la base
de muchas de las aplicaciones de sonido que existen hoy da, ya que sin los metodos
de codicacion de audio, sera inmanejable la cantidad de informacion que tendra que
4 CAP
ITULO 1. DEFINICI
circular por los distintos buses del sistema, y la ingente cantidad de espacio necesario
para poder almacenarlo.
Supongamos que queremos oir una cancion a una calidad lmite de la audicion
humana. Para ello, necesitamos que este en un formato ((calidad CD)), que no es mas
que 44 100 muestras por segundo, que es el lmite psicoac ustico del odo humano, con
muestras de 16 bits y en dos canales (el estereo basico).
Figura 1.3: Onda de audio digitalizada
Tenemos entonces que, para un segundo, debemos almacenar 44 100 muestras
de 16 bits (2 bytes) por canal. La Figura 1.3 muestra una onda digitalizada a dichos
parametros. Eso hacen 44 100 2 2 176 400 bytes por segundo. Una cancion
normal de 4 minutos, ocupara 176 400 60 4 40, 38 Mbytes. Es evidente que es
necesario encontrar alg un metodo de compresion de sonido. Recordemos que esto era
para una muestra en estereo. Con un Dolby Digital, que tiene seis canales de sonido,
necesitaramos tres veces mas de espacio, lo que implica que para la cancion de 4
minutos, necesitaramos aproximadamente 121, 12 Mbytes.
Hemos expuesto ya el codicador que usaremos, y un esbozo de las razones que
nos han llevado a elegirlo. Este formato, ogg vorbis, comparte gran parte de las ca-
ractersticas de cualquier codicador alternativo de semejante proposito: posee una
codicacion costosa en tiempo, en favor de una descodicacion muy rapida, apta para
una aplicacion de tiempo real, como es el caso. Se trata por tanto de un metodo de los
denominados asimetricos, debido a la distinta complejidad que supone su codicacion y
su descodicacion. Hay otro tipo de algoritmos de compresion, llamados simetricos, en
los que el tiempo de codicacion y descodicacion son similares, aunque no alcanzan
las caractersticas de calidad de los asimetricos. La nalidad de los algoritmos simetri-
cos esta orientada a conferencias en tiempo real, donde se necesita estar codicando y
descodicando de forma constante lo mas rapido posible.
Con nuestra eleccion intentamos dar soporte a un formato de codicacion asimetri-
ca de alta calidad, libre de patentes y con un gran soporte por parte de sus creadores,
tanto a nivel de documentacion como a nivel de implementaciones disponibles para
distintas plataformas.
La otra parte de la aplicacion conforma una demostracion multimedia, algo indis-
pensable hoy da. Relacionado con nuestra aplicacion, encontramos diversas muestras
de lo que pretendemos hacer, principalmente como plugins de visualizacion de los prin-
cipales reproductores multimedia, como bien pueden ser Winamp, Sonique, Windows
Media Player o XMMS [46] entre muchos otros. En este caso, optaremos por el pro-
grama XMMS como modelo a seguir por temas de soporte hacia el programador. En
la gura 1.4 se muestra uno de estos plugins gracos, concretamente el plugin ((Iris)),
disponible en la direccion http://cdelfosse.free.fr/xmms-iris/.
Sin embargo, la parte relativa a la programacion en el hardware de la PlayStation2
1.1. DEFINICI
ON DE OBJETIVOS Y ESPECIFICACIONES 5
Figura 1.4: Plugin de visualizacion ((Iris)) para XMMS
esta practicamente indocumentada y sin soporte de ning un tipo. Aunque hay
aplicaciones desarrolladas para la maquina a tratar, ninguna esta destinada al aprendi-
zaje de la programacion, y son poco mas que meros productos nales, creaciones de
gente que ha pasado una dura curva de aprendizaje y por un motivo u otro no dedica
el tiempo necesario a facilitar el camino a nuevos interesados en esta maquina.
De hecho, sin comprar ning un producto externo a la consola propiamente dicha,
la unica forma de programarla es mediante el empleo de un compilador cruzado y unas
bibliotecas mnimas creadas por un grupo de gente sin soporte de Sony de ning un tipo
cuyo pasatiempo es desenmara nar los secretos de la maquina. El principal problema
que se encuentra es el que las propias palabras de uno de sus maximos exponentes
de estas bibliotecas: ((es mas divertido programar que documentar)). Aunque tenemos
un conjunto de bibliotecas para compilar de forma cruzada a la maquina, volvemos a
tener una notable carencia de informacion sobre que o como se hace algo. El principal
metodo de aprendizaje es el ensayo y error, cosa no muy recomendable para nuestro
objetivo ultimo, que es mostrarle al alumno la programacion de una arquitectura
distinta de forma didactica.
Si disponemos de fondos sucientes, podemos adquirir cierto soporte de Sony a
la hora de desarrollar los programas, pues dispone de un kit [14] de desarrollo bajo el
sistema operativo GNU/Linux para la consola, con manuales sobre las principales uni-
dades funcionales includos. Esto supone una ventaja y una desventaja con respecto al
metodo anterior: tenemos mas soporte e informacion para la programacion, si bien al-
gunas unidades quedan ocultas por el sistema operativo y las aplicaciones desarrolladas
solo funcionaran en una PlayStation2 que tenga el kit de Linux instalado.
Un tercer metodo descartado desde el inicio es el que recibe un soporte completo
de Sony, tanto a nivel de herramientas de desarrollo como de informacion, incluyendo
una maquina PlayStation2 especial para desarrollo. El principal inconveniente de este
sistema es la necesidad de estar reconocido como un desarrollador ocial por Sony, cosa
difcil de conseguir, y mas para nuestro proposito.
1.1.5. Antecedentes bibliogracos disponibles
A pesar de su aparicion en el mercado hace varios a nos, su enfoque principalmente
orientado a ser un producto nal de ocio y consumo destinado al entretenimiento
interactivo de los usuarios hace que la documentacion otorgada de forma p ublica sea
mas bien inexistente. Es mas, Sony ha hecho una especie de campa na en cierta forma
elitista en lo que a su programacion se reere. No otorga soporte de ning un tipo
a la programacion de la consola si no hay un contrato por medio. En cierta forma
6 CAP
ITULO 1. DEFINICI
es comprensible, ya que la clase de programadores que quiere Sony para su consola
son parte de estudios de desarrolladores de videojuegos con suciente calidad como
para poder crear un producto de deleite que atraiga mas usuarios a su consola. El
programador ((free-lance)) o el usuario curioso con el suciente conocimiento como
para querer probar a hacer cosas en la maquina por mero placer no son el perl de
programador que le interesa.
Como un esfuerzo de desarrollo sobre la maquina, construdo desde cero sin so-
porte de ning un tipo por Sony, podemos encontrar el gran proyecto de PS2DEV [19].
Han desarrollado una serie de bibliotecas basicas para la programacion de la consola,
as como una peque na serie de tutoriales, codigos de ejemplo, demos y algunas he-
rramientas y proyectos que pueden facilitar el inicio de la gente a la programacion de
la consola sin soporte de Sony. El principal inconveniente es la necesidad de tener un
((mod-chip)) en la consola para poder arrancar los programas.
Dentro del soporte que Sony proporciona a los usuarios que no estan registrados
como un desarrollador ((serio)) de productos para la PlayStation2, sin compa nas que
respalden un producto de calidad, ni publicistas que puedan distribuirlos por el mer-
cado, solo encontramos el ya mencionado kit de Linux. Sony proporciona una serie
de manuales en el soporte digital, basicamente los repertorios de instrucciones de las
unidades y algunas consideraciones de uso. Dentro del sistema, solo se encuentran dis-
ponibles un par de ejemplos con el codigo fuente ligeramente comentado como principal
fuente de informacion, parte de los ejemplos de la biblioteca ps2dev [13].
Para este metodo, s podemos encontrar ciertas referencias introductorias por la
red. Un ejemplo es el peque no tutorial [21] escrito por Sarah Ewen, publicado en
el portal de Sony para el Linux de la PlayStation. Tambien encontramos una breve
introduccion [36] por Rob Louie al uso del kit de linux en la WEB de GameDev [5],
donde se muestra un programa mnimo para proporcionar un cambio de modo graco y
un dibujado de una malla en la pantalla, aunque sea usando unicamente el procesador
principal.
Respecto a la unidad vectorial, encontramos un tutorial bastante interesante de-
nominado Harnesses [45], confeccionado como ayuda para la participacion en el VU
Demo Coding Contest [15], una competicion que realiza Sony cuyo objetivo princi-
pal es confeccionar una demo lo mas impresionante gracamente usando unicamente
la VU1.
1.2. Introduccion a la arquitectura de la PlayStation2
1.2.1. Introduccion
Esta secccion pretende ser una introduccion didactica a la arquitectura de la con-
sola PlayStation 2. Se tratara la arquitectura de forma general para no perder el n
didactico y no aburrir al lector y se profundizara en cada seccion que lo requiera me-
diante los apendices.
1.2.2. La consola de juegos PlayStation 2
Aunque en esta seccion nos centraremos en la arquitectura de la PlayStation 2
y en especial en el microprocesador que hace las veces de corazon de la misma no
conviene olvidar que esta es una plataforma de ocio e interesa ralizar una introduccion
a sus caractersticas para que el lector nunca pierda la perspectiva. Haremos aqu una
muy breve descripcion. En el apedice ((La consola de juegos PlayStation 2)) se puede
1.2. INTRODUCCI
ON A LA ARQUITECTURA DE LA PLAYSTATION2 7
encontrar informacion completa y descriptiva acerca de la consola.
La PlayStation 2 salio al mercado en el a no 2001
1
al despues de la gran espectacion
causada en el mercado internacional. Es una plataforma de ocio mas que una consola,
pues no solo esta orientada a poder jugar con ella, sino que ofrece unas reconociadas
capacidades multimedia. En lo que respecta a los juegos, claramente esta orientada
juegos 3D. Pero esta plataforma tambien permite al usuario reproducir video DVD y
reproducir CDs de audio, lo que la convierte en un centro integral de entretenimiento
domestico.
Debajo de la elegante cubierta exterior oscura
2
de la consola PlayStation 2 hay
una completa central electronica. Es uno de los equipos de juegos mas potentes jamas
creados, la consola PlayStation 2 es realmente potente en el interior de su esbelta
cubierta, para que todos los juegos, los CDs que oigas o los DVDs que veas sean una
experiencia unica. Los detalles pormenorizados de la consola PlayStation 2, se muestran
a continuacion:
El corazon de la PlayStation 2 es el chip Emotion Engine. Este chip, con la ayuda
de la memoria principal y el sintetizador de gracos, permite a PlayStation 2 mover
una cantidad impresionante de polgonos en la pantalla del televisor (que en conjunto
forman los gracos en pantalla). Estas son sus caractersticas principales:
Chip Emotion Engine multimedia personalizado de 128 bits para CPU
Frecuencia de reloj del Sistema: 294 912MHz
Memoria Cache: Instrucciones 16KB, Datos 8KB + 16KB (ScrP)
Memoria Principal: 32MB
Ancho de banda del Bus de memoria: 128 bits DMA
Coprocesador: 2 Unidades paralelas de operaciones vectoriales
Actuacion del Punto Fluctuante: 6,2 GFLOPS
Transformacion Geometrica 3D CG: 66 millones de polgonos por segundo
Descodicador de compresion de imagen: MPEG2
El rendimiento del procesador graco de la PlayStation 2 es excelente. Con el
exclusivo chip del sintetizador de gracos que incorpora, sus gracos cobran vida.
Sintetizador graco
Frecuencia de reloj del Sistema: 147MHz
Memoria interna 4MB DRAM
Velocidad del frame buer: 38,4 Gbytes/seg.
Velocidad de dibujado: 2,4 Gpxeles/s
Con un signicado tan simple como Entrada/Salida, los sistemas E/S de PlayS-
tation 2 aseguran un funcionamiento sin problemas de la consola. Ademas el procesador
de entrada/salida de la PlayStation 2 es la CPU de la PlayStation mejorada, do que
asegura una compatibilidad al 100
N ucleo de la CPU: CPU de PlayStation mejorada
Frecuencia de reloj: 37,5MHz
Memoria IOP: 2MB
Sub Bus: 32-bit
Respecto al sonido la PlayStation 2 presenta una procesador de sonido de hasta
48 canales.
N umero de Voces: 48 canales con sonido surround 3D
Memoria de la seleccion de sonido: 2MB
Frecuencia de Salida: Hasta 48 KHz (calidad DAT)
1
Esto fue al mercado internacional, en realidad se llevaba comercializando en Japon desde su
presentacion el 4 de Mayo del 2000
2
Aunque este mismo a no estan saliendo al mercado versiones de distintos colores
8 CAP
ITULO 1. DEFINICI
En lo que respecta a la capacidad de almacenamiento, la PlayStation 2 incorpora
un DVD con estas caractersticas:
Tama no maximo: Doble capa 9GB
Velocidad del Dispositivo DVD-ROM: velocidad aproximada de 4X. CD-ROM:
velocidad aproximada de 24X.
La PlayStation 2 tambien incorpora varias interfaces que la dotan de gran versa-
tilidad, son las siguientes:
Tipos de interfaz
Serial Bus Universal (USB) x 2
Puerto de mando x 2, ranura para MEMORY CARD x 2
Salida

Optica Digital
Adaptador de red
En la pagina ocial de Sony [7] podemos encontrar ademas de estas caractersticas
un completo catalogo de complementos de la consola
1.2.3. La arquitectura de la PlayStation 2
La PlayStation 2 esta dise nada para conseguir unas altas prestaciones, sobre todo
en lo referente a juegos 3D. Es esta caracterstica la que va a condicionar toda la
arquitectura. Las caractersticas del cauce general de renderizacion 3D son las que
marcan la arquitectura de la PS2. A diferencia de un PC, donde hay un procesador
principal, un bus de sistema mediente el que se accede a la memoria principal y una
cache mas o menos pequea n, el EE se compone de vaios procesadores con peque nas
cache e interconectados por rapidos buses.
Por su diferente arquitectura, la losofa de programacion de una maquita y otra
deben ser radicalmetne distintas. Haciendo una a analoga, programar un PC sera tener
((unos grandes cubos de agua conectados con unos tubitos peque nos)) y programar la
PS2 sera tener ((unos cuencos conectados por amplios canales)).
El dise no de la arquitectura de la PS2 se rige por unos puntos principales (que
podemos llamar restricciones) que establecio el equipo de desarrollo de Sony y que
debemos tener en cuenta a la hora de comprender correctamente la arquitecura [27].
Esta orinetada al entretenimiento domestico. Esto siginica que las especicacio-
nes de la maquina no pueden cambiar a lo largo de su vida y si cambian tiene que
ser de una forma tranparente al desarollador y al usuario. A efectos practicas esto
nos asegura que cualquier aplicacion que hagamos basada en el Emotion Engine
va a funcionar alla donde haya un EE. Esto nos ofrece un angulo de vision muy
interesante desde el putno de vista comercial y de la investigacion.
Potencia para sintetizar emociones. Los gracos 3D de alta calidad requieren ua
gran potencia de calculo. Ademas, los juegos de calidad no solamente tienen unos
buenos gracos, sino que tambien manejan una pesada logica y una simulacion
de fenomenos fsicos considerable en aras de conseguir realismo. La consola tiene
que dise narse para soortar estos calculos.
Rapido renderizado. Para conseguir un buen frame rate en juegos 3D se necesita,
entre otras cosas, poder realizar un renderizado rapido. La PS2 usa un sintetizador
graco (GS) con DRAM embebida lo que consigue que el ancho de bandea entre
la memoria y el procesador se expanda. De esta manera se consiguen eliminar
los cuellos de botella que se generaban al hacer el rellenado de pxeles en la
1.2. INTRODUCCI
renderizacion
3
Simultaneidad de calculos geometricos. La consola proveera al desarrollador de
la posibilidad de simultanear calculos geometricos.
Descompresion de datos bajo demanda. Una buena solucion para abaratar el
coste de la consola es usar memorias de baja capacidad y baja velocidad. Para
conseguir un buen ancho de banda con esta con esta memoria se pueden usar
dartos comprimidos y descomprimirlos con circuitos especializados en tiempo real.
Esto es ideal para texturas de alta resolucion.
Control de stall y memoria FIFO. Una enorme cantidad de datos intermedos
(display lists) se transeren constantemente desde el motor geometrico hasta
el motor de renderizado. Para controlar este ujo de datos sin imponer carga
al procesador se provee de un mecanismo de memoria FIFO. Este mecanismo
permite sincronizar las transferencas de datos desde el motor geometrico hasta
la memooria y desde la memoria hasta el motor de renderizado usando la memoria
como un buer.
Procesadores especcos. Los video juegos usan cadena de procesamiento comu-
nes comom el procesamiento de imagenes. Ademas, de la carga de los procesos
por s misma, el overehead debido a los cambios de contexto producen una pesada
carga para la CPU. Por esta razon se usaran subprocesadores a peque na escala
para ejecutar esas cadenas de procesamiento comunes para compartir tiempo de
procesamiento de la CPU.
Transferencia inteligente de datos. El procesamiento distribudo incrementando
el n umero de subprocesadores requiere mecanismos de sincronizacion y arbitraje.
Para no sobrecargar la CPU con estas, tareas todas las intrucciones (programas)
se transeren junto con los datos usando un controlador de DMA
4
.
Buer de camino de datos. En un sistema UMA (Unied Memory Arquitecture)
5
con varios subprocesadores las competiciones por accesos al bus crean cuellos
de botella. Por ello se a naden a cada subprocesador unos buers de peque na
capacidad (caches) donde se almacenan temporalmetne los resultados del pro-
cesamiento y desde all se hace, de una vez y colectivamente, la transferencia a
memoria usando DMA. De esta manera se centralizan los accesos al bus en el
DMAC
6
y la eciencia de las transmisiones se puede mejorar.
Si se quiere sintetizar emociones es necesario realizar una cantidad enorme de
calculos.

Estas altas prestaciones se cosiguen con un esmerado dise no que busca la
maxima paralelizacion de componentes. Principalmente, la arquitectura de la PlaySta-
tion 2, tal y como podemos ver en el esquema se compone de 4 partes, a saber:
De las partes que hemos podido ver en la Figura 1.5, la principal es el Emotion
Engine (EE). Ahora procedemos a describir los elementos destacados.
3
Que era el principal problema del renderizado en el a no 2000
4
mas adelante veremos que este es la piedra angular para sacarle partido al EE
5
arquitectura de memoria unicada
6
Direct Memoy Access Controler
10 CAP
ITULO 1. DEFINICI
Figura 1.5: Esquema de la disposicion de las unidades, junto a las entradas/salidas
Emotion Engine (EE)
Este es el verdadero corazon de la consola. Se trata de un procesador con varios
procesadores integrados e interconectados entre si por un bus de 128 bits de alta
velocidad. Este procesador controla la PS2 y es el que la dota de toda su fuerza. Por
su principal importancia lo trataremos en la siguiente seccion.
El Procesador de Entrada/Salida (IOP)
Para controlar todos los dispositivos de I/O (mandos, DVD, puertos USB...) y
liberar al EE de esta tarea, Sony opta por usar un procesador dedicado. Aprovechando
su bajo coste y dando un golpe de efecto comercial usa como procesador de I/O
el mismo procesador que gobernaba la PlayStation (PS)
7
. As Sony se asegura una
compatibilidad del 100 %, minimiza costes y hace a un mas atractiva al usuario nal
poseedor de una PS la PS2; ya que el usuario podra seguir usando los ttuos que
posea y puede comprar nuevos ttulos a bajo precio debido al salto de tecnologa.
Sony no se quedo ah y mejoro el procesador. El IOP contiene un procesador MIPS
r3000 de 32 bits [24] y tiene dos tareas distintas. De un lado ejecuta lso juegos de
la PS, de otro realiza el control y la lectura de todos los perifericos y puertos de la
consola. As, el DVD-ROM, el HD, el puerto USB, el puerto IEEE 1394 (Firewire) y
el bus PCMCIA son controlados por este procesador. As se facilita la conexion de la
consola a m ultiples perifericos presentes y futuros tales como teclados, ratones, camaras
digitales, impresoras, joysticks, etc. Con respecto al procesador original de la PS esta
version mejorada incorpora el IEEE 1394, una cache mejorada y una nueva arquitectura
DMA que permite un incremento de rendimiento de hasta 4 veces en la transferencia
de datos [2].
El IOP tiene una memoria SDRAM que se encuentra totalmente separada de los
32 MB que tiene de memoria principal el EE de una capacidad de 2 MB. Dependiendo
de su modo de ejecucion, PS o PS2, el IOP funciona a 33 o 36 MHz respectivamente,
7
La llamaremos PS y no como erroneamente se hace en otros artculos PSOne pues PSOne es una
version de la PS original con un nuevo aspecto externo y una nueva organizacion del PCB que diculta
la instalacion de chips. La consola sigue siendo la misma
1.2. INTRODUCCI
como se analiza en el artculo publicado sobre la posible aplicacion de la consola a nes
didacticos [53].
El Sintetizador Graco (Graphics Synthesizer, GS)
El GS es el procesador graco de la PS2 y se encarga de dibujar el mundo 3D por
pantala. Para ello traduce las display lists (listas de datos) que le enva el EE.
Es un procesador graco de muy alto rendimiento que consigue su potencialidad
rgacias a unso buses muy anchos con los que se consigue un gran ancho de banda, a
16 motores de pxeles que operan en paralelo y a una DRAM de 4 MB embebida en el
chip. En la Figura 1.6 mostramos un esquema general de la arquitectura del GS.
Figura 1.6: Arquitectura del sintetizador graco
Los motores de pxeles operan en paralelo a 150 MHz. Al contrario que en un
sistema de video tradicional con una memoria externa y unos accesos a memoria a traves
de un bus de sistema, el GS tiene la memoria embebida conectada directamente a los
motores de pxeles con un bus de 2560 bits con lo que se consiguen unas transferencas
12 CAP
ITULO 1. DEFINICI
de 48 GB/s lo que ayuda a mejorar las tareas de renderizado y da mejor rendimiento
que un sistema de video tradicional.
Cuando se transmite al frame buer se consigue un ancho de banda de 38.4 GB/s
(1024 bits x 150 MHz x 2) y cuando se transmite al texture buer se alcanza una veloci-
dad de 9.6 GB/s (512 bits x 150MHz). Como vemos en la gura hay una conguracion
de doble puerto para acceder simultaneamente a las dos zonas de memoria. Sin entrar,
por ahora, en mas detalles y despues de haber destacado los elementos distintivos de
la arquitectura del GS vamos a comentar a ttulo descriptivo las capacidades del GS.
Mas a delante, si procede, trataremos el GS en mas profundidad.
El GS procesa 16 pxeles (32 bit por pxel) por ciclo sin texturas y 8 pxeles
por ciclo con texturas. La tasa de escritura de pxeles maxima es de 2.4 Gpxeles/s
sin texturas y de 1.2 Gpxeles/s con texturas. La Tabla 1.1 muestra una tabla donde
podemos ver cuantos polgonos es capaz de procesar el GS en distintas condiciones de
funcionamiento.
Cuadro 1.1: Rendimiento del GS para las distintas primitivas y opciones disponibles
El GS contiene tambien un modulo encargado de su salida que es el PCRTC.
Este modulo puede generar la salida seg un el estandar VESA (hasta 135 MHz como
1.2. INTRODUCCI
maximo), NTSC o PAL.
Por ultimo a nadir que no todos los monitores pueden conectarse con la PS2. Solo
aquello que tenga la sincronizacion en verde. De todas formas Sony proporciona una
WEB [6] donde podemos encontrar un listado actualizado de monitores probados.
Una puntualizacion. En su dise no, la PS2 no esta hecha para conectarse a un
monitor de alta denicion; de ah que no se requiera excesivo espacio de almacenamiento
para texturas de alta denicion, ya que Sony considera que no tiene mucho sentido ver
texturas de alta denicion televisor con las limitaciones que este tiene.
El Procesador de Sonido (SP) [53]
El procesador de sonido esta formado por 2 DSPs conectados a 2 MB de memoria
integrada y es capaz de manejar hasta 48 canales simultaneamente a una frecuencia
de reloj de hasta 48 KHz, ademas de decodicar Dolby, AC3 y DTS.
1.2.4. El Emotion Engine (EE)
Introduccion
El Emotion Engine es el corazon de la Playstation2, se trata de una CPU RISC de
128-bits desarrollada por Sony y por Toshiba
8
. Esta basado en la arquitectura MIPS III
aunque implementa un subconjunto de instrucciones de la arquitectura MIPS-IV. La
CPU funciona con una velocidad de reloj de 294.912 MHz. Para el proceso masivo de
informacion multimedia a altas velocidades, tanto el bus de datos, como la memoria
cache y los registros son de 128-bits. El Emotion Engine ha sido la primera CPU
desarrollada completamente de 128-bits. La capacidad de calculo en punto otante
es muy superior a la de los ordenadores personales corrientes. La CPU incorpora dos
unidades de enteros (IU) de 64-bits, una unidad SIMD de 128 bits con 107 instrucciones
para el procesamiento multimedia, dos unidades independientes de calculo de vectores
en punto otante (VU0, VU1), un circuito decodicador de MPEG-2 y controladores
DMA de alto rendimiento. Son tres los componentes que pueden realizar operaciones
en punto otante en paralelo:
1. Coprocesador 1 FPU con 1 FMAC1 y 1 FDIV
2. Coprocesador 2 VU0 con 4 FMAC y 1 FDIV
3. Unidad de proceso vectorial con 5 FMAC y 2 FDIV
El rendimiento combinado de todos estos elementos permite calculos fsicos com-
plicados, y todo tipo de transformaciones geometricas 3D. Ademas de procesar los
datos a 128-bits, es posible procesar y transferir vol umenes masivos de datos multime-
dia. Los 32 MB de RAM de memoria principal que soportan la velocidad de la CPU
son Direct Rambus DRAM de dos canales para conseguir un ancho de banda de 3.2
GB/seg. Unas cuatro veces el rendimiento de las memorias PC-100 que se montaban en
los ultimos PCs cuando salio al mercado la PS2. Con la incorporacion del decodifcador
MPEG-2 en un chip, es posible procesar en paralelo datos gracos 3D de alta resolucion
y imagenes DVD de alta calidad. Con una capacidad de calculo en punto otante de 6.2
GFLOPS/seg, el rendimiento de esta CPU alcanza el de algunos supercomputadores.
Cuando se aplica al procesamiento de transformaciones de perspectiva y geometricas,
que son las que se usan normalmente para el calculo de gracos en 3D, el rendimiento
8
En el desarrollo de CELL, el procesador para la PlayStation3 participa tambien IBM
14 CAP
ITULO 1. DEFINICI
llega a 66 millones de polgonos por segundo, lo que es con el rendimiento de las es-
taciones gracas usadas en la produccion de pelculas de animacion contemporaneas a
la consola.
Sobre la implementacion [10]
El EE esta implementado con tecnologa CMOS de 0,25 micras con una longitud
de puerta de 0,18 micras. Es un dado de 15,02mm 15,04 mm con 13,5 millones de
transistores, funciona a unos 300 MHz y consume 18 watios. Podemos encontrar una
descripcion detallada de la metodologa de dise no seguida en [16] [20] [18] [17].
Estructura principal
El EE se compone de 3 procesadores independientes que pueden trabajar en para-
lelo. El principal es un procesador basado en la arquitectura MIPS-III y MIPS-IV de 64
bits, el r5900. Este procesador funciona junto a un coprocesador de punto otante al
que esta directamente conectado mediante un bus de 128 bits. Los otros dos procesa-
dores son dos unidades vectoriales denominadas VU0 y VU1. La idea de la arquitectura
es que la VU0 se use junto con el MIPS r5900 para simular el juego y los procesos fsicos
de este, en tanto que el VU1 se use para simular el mundo 3D. De ah la estructura de
interconexion que tienen los 3 procesadores. En la Figura 1.7 podemos ver la estructura
general del EE.
Figura 1.7: Estructura del EE, a nivel de unidades y buses entre las mismas
El EE Core esta formado por el MIPS r5900 y por la FPU. Su mision es la del
procesador principal, es decir, realiza el control del videojuego teniendo en cuenta las
entradas del usuario
9
. Es un procesador superescalar de 64 bits basado en la arquitectura
MIPS-III e incorpora instrucciones de la arquitectura MIPS-IV, ademas de un repertorio
9
Es el que ejecuta el n ucleo de Linux
1.2. INTRODUCCI
de instrucciones multimedia SIMD de 128 bits y que es capaz de emitir 2 instrucciones
por ciclo. El r5900 tiene dos unidades de enteros de 64 bits que pueden usarse de
forma combinada para operaciones multimedia, una unidad load/store de 128 bits y
una unidad de prediccion de saltos.
El r5900 puede usar como coprocesadores a la FPU (cop1) y a la VU0 (cop2) y
para ello existen instrucciones especcas. As, en los programas que se ejecurataran en
el procesador principal pueden ir mezcladas intrucciones para ejecutarse en el VU0, en
el FPU y en el r5900. La FPU contiene una unidad FDIV y otra FMAC (multiplicacion
y acumulacion) para realizar operaciones de 32 bits en coma otante.
Las unidades vectoriales son dos exactamente iguales salvo por el tama no de
sus memorias (que es mayor en el VU1) y por una unidad adiconal que incorpora el
VU1. Como la idea de la arquitectura es que la VU1 trabaje de forma independiente
(generando el mundo 3D) y en paralelo con el EECore y la VU0 (mientras generan la
simulacion del juego) su memoria es mayor que la de la VU0.
Las dos unidades vectoriales tiene una arquitectura SIMD-VLIW y permiten ope-
raciones con matrices 4x4 y correciones de perspectiva. Cada unidad vectorial contiene
4 unidades FMAC de un ciclo y una unidad FDIV de 7 ciclos. Ademas, la VU1 tiene un
modulo adicional para realizar operaciones elementales usadas comunmente en opera-
ciones con geometra 3D. Este modulo se denomina EFU(Elementary Function Unit).
La VU1 tiene adicionalmente otra FMAC y otra FDIV.
Dentro de cada VU se consigue paralelismo local dividiendo estas en dos unidades
funcionales que pueden operar independientemente y en paralelo, una mitad inferior y
otra superior.
En modulo INTC que vemos en la imagen es el interrupt controller, se encarga
de gestionar las interrupciones que lleguen al EECore para minimizar los cambios de
contexto. Mas adelante veremos que operaciones que en otros procesadores causaran
einterrupciones en las unidades vectoriales solo causan cambios de bits en los registros
de estados; sinedo responsabilidad del programador comprobar dihcos registros.
El modulo TIMER contiene 4 contadores de 16 bits que se usan con proposito
general para los programas.
Las se nales de reloj que rigen el sistema que son 150 MHz para los buses y 294.912
MHz para los procesadores del EE. El IOP, recordemos, trabaja a una frecuencia 37.5
MHz cuando es el procesador de entrada/salida del EE y a 33 MHz cuando trabaja
como si fuera una PlayStation. El GS trabaja a 147 MHz [7] [17].
El EE cuenta con un controlador de DMA (DMAC, DMA Controller) de 10 ca-
nales que se encarga de realizar todas las transferencias entre los distintos elementos,
descargando as al EECore de esta tarea. El DMAC puede realizar transferencias de
datos que se encuentran en zonas de memoria discontinuas. Estra caracterstica se de-
be principalmente a que la labor principal de EE es la producion de display lists que
seran interpretadas por el GS y estas no tienen por que estar siempre en posiciones
de memoria consecutivas. Para realizar estas transferencias el DMAC una una lista de
punteros enlazada.
El modulo IPU (Image Data Processor) implementa la descompresion por hardware
de imagenes 2D seg une l estandar MPEG2 o un subconjunto de el. Tambien realiza
VQ (Vector Quantization). El IPU decodica los macrobloques, pero la compensacion
d e movimiento la tinee que realizar el EE por software con ayuda de las instrucciones
mltimedia. Para una completa informacion a cerca del funcionamiento del estandar
MPEG se puede consultar [34].
El modulo SIF (Sub-Processor Interface) es una interfaz entre el EE y el IOP que
contiene una memoria FIFO bidireccional para intercambiar datos entre los procesadores
16 CAP
ITULO 1. DEFINICI
sin sobrecargar el bus.
El GIF (GS Interface) es la interfaz con el GS, recibe los datos de tres cami-
nos distintos posibles (PATH1:Entre el VU1 y el GIF, PATH2:Entre el VIF y el GIF,
PATH3:Entre memoria principal y el GIF) y arbitra la preferencia entre ellos. Ademas,
el GIF da el formato adecuado a los datos para que el GS los pueda interpretar ade-
cuadamente (GIFTag) y se los enva.
En el apendice ((El EE a fondo)) podemos encontrar informacion en profundidad
sobre el EE; as mismo, en el apendice ((Las VUs a fondo)) podemos hacer lo mismo
sobre las unidades vectoriales.
Arquitectura de memoria
Para conseguir una mayor eciencia en las transacciones de datos, cada procesador
cuenta con sus peque nas memorias internas. En la Figura 1.8 se muestra la arquitectura
de memoria de la PS2.
Figura 1.8: Esquema de memoria de la PlayStation2
La memoria principal del EE esta formada por 2 modulos de 16 MBs de memoria
RDRAM a 400 MHz que alcanza una velocidad de transferencia pico de 3.2 GB/s.
Todos los modulos del EE pueden acceder a esta memoria a rtaves de una arquitectura
UMA (Unied Memory Architecture). Teoricamente, el procesamiento multimedia de
se nales de audio y video de alta resolucion requiere un ancho de banda muy superior.
Este ancho de banda se consigue mediante el uso en cada procesador de peque nas
memorias dedicadas que se utilizan como buers para agilizar las transferencais de
datos entre los diferentes procesadores del EE.
Estas memorias son, como vemos en la Figura 1.9, una memoria interna muy
rapida y con unas propiedades especiales denominada Scratchpad RAM (SPR) de 16
KB en el r5900 y dos memorias caches de dos vas asociativas por conjuntos, una de
1.3. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 17
dats de 8 KB y otra de instrucciones de 16 KBs. La cache de datos cuenta con un
mecanismo de escreitura write back.
Figura 1.9: Arquitectura de las memorias de la PlayStation2
La VU0 puede acceder tambien a la SPR para compartir datos y cuenta ademas
con una cache de datos de 4 KB y otra de instrucciones de 4 KB.
El SP (Sound Processor) cuenta con una memoria embebida de 2 MB y el GS con
orta memoria embebida VRAM de 4 MB como vimos antes. El IOP posee tambien 2
MB de memoria independiente.
Los accesos a memoria se hacen a traves del DMAC. Existen tres modos de acesos
diferente. En los juegos, el proceso principal es la generacion de display lists y estas
se calculan con los datos que se acaban de leer de memoria, se envan al GS y no se
vuelven a utilizar. En este tipoo de aplicaciones multimedia donde el ujo de datos es
claramente unidireccional, el uso de caches disminue el rendimiento del sistema. Por
eso existe un modo de transferencia de memoria que salta la cache (UnCached Mode).
Esta tambien el modo de transferencia estandar usando la cache, lo que es ideal para
datos temporales. El ultimo mode que provee el EE es el denominado UCA (UnCached
Accelerated) que acelera la lectura de datos adyacentes mientras escribe asincrona-
mente interponiendo un buer de proposito especial denominado UCAB (UnCached
Accelerated Buer).
1.3. La consola de videojuegos PlayStation2
El 13 de Septiembre de 1999, Sony Computer Entertaiment anuncion el lanza-
miento de la nueva generacion de consolas sucesoras de la PlayStation, de la que por
aquellos entonces se haban vendido mas de 50 millones
10
. Se anunciaba que la consola
iba a mejorar innitamente a su predecesora.
Ken Kuratagi fue el principal desarrollador del motor de la consola y podemos
encontrar varios artculos suyos en la bibliografa.
Fueron muchos los rumores que salieron sobre la consola y su comercializacion. Se
llego incluso a decir que la importacion estaba congelada en China porque el porderoso
hardware de la consola poda tener aplicaciones belicas y comenzo a especularse con
posibles adquisiciones masivas de los gobiernos de consolas. Hubo tambien rumores a
cerca de discremancias enrte los ingenieros y la directiva de Sony sobre las potencia-
lidades de la consola de la que se hicieron eco varios periodicos. Todos estos rumores
10
Actualmente se han vendido mas de 73 millones de unidades
18 CAP
ITULO 1. DEFINICI
Figura 1.10: Imagen de una PlayStation2
claramente beneciaban a Sony pues la consola fue ganando cada vez mas en especta-
cion. Por n, el 4 de Mayo de 2000 la consola PlayStation2, que se puede en la Figura
1.10, salio a la venta en Japon. Solo la primera semana se vendieron mas de 1 mill on
de unidades. Haba continuos problemas de estocaje.
Para el resto del mundo la consola se hizo esperar y no fue hasta el a no 2001
cuando pudimos adquirirla en Espa na. Las caractersticas tecnicas de la consola son
impresionantes. Esta consola ha sido dise nada desde el pricipio con un claro objetivo:
Juegos 3D. Es por eso que todo el hardware esta orientado a que se puedan ejecutar
este tipo de juegos con las maximas prestaciones posibles. La PS2 es la evolucion de la
primera consola desarrollada por Sony, la Playstation (PSX). La PSX fue de las primeras
consolas cuyos juegos se distribuian en soporte CDROM. Uno de los golpes de efecto
comerciales mejor pensados de Sony es la compatibilidad absoluta de las dos consolas.
As, el consumidor puede reutilizar todos sus juegos de PSX en la PS2. Incluso algunos
juegos se mejoran ya que se hace un suaizado de polgonos. Los juegos de la PS2 se
distribuyen en DVD aunque tambien es capaz de reproducir los juegos de la PSX en
CDROM. Gracias a la gran capacidad de los DVDs, los juegos de la PS2 estan repletos
de videos, m usica y sonido en 3D. Ademas de juegos, la PS2 puede reproducir CDs de
audio y pelculas en DVD por tanto es una completa plataforma de entretenimiento.
El panel frontal contiene, ademas de la bandeja para los DVDs/CDs:
2 slots para las tarjetas de memoria que son de 8 MB normalmente, aunque el
formato es el mismo que las de la PSX por lo que se pueden intercambiar.
2 slots para los nuevos controles, aunque siguiendo con la poltica de compatibi-
lidad tambien funcionan los controles antiguos de la PSX.
2 puertos USB que pueden ser usados con cualquier dispositivo USB compatible
como teclados, ratones, impresoras, etc.
1 puerto Firewire de alta velocidad.
La parte trasera contiene conectores para la salida de television, para television
de alta defnicion y salidas de sonido surround, DTS y Dolby Digital 5.1.
Los mandos estandar, Dual Shock 2, tienen 15 botones; todos son analogicos,
excepto Analog, Start y Select.
El mando consta de:
4 botones ordenados como cursores direccionales (arriba-izquierda).
Botones Analog, Start y Select (medio)
4 botones de accion de distintos colores (arriba derecha)
11
4 botones de accion, L1 , L2 (frente-izquierda) y R1, R2 (frente-derecha)
2 joysticks analogicos con force-feedback
12
(arriba-izquierda y arriba-derecha)
1.3.1. Caractersticas
En la siguiente lista vamos a morstrar las caractersticas principales de la consola
dadas por el fabricante:
Dimensiones: 301 mm (altura) x 182 mm (anchura) x 78 mm (profundidad)
Peso: 2,4 kg
Formatos compatibles: CD-ROM / DVD-ROM PlayStation 2 CD-ROM PlaySta-
tion CD audio, video DVD, Dolby Digital (AC-3), DTS
Unidad Central de Procesamiento (CPU): Emotion Engine de 128 bits
Frecuencia de reloj del sistema: 294,912 Mhz Memoria principal: Direct RDRAM
Tama no de la memoria: 32 MB
Gracos: Graphics Synthesizer (Sintetizador graco) Frecuencia de reloj: 147,456
MHz VRAM cache integrada: 4 MB
Sonido: SPU2
N
o
de voces: 48 canales. Dos posibles frecuencias selecionables 44 y 48 KHz
Memoria de sonido: 2 MB
IOP: Procesador I/O
N ucleo CPU: PlayStation CPU mejorado
Frecuencia de reloj: 33,868 MHz o 36,864 MHz (seleccionable) Memoria IOP: 2
MB
Dispositivo de disco CD-ROM y DVD-ROM: Velocidad CD-ROM: 24x DVD-
ROM: 4x
Sintetizador de gracos: 147,456 MHz 75 millones de polgonos/s max.
Interfaces:
11
Con formas, muy importantes pues son el distintivo comercial de la consola
12
Tecnologa de retroalimentacion de joystck
20 CAP
ITULO 1. DEFINICI
Conector DIGITAL OUT (OPTICAL)
Conector para Bus Serie
Universal (USB) Conector para i.S400 i.LINK Puerto de mando (2)
Ranura de MEMORY CARD (2)
Conector AV MULTI OUT
Perifericos incluidos: Mando analogico DUALSHOCK2
1.3.2. Expansion y accesorios
Las posibilidades de expansion en s de la consola son limitadas pues esto ira en
contra de la poltica de dise no de mantener la compatibilidad. Las posibles mejoras
del reproductor de DVD que es lo que es mas susceptible de mejorar con el tiempo
se resuelven a base de nuevas versiones de la consola que actualizan el rmware o
bien cambian la disposicion de la PCB o introducen mnimos cambios que para nada
cambian ning un requerimiento. La salida de nuevas versiones de la consola dicultan
tambien el uso de modchips para las mismas.
Los modchip son unos chips que modican las funciones de la BIOS de la consola
y permiten principalmente ejecutar backups de los juegos originales y algunos repro-
ductores multimedia mejorados que permiten reproducir DivX y otros codecs similares.
La principal ampliacion que se le puede hacer a la consola es el kit de Linux. El
kit de Linux para PS2 [14] permite ejecutar una distribucion Linux en la PS2.
Figura 1.11: Imagen de los componentes del kit de linux
Esto convierte a la consola en un ordenador de sobremesa plenamente funcional.
El kit de Linux mostrado en la Figura 1.11 contiene:
un disco duro interno de 40 GB
un teclado usb
un raton usb
una tarjeta de red 10/100 Base-T
dos discos DVD
El primero contiene el entorno de ejecucion (RTE) y los manuales de la PS2 que
Sony suele incluir en el kit de desarrollo. El segundo disco contiene todo el software de
la distribucion que se puede instalar en el disco duro. La distrubucion es una modicion
de la RedHat
13
. El kernel de Linux contiene drivers que ocultan el hardware e impiden
el acceso directo a la IOP. Sony proporciona solo los binarios de estos drivers por lo
que existen limitaciones a la hora de programar la PS2 con este kit. Por ejemplo estos
drivers no proporcionan interfaz con el puerto Firewire, por lo que es imposible de
programar este puerto. El Kit viene con el compilador de GNU gcc, las xfree y muchas
otras utilidades. Por lo que tenemos un completo entorno de desarrollo. Aunque los
programas o juegos que se desarrollen sobre el kit de Linux solo podran ejecutarse en
una PS2 que tenga el kit. Nosotros hemos empleado el kit de linux en el desarrollo de
nuestro proyecto.
De todos los dispositivos que el Kit de Linux trae sellados y etiquetados por Sony,
el unico que no puede ser estandar por sus especiales caractersticas es la tarjeta de red.
Respecto al teclado y al raton valen cualesquiera con tal de que sean usb. Respecto
al HD, en principio (pese a las negativas de Sony) funciona cualquiera que sea ATA.
En la interfaz que tiene solo se puede colocar un disco duro. Estos conocimiento son
interesantes de cara a la construccion de un cluster de PS2 como el que existe en la
Universidad de Illinois en Urbana-Champaign, mostrado en la Figura ??. Es un cluster
de Computo cientco basado en PS2. Con el exploran el uso de PS2 en Computo
Cientco y Visualizacion de Alta Resolucion. El cluster lo constituyen 70 PS2
14
.
Lo demas son accesorios que la consola tiene y que tienen su utilidad para los
juegos [7]. Sony, ademas de los juegos, tambien ha hehco compatibles los perifericos de
la PlayStation con la PlayStation2. Pero tambien ha desarrollado perifericos exclusivos
para la nueva consola:
MANDO ANAL
OGICO DUALSHOCK2:
Sony Computer Entertainment ha desarrollado un nuevo
mando analogico DUALSHOCK, de aspecto exactamente
igual al del mando analogico DUALSHOCK original, pero
dotado con controles analogicos sensibles a la presion (ex-
cepto los botones ((START)) y ((SELECT))), para mejorar el
control de lo que ocurre en la pantalla y hacer la experiencia
de juego interactivo a un mas atractiva.
MEMORY CARD (TARJETA DE MEMORIA) [8MB] para PlayStation 2:
La nueva memory card (tarjeta de memoria) cuenta con una
capacidad de almacenamiento de datos de 8MB y con una
tasa de transferencia hasta 250 veces mas rapida que la me-
mory card (tarjeta de memoria) de PlayStation. Para mejorar
la seguridad de los datos en las posibles aplicaciones futuras
en red, la memory card (tarjeta de memoria) incorpora el
sistema de autenticacion y cifrado ((MagicGate)).
13
Hay otra distribucion llamada BlackRhino que esta basada en Debian
14
Sony Linux Kit + MPI, PBS, Maui Scheduler
22 CAP
ITULO 1. DEFINICI
MULTITAP:
Con el multitap, redise nado para PlayStation 2, los videojue-
gos siguen siendo una actividad social, con grupos de amigos
api nados delante del televisor intentando conseguir el gol mas
artstico, el partido perfecto, o, simplemente, buscando el pu-
ro disfrute de una experiencia compartida.
FANATEC SPEEDSTER 2:
El Speedster2 presenta una combinacion de volante y peda-
les compatible con la lista siempre creciente de ttulos para
PlayStation y PlayStation2 de juegos de conduccion, entre
otros Gran Turismo 3: A-spec, Ridge Racer V y Formula One
2001. El Speedster2 incluye todos los botones standard de
una PlayStation as como el sistema de vibracion que le pro-
porcionan dos motores duales integrados en el mismo volante.
BOLSA PLAYSTATION2:
La bolsa ocial de PlayStation2, facilita la movilidad y pro-
teccion de esta consola. Ademas de un amplio espacio para
la PlayStation2 y accesorios, cuenta con un compartimento
con capacidad para guardar 5 DVDs. Este accesorio puede
parecer una tontera pero es una muestra clara de la implica-
cion de Sony en sacar adelante su producto y de dar soporte
original hasta en el mas mnimo detalle.
PORTA CDS PLAYSTATION2:
Este estuche cuenta con espacio para guardar 12 CDs y un
bolsillo especial para la tarjeta de memoria. Resistente por
fuera y acolchado por dentro, este porta CDs ocial de Sony
resulta un accesorio casi indispensable para cualquier usuario
de PlayStation2. Podemos hacer el mismo comentario que
antes.
Pese a la dicultad para su programacion la PS2 salio al mercado con mas de 30
ttulos disponibles. Los principales desarrolladores de juegos han desarrollado y estan
desarrollando juegos para la PS2. Acclaim, Activision, Capcom, Crave, Eidos, Elec-
tronic Arts, From Software, Infogrames, Interplay, Kemco, Koei, Konami, LucasArts,
Microids, Midas, Midway, NAMCO, Squaresoft, Rage Games, Rockstar, SCI, Swing,
Take2, Tecmo, THQ, Titus Interactive, Ubisoft y Virgin Interactive, entre otros.
1.3.3. Comparativa
La Tabla 1.2 muestra algunas consolas disponibles en el mercado en el a no de
presentacion de la PS2 y las consolas mas recientes. Los datos proporcionados por Sony
y Microsoft no son realistas, son los datos maximos, mientras que los de Nintendo y
Sega estan medidos en un juego real.
1.3.4. Que le falta a la consola
La verdad es que nos encontramos ante una maquina impresionante que nos ofrece
unas capacidades asombrosas. Sin embargo, no todo es tan maravilloso. Este monstruo
es un coloso muy difcil de gobernar. Sony no provee de unas herramientas adecuadas
DC PS2 GAMECUBE XBOX
compa na SEGA SONY NINTENDO MICROSOFT
s. operativo Windows CE propio propio Windows
2000
procesador Hitachi SH4
Risc
Emotion En-
gine
Gekko IBM Pentium III
velocidad 200 Mhz. 300 Mhz. 405 Mhz. 733 Mhz.
procesador graco Power VR
100 Mhz.
Sony GS 150
Mhz.
ATI 200
Mhz.
V-25 300
Mhz.
polgonos por se-
gundo
3 millones 20 millones 20 millones 100 millones
resolucion maxi-
ma en pantalla
640x480 1280x1024 1280x1024 1920x1080
ancho de banda 0,8 gi-
gas/seg.
3,2 gi-
gas/seg.
3,2 gi-
gas/seg.
6,4 gi-
gas/seg.
memoria total 26 megas 38 megas 38 megas 64 megas
tarjeta de memo-
ria
2 megas 8 megas 8 megas 8 megas
canales de sonido 64 48 64 256
audio 3D disponi-
ble
NO NO S
I S
I
sonido AC3 dispo-
nible (DVD)
NO NO NO S
I
modem incorpora-
do
S
I / 33.6
Kbps
NO / 56
Kbps
NO / 56
Kbps cable-
modem
NO / 56
Kbps Ether-
net 100Mb
conexion en red NO NO NO S
I
almacenamiento GD-ROM
(1,2 gigas)
DVD 4x (4,7
gigas)
formato pro-
pio (1,5 gi-
gas)
DVD 5x (9,4
gigas)
puertos para man-
dos de control
4 2 4 4
DVD-video NO S
I NO S
I
disco duro NO S
I NO S
I (8gigas)
Cuadro 1.2: Principales caractersticas de la consola comparada con las que ofrecen sus
mas directas competidoras en el mercado.
24 CAP
ITULO 1. DEFINICI
de desarrollo y aventurarse en la empresa de programar un juego para PlayStation2,
ademas de ser una empresa intelectualmente muy costosa tambien lo es economica-
mente. Primero hay que inscribirse como desarrollardor ocial de Sony y rmar por los
ttulos que se vayan a publicar. Despues hay que comprar el kit de desarrollo que da
Sony que se denomina Sony Computer Entertainment Development Kit DTL-T10000,
como se muestra Figura 1.12. El coste por unidad es de aproximadamente 20 000
dolares americanos, lo que es un coste muy signicativo que lo hace prohibitivo para
usuarios particulares y peque nas e intrepidas empresas que quieran aventurarse en este
mundo, ademas, un solo kit de desarrollo se hace insuciente para un equipo serio y
completo de desarrollo de un juego.
Figura 1.12: PlayStation2 conectada al kit de desarrollo DTL-T10000.
El KIT contiene dos PS2 de desarrollo:
La PS2 TEST, es igual que una PS2 normal pero puede leer CD-R sin necesidad
de modchips.
La PS2 TOOL, es bastante mas grande que una PS2 normal debido al aumento
de los componentes con respecto a esta, entre las diferencias, destacan:
1. 128 MB de memoria principal
2. Disco duro
3. Tarjeta de red
Sony proporciona a los desarrolladores esta maquina de tal forma que compilan su
codigo y se ejecuta sobre el hardware de esta PS2. Sony solo proporciona el hardware y
las librerias,as como asesora y ejemplos. La escasa documentacion de la consola hace
que sea muy dicil programar esta. El paradigma de programacionde esta consola es
totalmetne diferente a programar un PC y se requieren unos desarrolladores con amplios
conocimientos de arquitecturas de computadores (y en particular de la aruiqtectuar de
la PS2) para ser capaz de sacar el rendimiento real de la consola. Una prueba clara de
ello es seg un los datos de los analisis de rendimiento ociales de Sony a fecha de 2003,
entre todos los juegos analizados todos anteriores a esa fecha, solo se haca un uso
del 2 % de la VU0 y solo el 56 % de la VU1.
Existen una serie de entornos de desarrollo comerciales pero estos suponen un
desembolso economico adicional y no necesariamente una mejora signicativa. Entre
ellos los dos mas conocidos:
1. ProDG de Snsys. Tienen diferentes modulos, incluido uno muy interesante llama-
do proview que permite mediante el uso del interfaz rewire conectar una PS2
modelo DTL-H Test Unit a un pc. Snsys proporciona con el proview los archivos
de una iso que corre en esta PS2 a modo de programa monitor permitiendo la
comunicacion con el software que corre en el PC. Con este sistema se consigue
porder compilar en el PC y ejecutar directamente en la PS2 sin necesidad de estar
continuamente generando CDs por cada prueba. Tambien tiene heramientas de
debug que redirigen la salida al pc para facilitar el desarrollo.
2. CodeWarrior de Metrowerks. Al igual que Snsys nos proporciona un entorno de
desarrollo completo con multitud de herramientas.
Hace poco ha salido un compilador denominado VectorEE de Codeplay [3] que
aparenta ser la mejor herramienta de desarrollo ya que permite compilar directamente
codigo C y promete paralelizar el solo el codigo en las distintas unidades vectoriales del
EE. No tenemos datos sobre sus resultados.
Para adquirir cualquiera de estas plataformas de desarrollo propietarias hay que
ser desarrollador ocal de Sony.
Otro gran inconveniente de desarrollar para esta consola es que una vez que ten-
gamos desarrollado el software nos lo tiene que grabar Sony por los especiales sistemas
anticopia que posee la consola, con los gastos adicionales que ello conlleva. Todos los
discos los graba Sony en una fabrica en Salzburg, Austria. Prometen que no existen las
listas de espera para grabar las copias.
La Figura 1.13 muestra el interior de la fabrica situada Nagasaki, en la que se
puede ver la fabricacion del Emotion Engine y del Sintetizador Graco.
Figura 1.13: Planta de fabricacion de Sony en Nagasaki.
1.3.5. Algunos comentarios sobre la PlayStation2
((PlayStation 2 esta trazando una ruta hacia el futuro del entretenimien-
to digital en red. Al igual que PlayStation puso los videojuegos al alcance
26 CAP
ITULO 1. DEFINICI
de un mercado de masas sin precedentes, la combinacion de impresionantes
gracos digitales, magnco sonido y vdeo DVD de PlayStation 2, abrira las
puertas a una nueva forma de entretenimiento en el hogar)).
Ken Kutaragi,
presidente y director ejecutivo de SCE Inc.
((Yo me quede tan impresionado como vosotros. En cuanto la vi (la con-
sola PlayStation 2), pense: esto va rapidsimo! No puedo seguir este ritmo,
es alucinante. Lo que han logrado con PlayStation 2 se sit ua sencillamente
mas alla de toda posibilidad de comprension)).
((Acababa de terminar esta pelcula (La guerra de las galaxias Episo-
dio I: La amenaza fantasma) que es, bueno, tecnologicamente de lo mas
avanzado Y en eso estabamos, sintiendonos extremadamente satisfechos de
nosotros mismos, cuando pusieron este juguetito en la mesa, y resulto ser
todava mas potente que lo que habamos hecho. Lo que a nosotros nos
costo a nos alcanzar, estara dentro de un a no a disposicion de todo el mun-
do. Es impresionante)).
George Lucas,
director y guionista de cine
((Creo que, cuando se combine la potencia deI hardware de PS2 con
la de la imaginacion y de la narracion, el resultado nal sera fantastico, y
superara nuestras mas descabelladas fantasas)).
Phil Harrison,
vicepresidente de SCE America
((Los gracos en tiempo real de PlayStation 2 no tienen limitaciones.
Por eso eleg el color negro, porque representa la innidad del universo. El
azul representa inteligencia y vida)).
Teeiyu Goto,
legendario dise nador de PlayStation 2
((La herramienta necesaria para descubrir las nuevas, innitas y emoti-
vas experiencias que PlayStation 2 nos reserva es la imaginacion. No hay
metodo correcto ni erroneo. No hay resultado predecible. Cada viaje es
activo y unico, y depende solo de la imaginacion del usuario)).
David Patton,
director de marketing europeo de SCE Europe
((PlayStation 2 esta lista para revolucionar el sector del entretenimiento
de la misma manera que PlayStation revoluciono el sector de los juegos.
Namco considera que PlayStation 2 es la plataforma mas viable para la
explotacion de sus capacidades de desarrollo de software; Ridge Racer V y
Tekken Tag Tournament estaran disponibles en el da del lanzamiento, y
hay otros apasionantes proyectos en curso)).
Yashuhiko Asada,
director general de Namco
1.3.6. Curiosidades
Una prueba mas de que la consola PS2 esta en auge pese a sus ya 4 a nos de
mercado es que ha entrado tambien en ella la ebre del modding. Esto signica que
existe toda una comunidad interesada en realizarle mejoras. Podemos encontrar mas
informacion sobre esto en [9]. La Figura 1.14 muestra los lmites de la imaginacion por
parte de los usuarios de Sony, que no temen destrozar la consola para variar el dise no
original.
Figura 1.14: Resultado de un modding por parte de un usuario de PlayStation2.
28 CAP
ITULO 1. DEFINICI
Captulo 2
Estudio del hardware: el
Emotion Engine
En este captulo realizaremos un estudio a fondo del centro de procesamiento
principal de la consola: el Emotion Engine, centro neuralgico de la potencia de com-
putacion de la que se ha dotado. Veremos los aspectos mas relevantes de las unidades
que conforman este n ucleo computacional.
2.1. Apendice. El EE a fondo
2.1.1. Introduccion
El Emotion Engine esta dise nado para hacer funcionar a la perfeccion juegos 3D.
Para ello, en vez de empe narse los ingenieros en mejorar estructuras de procesadores
de proposito general decidieron hacer un procesador especco para lograr mejor ren-
dimiento. La principal carga de procesamiento de un juego 3D es el renderizado de
las imagenes. En la Figura 2.1 veremos el esquema normal del cauce de renderizado y
como la estrcutura de la consola se adapta perfectamente a este cauce:
Figura 2.1: Cauce de renderizado y asociacion a una unidad funcional de la consola
Este cauce marca la arquitectura de la consola y explica la topologa de los buses.
El cauce de renderizado es un cauce de datos multimedia en una unica direccion y
que se puede realizar concurrentemente con la arquitectura de la PS2. La PS2 es una
29
30 CAP
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

arquitectura especializada para juegos 3D, igual que el TriMedia de Philips lo es para la
descompresion de video o el Audigy 2 de Creative lo es para el tratamiento del audio.
Como hemos visto en la gura anterior el principal elemento de procesamiento
del cauce es el EE. El EE se compone de 3 procesadores independientes que pueden
trabajar en paralelo. El principal es un procesador basado en la arquitectura MIPS-III
y MIPS-IV de 64 bits, el r5900. Este procesador funciona junto a un copocesador de
punto otante al que esta directamente conectado mediante un bus de 128 bits. Los
otros dos procesadores son dos unidades vectoriales denominadas VU0 y VU1. La idea
de la arquitectura es que la VU0 se use junto con el MIPS r5900 para simular el juego
y los procesos fsicos de este, en tanto que el VU1 se use para simular el mundo 3D.
De ah la estructura de interconexion que tienen los 3 procesadores. Podemos ver en
la Figura 2.2 esta interconexion y distribucion.
Figura 2.2: Reparto de las tareas mas habituales entre el hardware de la consola.
Estas son las partes principales de las que se compone el EE. Las describiremos
en detalle a continuacion. Antes veamos la Figura 2.3 que representa un esquema que
trata mas en profundidad el procesador Emotion Engine, sobre el que explicaremos sus
particularidades.
2.1.2. Mapa de memoria
Ademas de su estructura, lo primero que tenemos que tener claro a la hora de
programar con exito el EE es su mapa de memoria. Lo podemos ver en la Figura 2.4.
En la Seccion 2.2 del manual de usuario del Emotion Engine[28] podemos encontrar
cual es la direccion especca de los registros.
2.1.3. El EE Core
El EE Core es la denominacion que recibe conjuntamente el MIPS r5900 junto
a sus coprocesadores. Los posibles coprocesadores que puede utilizar el MIPS son el
FPU (y se denomina COP1) y la VU0 (y se denomina COP2). Se proveen instruciones
especcas para acceder a los dos procesadores e incluso hay una memoria (SPR) que
se comparte entre el MIPS y la VU0. Para que la unidad vectorial se pueda usar como
coprocesador tiene que estar funcionando en modo micro. Ya veremos los modos
2.1. APENDICE. EL EE A FONDO 31
Figura 2.3: Estructura interna del Emotion Engine
Figura 2.4: Mapa de memoria del Emotion Engine
32 CAP

de funcionamiento de las unidades vectoriales en el apartado dedicado a ellas. Por las
especiales caractersticas de las VUs nosotros denominaremos EECore solo al conjunto
formado por el MIPS (junto con sus memoras locales y caches) y el FPU.
El EECore es un procesador superescalar de dos cauces que implementa la arquitec-
tura de instrucciones de 64 bits MIPS-III y parcialmente la de MIPS-IV (instrucciones
de precaptacion y de movimiento condicional), ademas se le han a nadido 107 instru-
ciones SIMD de 128 bits para el procesamiento multimedia paralelo[26]. El EECore
cuenta tambien con una batera de instrucciones propias de su especial arquitectura
que sobre todo aprovechan el paralelismo de los cauces y que podemos consultar en
[25]. Citemos, por ejemplo, la multiplicacion de tres operandos.
Dentro del esquema que hemos visto anteriormente el EECore se compone del
MIPS r5900 junto con sus caches, los 16 KBs de memoria Scratchpad RAM (SPR) y
la FPU. Tiene 16 KB de cache de instrucciones (I$) y 8 KB de cache de datos (D$),
ademas cuenta con 32 registros de proposito general de 128 bits. Tiene 32 bits para
su espacio de direcciones, tanto fsicas como logicas. En su unidad de gestion de me-
moria (MMU) implementa una TLB (Translation Look-Aside Buer) completamente
asociativa de 48 entradas (96 paginas). El micro soporta instrucciones de carga no
bloqueantes. En general, podemos aplicar al r5900 cualquier documentacion sobre la
arquitectura MIPS-III salvo por las instrucciones especcas para acceder a los copro-
cesadores, la multiplicacion de tres operandos que soporta, la extension de todos los
registros de 64 bits a 128 bits y el uso del registro r31 reservado para instrucciones de
salto. La estructura del EECore se muestra en la Figura 2.5.
PC Unit
El PC Unit es el contador de programa (Program Counter). Es un PC de 32 bits
y mantiene la direccion de la instruccion que se este ejecutando. Esta unidad tambien
contiene una cache de 64 entradas denominada Branch Target Address Cache (BTAC,
Cache de direcciones destino de saltos ) que se usa para la prediccion de saltos.
MMU, Memory Management Unit (Unidad de Control de Memoria)
Como ya dijimos antes implementa una TLB (Translation Look-Aside Buer) com-
pletamente asociativa de 48 entradas (96 paginas). Implementa tablas separadas para
datos y para instrucciones. Usa 32 bits para direccionar direcciones fsicas, lo que co-
rresponde a un espacio de direcciones de 4 GB y 32 bits para direccionar direcciones
logicas o virtuales. Las direcciones virtuales estan formadas por un n umero de pagina
(VPN, Virtual Page Number) y un desplazamiento (oset). Los tres bits mas signi-
cativos del VPN identican el modo de operacion, esto es, el taama no de la pagina,
que puede ser 4 KB, 16 KB, 64 KB, 256 KB, 1 MB, 4 MB y 16 MB. El EECore tiene
los tres modos de operacion estandar de un procesador MIPS [24]: Usuario (User, User
program), Supervisor (OS) y Kernel. En modo Usuario se pueden direccionar hasta
2GB por proceso de usuario.
Caches y Scratchpad RAM (SPR)
Implementa una cache de datos de 8 KB y una cache de instrucciones de 16 KB.
Ademas de los 16 KB de SPR para manipular muy rapidamente grnades estructuras
de datos y de un buer para las transmisiones de datos contiguos rapidamente sin usar
cache: UCAB (UnCached Accelerated Buer).
Figura 2.5: Estructura interna del EECore
34 CAP

Las caches son de dos vas completamente asociativas y tienen una longitud de
lnea de 64 bytes, implentan una poltica Write-back y permiten el bloqueo de lneas
de cache y lecturas no bloqueantes. Se tienen que usar las instrucciones de cache para
mantener la coherencia. Las caches se organizan seg un la Tabla 2.1.
Cache Tama no Organizacion
Datos 8 KB 64 bytes 64 entradas 2 vas
Instrucciones 16 KB 64 bytes 128 entradas 2 vas
Cuadro 2.1: Organizacion de la memoria cache.
En la Figura 2.6 vemos la organizacion de la cache de datos y la organizacion
de la cache de instrucciones, respectivamente. Podemos consultar exhaustivamente la
disposicion de las caches en [26]:
Figura 2.6: Organizacion de la cache de datos y la cache de instrucciones.
Todas las lecturas que se hacen de memoria se hacen de cache. Solo se lee de
memoria principal cuando se usan isntrucciones para transparas la cache, cuando no
esta la lnea de cache que se necesita o cuando esta es invalida.
Algunas aplicaciones requieren una memoria embebida de alta velocidad que se
pueda acceder con lecturas/escrituras convencionales para manejar ecientemente es-
tructuras de datos (sobre todo si estas son grnades y complejas). Para conseguir suplir
estas necesidades los ingenieros de Sony dotaron al EE de la Scratchpad RAM (SPRAM
o SPR) de 16 KB. Tanto la CPU como el DMAC pueden acceder a la SPR, pero el
DMAC tiene prioridad.
La SPR es como una cache de datos sin etiquetas. Esta congurada como 1024
x 128 bits. Usa el mismo camino de datos que la cache de datos, lo que signica que
en ciclo determinado de CPU la CPU puede acceder bien a la SPR, bien a la cache de
datos, no a las dos simultaneamente. La SPR esta mapeada en el espacio de direcciones
virtuales. Lo vimos en la seccion de Mapa de Memoria un poco mas arriba o lo podemos
consultar en [26].
Tanto como para leer datos desde la SPR como para escribirlos, se provee de un
protocolo especial de DMA (ademas de las instrucciones de lectura/carga). El espacio
de pagina de ls SPR es de 16 KB. Los 14 bits menos signicativos de la direccion virtual
se usan para indicar la direccion en la SPR, en tanto que los 18 bits mas signicativos
se usan para acceder a la TLB y determinar si un bloque de 16 KB esta mapeado en la
SPR o no. Para direrenciar entre los espacios de memoria (puede estar en la cache de
datos o en la SPR) se usa el bit S las entradas de la TLB.
Para hacer una escritura de DMA a la SPR, se enva una se nal especial a la CPU
de escritura en la SPR con una direccion de SPR de 10 bits. Los datos se colocan el
el CPU BUS. Despues la CPU muestrea los datos del bus y los escribe en la direccion
indizada de la SPR.
Para hacer una lectura desde la SPR, es el DMAC el que se encarga de leer los
datos del SPR y pasarlos a memoria. De esta manera, la CPU puede realizar escrituras
en la SPR de resultados de programas que esta ejecutando mientras concurrentemente,
el DMAC va pasando estos datos a memoria principal. As se consigue un rendimiento
muy alto. La Figura 2.7 muestra la arquitectura de la SPR y la planicacion por parte
de la CPU.
Figura 2.7: (a) La conexion de la SPR con la CPU y con la memoria externa a traves
de DMA, (b) la CPU y la memoria accediendo concurrentemente al SPR para grabar
y leer datos respectivamente.
El UCAB (UnCached Accelerated Buer) es una peque na cache de solo lectura
que se usa en las transacciones de datos que se saltan la cache y que sirve para
optimizar las transmisiones y reducir el traco del bus. Acelera las transmisiones de
datos desde direcciones contiguas de memoria. Su disposicion se muestra en la Figura
2.8, comparada con otros tipos de transferencia.
Issue logic
Esta unidad se encarga de colocar un maximo de dos intruciones por ciclo en cada
cauce fsico que le corresponda.
36 CAP

Figura 2.8: Disposicion de distintos tipos de transmision a memoria.
Registros de la CPU
Los registros del EECore amplian el conjunto general de registros que dene la
arquitectura MIPS [24]. Cuenta con los siguientes registros:
32 registros de 128 bits registros de proposito general (GPRs, General Purpose
Registers)
1
.
4 registros que almacenan los resultados de las multiplicaciones y dividisiones de
enteros (HI0, LO0,HI1, LO1).
Un registro SA (Shift amount). Es un registro que se usa para especicar la
cantidad de desplazamietno en las instrucciones de desplazamiento. Es de 32 bits
y para acceder a el se han tenido que denir nuevas instrucciones.
El Contador de Programa (PC).
Notar que los 64 bits mas signicativos de los GRPs solo se usan con las instruc-
ciones especcas del EECore (lectura/carga de qword e instrucciones multimedia). Los
registros LO y HI tambien se han ampliado a 128 bits. Los 64 bits menos signicativos
de estos registros (HI0/LO0) se corresponden exactamente con sus homologos de 64
bits HI y LO. Los 64 bits mas signicativos (HI1/LO1) solo se usan para las nuevas
instrucciones de multiplicacion y division. Estas instrucciones son MULT1, MULTU1,
DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1, MTLO1.
Los registros de proposito general r0 y r31 son especiales.
El r0 esta siempre puesto por hardware a valor cero. Cuando se necesita un cero
en una operacion se puede usar este registro. Tambien se puede usar se realiza
una operacion de la que no se necesita el resultado.
El r31 se usa en las instrucciones de salto y no se debe usar.
Los registros HI0, HI1, LO0 y LO1 se pueden usar separadamente. Almacenan los
resultados de la multiplicacion entera, de la multiplicacion y acumulacion entera y de
la division entera. Cuando se realiza esta ultima, el cociente y el resto se almacenan en
LO0 and LO1, y HI0 y HI1, respectivamente.
1
Los registros en la arquitectura MIPS-III son de 64 bits
El registro SA especica la cantidad de desplazamiento cuando se usa la instruccion
QFSRV. El registro es especco del EECore y se necesita salvar como parte del contexto
del procesador si procediera. Existe una instruccion especca que se ha creado para
cargar intercambiar datos entre el SA y los GPRs.
El contador de programa (PC) mantiene la direccion de la instruccion que se
esta ejecutando. El PC se incrementa automaticamente en pasos de 4 cuando ins
instruccion se ejecuta. Cuadno se produce un salto el PC se actualiza a la nueva
direccion destino. Cuando ocurre una excepcion se cambia el valor del PC a la direccion
del vector que maneje las excepciones.
Cauces fsicos
Los cauces fsicos ejecutan las operaciones de las intrucciones. El EECore tiene 6
cauces fsicos que describiremos a continuacion:
1. Cauces I0 y I1. Son los cauces que contienen la logica para soportar la aritmetica
entera. Ambos dse componen de una ALU completa de 64 bits, un registro
de desplazamiento y una unidad MAC. El cauce I0 contiene el registro SA y
el cauce I1 contiene uan unidad LZC (Leading zero counting). Los dos cauces
comparten un registro de 128 bits de desplazamiento multimedia. Se conguran
ambos cauces dinamicamente para ser un unico cauce de 128 bits y ejecurar
operaciones de 128 bits.
2. Cauce LS. El cauce LS (Load/Store Pipe) contiene la logica para soportar las
instrucciones Load y Store.
3. Cauce BR. El cauce BR (Branch Pipe) contiene la logica para ejecutar instruc-
ciones de salto.
4. Cauce C1. El cauce C1 contiene la logica para soportar el coprocesador de punto
otante FPU (COP1).
5. Cauce C2. l cauce C1 contiene la logica para soportar el coprocesador vectorial
VU0.
Logica de bypass
La logica de bypass es una unidad que toma los datos de los GPRs y del Bus de
Resultados y los enva a los cauces y a la SPR.
Buer de WriteBack (WBB)
El buer de WriteBack es una memoria FIFO de 8 entradas de 16 bytes cada una
(1 qword) que sirve para acceder al BUS de la CPU. De esta manera se incrementa el
rendimiento desacoplando la CPU de las latencias del bus.
Unidad de interfaz del BUS (BIU, Bus Interface Unit)
El BIU conecta el EECore con el resto del sistema. Acopla las se nales del bus
interno del core al bus de la CPU.
38 CAP

La Unidad de punto otante (FPU, Floating-Point Unit)
La unidad de punto otante es un coprocesador fuertememte acoplado al MIPS
del EECore. Soperta el formato de precision simple denido en el estandar IEEE 754.
No soporta NaNs ni innitos. Soporta operaciones con el 0. No hay un mecanismos
de excepciones hardware que afecte a las instruciones y es compatible con el COP2
(VU0).
Tiene 32 registros de proposito general (FPRs) de 32 bits a los que puede acceder
la CPU meidante instrucciones especcas. Hay 32 registros de control de punto otante
de los cuales solo dos estan implenetados. Ademas hay un registro adicional de 32 bits
que se usa en las operaciones de multiplicacion-acumulacion. Estan estructurados como
muestra la Figura 2.9.
Figura 2.9: Registros que conforman la Unidad de Punto Flotante
La FPU solo soporta redondeos a cero. No sopora ning un otro tipo de redondeo
denidos en el estandar IEEE 754.
El cauce de la FPU consta de 8 etapas, como antes, cada una con dos fases.
Las instrucciones del COP1 se ejecutan simultaneamente en el cauce de enteros I0 y
en el cauce del COP1. La Tabla 2.2 muestra cada una de estas etapas. En la Figura
2.10, en la etapa donde se muestre una barra(/) lo que hay a la izquierda de esta se
ejecuta en cauce I0 y, lo que hay a la derecha, en el cauce del COP1. Las operaciones
que se relizan en cada etapa concretamente las podemos consultar en el manual [26]
proporcionado por Sony.
Figura 2.10: Cauce de la Unidad de Punto Flotante
Smbolo Etapa Fase
1I Captacion de instruccion Fase 1
1Q Decodicacion de instruccion Fase 1
1R Captacion de los registros Fase 1
1T Captacion de los registros en COP1 Fase 1
2T Captacion de los registros en COP1 Fase 2
X Ejecucion 1
Y Aritmetica/ALU1
Z Aritmetica/ALU2
1S Escritura de resultados Fase 1
2S Escritura de resultados Fase 2
Cuadro 2.2: Signicado de las siglas de las etapas del cauce de la FPU.
Cauce de las operaciones superescalares
El EECore tiene u cauce superescalar segmentado en 6 etapas. Puede captar,
decodicar y ejecutar un maximo de dos instrucciones en paralelo cada ciclo.
El EECore tiene 4 cuaces distintos de enteros: los cauces I0 y I1, y los cauces LS
y BR. Cada cauce tiene las siguientes 6 etapas cada una con dos fases, enumeradas en
la Tabla 2.3 y mostradas en la Figura 2.11.
Smbolo Etapa Fase
1A Ejecucion Fase 1
2A Ejecucion Fase 2
1D Captacion de los datos Fase 1
2D Captacion de los datos Fase 2
1W Escritura Fase 1
2W Escritura Fase 2
Cuadro 2.3: Signicado de las siglas de las etapas de los cauces del EECore.
Figura 2.11: Etapas de los cauces del EECore.
Las operaciones que se relizan en cada etapa concretamente las podemos consultar
40 CAP

en el manual del Emotion Engine [26]. Este procesador es muy didactico y puede usarse
como ejemplo para la docencia de la asignatura ((arquitectura de computadores)).
2.1.4. El Controlador de interrupciones (Interrupt Controller, INTC)
El modulo INTC es el controlador de interupciones que gestiona las interrupciones
de los procesadores y de los otros elementos del EE salvo las del DMAC. Cuando un
dispositivo (que no sea el DMAC) produce una interrupcion, el INTC la gestiona y
enva al EECore la se nal de interrupcion INT0. Si es el DMAC el que la produce, el
mismo enva otra se nal distinta INT1 al EECore. El INTC controla quince posibles
interrupciones que se resumen en la Tabla 2.4:
ID NOMBRE CAUSA
0 INT GS Deteccion deuna interrupcion en el GS
1 INT SBUS Deteccion de una interrupcion en un periferico del
SBUS
2 INT VB ON Comienzo del V-Blank
3 INT VB OFF Final del V-Blank
4 INT VIF0 Deteccion de un VIFCode en el VIF0 con el bit de
interrupcion activado o una excepcion en el VIF0
que activa una interrupcion (stall)
5 INT VIF1 Deteccion de un VIFCode en el VIF1 con el bit de
interrupcion activado o una excepcion en el VIF1
que activa una interrupcion (stall)
6 INT VU0 Ejecucion de una micro instruccion en la VU0 con
el bit de interrupcion activado o la ocurrencia de
una interrupcion en la VU0 (stall)
7 INT VU1 Ejecucion de una micro instruccion en la VU1 con
el bit de interrupcion activado o la ocurrencia de
una interrupcion en la VU1 (stall)
8 INT IPU Deteccion en el IPU del nal de los datos o una
excepcion
9 INT TIMER0 Condicioon de interrupcion del contador 0
13 INT SFIFO Deteccion de error durante una transferencia SFIFO
14 INT VU0WD Interrucpcion que se produce cuando la VU0 lleva
en el estado RUN mucho tiempo (ForceBreak)
Cuadro 2.4: Interrupciones que es capaz de controlar el modulo INTC.
Para mas informacion, consultar el Manual de Usuario [28] proporcionado por Sony
junto al kit de linux.
2.1.5. TIMER
El modulo TIMER es un modulo que implementa cuatro contadores independientes
de 16 bits cada uno. Se pueden inicializar y producen interrupciones cuando alcanzan
el valor de referencia o cunado producen overow. Hay un ag en el registro de estado
que indica cual ha sido la causa que ha producido la interrupcion. Los contadores se
pueden sincronizar con 1/16 de BUSCLK, 1/256 BUSCLK y con las se nales externas
H-BLNK/V-BLNK para sincronizarlos con la imagen de la pantalla.
Adicionalmente, tanto el Timer 0 como el 1 tienen un registro donde almacenar
el valor de la cuenta cuando se produce una interrupcion SBUS.
2.1.6. El controlador de DMA (DMA Controller, DMAC)
El controlador de DMA se encarga de transferir inteligentemente los datos entre la
memoria principal y los procesadores y entre la memoria principal y la scratchpad RAM
(SPR) realizando un mejor aprovechamiento del bus principal y liberando al EECore
de esta tarea. La unidad mnima que se transere es la cuaddruplepalabra (qword, 128
bits). Las transferencia con el DMAC se especican en base a sus direcciones fsicas y
no se hace traduccion alguna con la TLB.
Las transferencias desde y hacia un periferico se realizan en paquetes de 8-qwords
denominadas slices. Hasta que la transferencia de un slice no se completa el canal que
esta usando la transferencia permanece ocupado y monopoliza los derechos del bus.
Como hay mas de un bus se permiten transferencias concurrentes por los distintos
buses, ademas, es to no impide que la CPU acceda a memoria principal. Existe la
funcion de control de stall que permite sincronizar las transferencias desde y hacia
memoria principal. Hay 10 canales de DMA, mostrados en la Tabla 2.5.
ID Canal Sentido Prioridad
0 VIF0 hacia A
1 VIF1 desde/hacia C
2 GIF hacia C
3 fromIPU desde C
4 toIPU hacia C
5 SIF0 desde C
6 SIF1 hacia C
7 SIF2 desde/hacia B
8 fromSPR desde C
9 toSPR desde C
Cuadro 2.5: Disponemos de diez canales DMA para realizar transferencias.
La prioridad es A > B > C. El SBUS tiene tres canales (ID = 5, 6, 7) y mejora
las tranferencias DMA cooperando con el correspondiente DMA del SBUS. Los canales
que tiene como destino la memoria (excluyendo fromSPR) pueden seleccionar como
destino bien al memoria, bien la SPR. Los canales que tiene como origen la memoria
(excluyendo toSPR) pueden seleccionar como origen bien al memoria, bien la SPR.
Los datos que se transeren tiene que estar alineados a fronteras de 128 bits. Hay dos
modos de transferencia por los canales del DMA:
1. Modo de transferencia fsico (Physical Transfer Mode) que es jo para cada canal.
2. Modo de transferencia logico (Logical Transfer Mode) que es seleccionable en
cada canal.
Dentro de cada modo hay distintas categoras. Las vamos a enumerar y a describir
brevemente.
Modo de transferencia fsico (Physical Transfer Mode). Se divide en dos tipos:
1. Modo rafaga (Burst Mode). Es este modo los datos se traneren en grupos.
2. Modo Slice (Slice Mode). En este modo los datos se transeren en paquetes
de 8 qwords en conjuncion con otros canales de DMA.
42 CAP

Modo de transferencia logico (Logical Transfer Mode). Se pueden seleccionar tres
modos:
1. Modo Normal (Normal Mode). Este modo lee datos continuamente de la
memoria principal o de la SPR y los transere a un periferico o viceversa. Es
una transferenca DMA normal. Transere desde una direccion de origen a
una destino tantos bytes consecutivos como se indiquen. Las transferencias
se dividen en slices (8 qwords) si esta seleccionado el Slide Mode o de una
sola vez si esta seleccionado el Burst Mode.
2. Modo Cadena (Chain Mode). En este modo se transere desde posiciones de
memoria no contiguas. Cada bloque que se transere contiene informacion
a cerca de la direccion del siguiente bloque a transferir en una estructura
denominada DMATag. El DMAC realiza los cambios de direccion de los
bloques a transferir sin ayuda del EECore. Si el modo es Slice Mode los
bloques se trocean en Slices y posteriormente se transmiten. Si el modo es
Burst Mode cada bloque se transmite seguido.
3. Modo Entrelazado (Interleave Mode). En este modo se transenren datos
entre la SPR y la memoria principal. Es un modo especial de transferencia
en el que se puede transferir un rectangulo dentro de una region de me-
moria bidimensional (una imagen) y transferirla a la SPR (y viceversa). Su
funcionamiento queda ilustrado en la Figura 2.12.
Figura 2.12: Ejemplo de transferencia de una region rectangular de entre la memoria
principal y la SPR.
Para transferir datos desde la SPR al GIF o al VIF1, se puede usar como memoria
FIFO para agilizar las transferencias un buer circular que hay implementado en me-
moria principal en conjuncion con los DMATag correspondientes. Este buer circular
se llama MFIFO (MemoryFIFO).
Cuando hay mas de una peticion simultanea de DMA, las peticiones se ordenan
seg un la prioridad siguiente de los canales:
V IF0 > SIF2 > V IF1 > GIF > fromIPU >
toIPU > SIF0 > SIF1 > fromSPR > toSPR
El controlador de DMA puede producir interrupciones por las siguientes cuatro
causas: (i) Interrupcion del canal, (ii) interrupcion de DMA debida a un stall, (iii)
interrupcion debida a que la Memoria FIFO se queda vaca y (iv) interrupcion BUSERR
(error en el bus).
2.1.7. Interfaz del GS (GIF, GS Interface
El GIF es la interfaz entre el EE y el GS. Obtiene los datos que se generan en el
EE y los enva con su formato adecuado al GS. Normalmente los datos que se envan al
GS los genera la VU1 (simple stream) o el EECore en conjuncion con la VU0 (complex
stream). Aunque estos datos se generan y se envan en paralelo, el GIF establece un
mecanismo de arbitraje de prioridad entre ellos.
El GIF puede obtener los datos de tres caminos distintos mostrados en la Figura
2.13, a saber, PATH1, PATH 2 y PATH 3:
1. PATH 1. Este camino de datos es el que siguen los datos que van desde la
memoria de datos de la VU1 (VU1 Mem1) al GS. La instruccion de la VU1 que
realiza este envio es XGKICK. Si se produjera esta instruccion antes de que se
terminara otra transferencia por el mismo camin, se produccira un stall. Si la
transferencia se produjera mientras ocurren otras por cualquiera de los otros dos
caminos, se encolara. Solo puede encolarse uan transferencia.
2. PATH 2. Este es el camino entre la FIFO del VIF del VU1 y el GIF. Este camino
se usa cuaando se usan las instrucciones DIRECT/DIRECTHL.
3. PATH 3. Este es el camino directo entre el bus principal del EE y el GIF. Se usa
cuando se transeren datos al GIF directamente desde memoria principal o desde
la scratchpad RAM.
Figura 2.13: Posibles caminos hacia el GIF, seg un la unidad funcional de origen.
44 CAP

Estos tres canales tienen un esquema de prioridad, su prioridad es PATH1 >
PATH2 > PATH3, lo que es logico si tenemos en mente la idea inicial de la ar-
quitectura de que sea el VU1 quien se ocupe de calcular el mundo 3D. Si se piden
trasmisiones simultaneas por los canales se resuelven en base al esquema de prioridad
anterior. Mientras se hace el arbitraje de la prioridad se produce un ciclo desocupa-
do (idle cycle). Por lo tanto, aunque las transferencias se ordenen consecuivas, estas,
efectivamente, no se hacen consecutivas. Las transferencias se hacen por los distintos
caminos a una frecuencia de 147,456 MHz.
La unidad basica de transferencia con el GIF es una primitiva del GS que consiste
en una GIFtag y a continuacion datos. Las transferencias se hacen en paquetes que
consisten en dos o mas primitivas. El GIFtag tiene 128 bits y especica el tama no y la
estructura de los datos que vienen a continuacion. Su estructura es:
NLOOP: Bits 0 - 14, tama no de la primitiva, tambien indica si es empaquetada,
o imagen.
EOP: Bit 15(End Of Packet) Informacion de si vienen mas primitivas.
PRE: Bit 46: Ignorar el campo PRIM o no.
PRIM: Bits 57 - 47, Datos a mandar al registro PRIM del GS.
FLG: Bits 58 - 59: Formato de los datos (empaquetados, listado, imagen, desha-
bilitado).
NREG: Bits 60 - 63: Descriptor de los registros. N umero de registros a usar.
Cuando el valor es cero son 16.
REGS: Bits 64 - 127: Descriptor de los registros
Tanto el GIFTag como los datos tienen que estar alineados a una frontera de 128
bits. Despues del GIFTag los datos pueden estar en tres modos distintos que especican
como tratarlos. Estos modos son:
1. Modo Empaquetado (Packed Mode). En este modo cada qword de datos se
interpreta y empaqueta de acuerdo con el descriptor de registros del GIFTag y se
dirige la salida hacia la direccion especicada en esos mismos registros.
2. Modo REGLIST (REGLIST Mode). En este modo los datos que siguen al GIFTag
se consideran cadenas de datos de 64 bits x 2 y se mandan a la salida sin
empaquetar como contenido de los descriptores de los registros. Luego se hacen
los paquetes en funcion de estos registros y se reduce su tama no.
3. Modo Imagen (IMAGE Mode). En este modo los datos que siguen al GIFTag se
consideran cadenas de datos de 64 bits x 2 y se mandan a la salida que marca el
registro HWREG del GS. Este modo se usa cuado se manda una imagen (como
puede ser una textura) al GS.
Cuando se usa el PATH 3 en IMAGE Mode se pueden especicar dos modos de
transmision, continuo e intermiente. Si se especica el intermitente, tras cada slice
que se transmita se sondean los otros caminos y se les da la preferencia si necesitan
transmitir (son de mas prioridad).
Las transferencias por el PATH 3 pueden ser tambien enmascaradas. Hay dos
formas de hacer esto, bien a traves de la instruccion MSKPATH3 o bien a traves del
campo M3R en el registro GIF MODE.
El registro de privilegios del GS esta directamente mapeado en el espacio de di-
recciones del EECore.
Cuando se hace una transferencai al GS el GIF especica en cual de los dos
contextos posibles del GS se almacena.
2.1.8. Unidad de procesamiento de imagenes (IPU, Image Data
Processor
El IPU es una unidad de procesamiento de imagenes con capacidad para realizar
la decodicacion de los macrobloques del estandar MPEG2 [34], la conversion RGB,
la cuantizacion de vectores y la descompresion de chorros o cadenas de bits (bits
streams). No posee ning un buer especial y comparte la memoria principal con los
otros procesadores a tiempo compartido. Esto signica que los datos se leen, se colocan
en memoria principal, se decodican y se vuelven a colocar decodicados en memoria
principal. La imagen decodicada se transere al GS que la usa como textura o como
datos de animacion.
Figura 2.14: Estructura de la Unidad de Procesamiento de Imagenes
El IPU implementa las siguientes capacidades:
Decodicacion estandar de bit streams. El IPU interpreta y decodica por hard-
ware el bit stream estandar de MPEG2. La compensacion de movimiento no la
realiza el IPU. La tiene que realizar el EECore ayudado por las instrucciones
multimedia.
Decodicacion de macrobloques. El IPU decodica los macrobloques que van en
el bit stream y los convierte a RGB. Esta es una de las capas de MPEG2.
Cuantizacion de vectores. El IPU puede convertir una imagen a color deodicada
directamente a una paleta de colores indizada de 4 bits haciendo la cuantizacion
de vectores dada por CLUT (Color LookUp Table). Esta tecnica se usa para
proveer el patron de texturas que la tecnica CLUT requiere. Tambien se usa
cuando la capacidad del area de texturas esta limitada. La idea de Sony es que
para ver una textura en la TV al 50 fps no es necesario que sea una textura de 32
bits. De hecho, en la Figura 2.15 vemos texturas de la PS2 de 4 bits solamente.
Podemos apreciar una muy buena calidad.
Control de transparencias. El plano alpha (plano de transparencias) se genera a
partir del valor de luminacia decodicado y de un coeciente.
Las funciones basicas del IPU son:
46 CAP

Figura 2.15: Con un n umero reducido de colores se puede conseguir una textura de
gran calidad, como se puede comprobar. Cada textura usa tan solo 4 bits de color.
Figura 2.16: Proceso de decodicacion de MPEG2 empleando el IPU.
1. Decodicar los macrobloques MPEG2.
2. Extraer el bit stream MPEG2.
3. Decodicar el bit stream MPEG2.
Esquematicamente, el proceso de descompresion de video MPEG2 usando el IPU se
muestra en la Figura 2.16.
2.1.9. SIF, Sub-CPU Infertace
El SIF el un modulo que sirve como la interfaz de la unidad con el IOP. Recordemos
que el IOP tiene sus propios 2 MB de memoria local y su propio bus para controlar
el procesador de sonido, el disco duro y los demas perifericos de entrada/salida de
la consola. Para realizar las transferencias con los dispositivos, el DMAC trabaja en
cooperacion con el SIF y con su memoria FIFO bidireccional (SFIFO). En la Figura
2.17 se muestra la estructura del SIF.
Figura 2.17: Estructura del SIF
Para transmitir los datos, estos se agrupan en unas unidades llamadas paquetes
(packets). A cada paquete se le asocia una etiqueta (DMATag) que es uan estructura
de datos que contiene metainformacion a cerca de la direccion de los datos en el espacio
de memoria del IOP, de la direccion de los datos en el espacio de memoria del EE y del
tama no de los datos en s.
Para transmitir datos desde el IOP al EE, el controlador de DMA del IOP lee
del DMATag la direccion de su espacio de memoria y carga los datos con el tama no
especicado desde la direcion leda hasta la SFIFO. Despues, el DMAC del EE vuelve
a leer el DMATag para obtener la direccion de los datos en su espacio de memoria
y saca los datos de la SFIFO y los copia donde proceda. De esta manera, el uso del
DMAC y de la SFIFO evita que se produzcan interrupciones innecesarias y se mejora
el rendimiento. La Figura 2.18 nos ilustra el proceso.
48 CAP

Figura 2.18: Flujo en una transferencia de datos entre el IOP y la memoria del Emotion
Engine.
Captulo 3
Desarrollo del proyecto
Explicaremos con detalle las alternativas de las que disponemos para realizar el
proyecto, as como una gua paso a paso de la solucion que hemos adoptado denitiva-
mente, a n de servir como manual didactico. Iremos comentando al par las decisiones
de dise no y de implementacion, as como los posibles problemas encontrados, y la
solucion adoptada.
3.1. Desarrollo del proyecto
3.1.1. Especicacion de las tareas
Como vimos en la Figura 1.2, inicialmente hemos organizado el proyecto en tres
tareas bien denidas. Ahora comenzaremos el desarrollo de cada parte, y comentaremos
los problemas encontrados as como las soluciones propuestas y la solucion adoptada.
Primero debemos observar el hardware disponible, y la funcionalidad de cada parte,
para poder determinar una distribucion lo mas logica posible sobre el. La Figura 3.1
muestra un funcionamiento normal de las unidades funcionales que vamos a emplear
seg un su dise no original. Como se aprecia, el procesador central y la VU0 se encargan
del procesamiento variado, mientras que la VU1 se emplea principalmente para calculos
computacionalmente pesados que se aplican constantemente y de forma invariante a
la geometra.
Figura 3.1: Uso normal de los procesadores que conforman el Emotion Engine
49
50 CAP
ITULO 3. DESARROLLO DEL PROYECTO

3.1.2. Metodo de programacion de la consola
Como mencionamos anteriormente, existen principalmente tres formas de progra-
mar la consola. La ((mejor)) alternativa es inviable para nosotros, pues no podemos
acreditarnos como desarrolladores ociales de Sony, ni disponemos del presupuesto ne-
cesario para hacerlo. Teniendo en cuenta que lo que buscamos es poder programar las
unidades principales de procesamiento de forma comoda para facilitar la realizacion de
practicas de laboratorio sobre arquitecturas no comunes, tampoco necesitamos el equi-
po y soporte requerido en un desarrollo comercial. Por tanto, quedan dos alternativas
que detallaremos a continuacion.
Programacion stand-alone
Nos referimos a la que se realiza sin soporte alguno por parte de la consola. El
programa resultante se ejecuta directamente en la consola, no necesitando ninguna
conguracion adicional de software ni hardware en la consola. Se realiza mediante la
creacion de los ejecutables usando compilacion cruzada desde el PC.
Los cheros necesarios pueden encontrarse en el proyecto ((ps2stu)) [8] del portal
de linux para la Playstation2 [14]. Basicamente se necesitan los siguientes elementos:
Compilador para el procesador central MIPS (el Emotion Engine)
Ensamblador para las unidades vectoriales (las VU)
Con estos elementos congurados de forma adecuada podremos generar ejecu-
tables tanto para el procesador MIPS como para las unidades vectoriales VLIW. El
principal inconveniente que presenta este metodo es la forma de hacer que el ejecuta-
ble generado sea cargado por la consola. Debido a la proteccion anticopia presente en
el hardware de la Playstation2, no se puede grabar un CD-ROM e insertarlo en la ban-
deja, esperando que arranque. Podemos recurrir a la implantacion de un ((mod-chip))
para paliar esta limitacion. De nuevo surge un inconveniente con esta va de trabajo.
Grabar un CD-ROM cada vez que vayamos a probar el programa supone un gasto
considerable en material, ademas de la necesidad de implantar una grabadora de CD
en los ordenadores que se vayan a destinar para el desarrollo sobre la consola.
Otra posible va para enviar el ejecutable a la maquina pasa a traves de la aplicacion
conocida como ((Naplink [40])), un programa de transmision de cheros entre la consola
y un ordenador, mediante una arquitectura cliente-servidor, a traves del puerto USB,
mediante un cable especial denominado PL2301, cuyo aspecto es el que muestra la
Figura 3.2. Este programa crea un link de comunicacion mediante el puerto USB entre
el PC y la consola, de forma que la consola ejecuta el ejecutable que se le transere desde
el PC, y permite mostrar mensajes de depuracion directamente en el PC. Para poder
cargar el cliente de Naplink en la consola, necesitamos nuevamente poder arrancar un
programa cualquiera en la consola, por lo que necesitamos disponer de un ((mod-chip)).
Esta opcion requiere tener modicada cada consola, con la perdida de garanta
que ello supone. Ademas necesita tener al menos un PC para programar las consolas, y
supone programar a un nivel demasiado cercano a la maquina, pues no disponemos de
ning un tipo de facilidad a la hora de la depuracion, requisito principal en un ambiente
educativo. No hay que olvidar que queremos iniciar la programacion al alumnado, y
para ello debemos permitirle una cierta sencillez de depuracion para evitar la apata
que produce la frustracion de la impotencia.
Tambien tenemos que tener en cuenta que ninguna de las bibliotecas usadas de
esta forma tienen soporte de Sony, y que pueden variar sin previo aviso, funcionar
3.1. DESARROLLO DEL PROYECTO 51
mal, estar incompletas, o simplemente indocumentadas, como apuntamos inicialmente
cuando la mencionamos.
Figura 3.2: Cable PL2301 USB
Programacion mediante el kit de linux
Con esta opcion,adquirimos el kit de desarrollo linux que ofrece Sony, y dispone-
mos de los manuales de las unidades funcionales, con lo que contamos con una ayuda
ocial de Sony. Tambien recibimos una distribucion especial de linux para la arqui-
tectura MIPS de la PlayStation2, basada en Red Hat, y lo sucientemente completa
como para traer gran cantidad de herramientas y utilidades de desarrollo para la pla-
taforma. Editores, compiladores, servidores, clientes y utilidades entre muchas otras
aplicaciones, facilitan la tarea del usuario hacia la programacion, ademas de propor-
cionar un entorno familiar de desarrollo. Al estar trabajando bajo un linux, toda la
funcionalidad de este sistema operativo esta disponible, as como sus herramientas mas
comunes, lo que supone un grado de similaritud muy elevado para el programador, ya
acostumbrado a trabajar en entornos linux. Esta familiaridad conseguida supone una
gran reduccion de la complejidad que supone enfrentarse a un nuevo tipo de hardware,
pues al menos el entorno de desarrollo se mantiene mas o menos inalterado, pudiendo
aplicar conocimientos adquiridos hace tiempo para obviar la parte del aprendizaje de
un nuevo conjunto de herramientas de desarrollo, pudiendo centrarse unicamente en el
aprendizaje del nuevo hardware subyacente.
Hay que tener en mente que el sistema operativo esta ejecutandose unicamente
en el procesador central, el MIPS, dejando las VU totalmente libres. Esto conlleva la
seguridad de que todo lo que se programe para las VU no se vera afectado por el
sistema operativo. Tan solo lo que ejecute el procesador principal competira con el
sistema operativo en cuanto a recursos. Puede parecer un gran impedimento a priori,
pero hay que pensar que cuando se trabaja con una arquitectura general, como es
la x86, aunque sea a nivel ensamblador de procesador, el sistema operativo siempre
va inherente (excepto en contadas excepciones en las que unicamente se emplean
instrucciones de la BIOS).
Para las unidades vectoriales disponemos de un ensamblador especco para dichos
nes, mientras que para el MIPS tendremos el compilador nativo, que a efectos practicos
resultara ser semejante al cruzado, ya que ambos estaran generando codigo objeto
de un MIPS III modicado. En esta ocasion, sin embargo, contamos con una gran
cantidad de bibliotecas y utilidades que facilitan el desarrollo, as como una interface
de entrada/salida hacia el lector de DVD, el disco duro, los puertos USB, los mandos
de control (o ((gamepad))), etcetera. Supone una capa mayor de abstraccion entre el
hardware y el usuario, pero no limita por ello la capacidad de utilizacion en cuanto a
formacion didactica se reere.
52 CAP

La unica limitacion que encontramos a nivel de programacion es la unidad de con-
trol de entrada salida de perifericos, tambien conocido como IOP, ya que los drivers
del n ucleo de la distribucion de linux que trae el kit nos impiden controlar dicho proce-
sador a un nivel similar al del resto de componentes. Sin embargo, esto no supone una
limitacion para nuestros nes, ya que no existe un gran interes didactico en acceder
al lector de DVD o a los mandos de control de forma cercana al hardware, y la abs-
traccion que hacen las bibliotecas y el sistema operativo de los mismos evitan la ardua
tarea de tener que realizar muchas llamadas a bajo nivel para abrir un chero o leer
los botones presionados. El driver del n ucleo abstrae dicho hardware y proporciona una
interface similar a la que encontramos en cualquier sistema operativo linux, basada en
dispositivos.
La distribucion, por contra, quizas sea un punto mas delicado a tratar, aunque no
repercute en la funcionalidad didactica del material. Al haber sido desarrollado bajo
el kit de linux, la aplicacion necesita de bibliotecas y soporte del sistema operativo
que solo se encuentran disponibles en un kit de linux. Por tanto, cualquier aplicacion
desarrollada bajo un kit de linux solamente funcionara en otra consola en la que se
disponga de un kit de linux, siendo imposible compilar la aplicacion para que funcione
de forma ((stand-alone)).
No podemos olvidar el descargo monetario que supone esta opcion que, si bien
no es comparable a la opcion que hemos descartado directamente, supone un gasto
adicional que no posee la opcion anteriormente descrita. Tambien hay que recordar que
recibe soporte de Sony, algo que se pierde casi con total seguridad al intentar usar el
metodo ((stand-alone)) debido a la necesidad de implantar un ((mod-chip)).
Eleccion del sistema de programacion
Teniendo en cuenta las ventajas y desventajas proporcionadas por cada metodo,
conclumos que la mejor opcion sera disponer de una facilidad de depuracion y de-
sarrollo por encima del rendimiento, ya que se trataba de comenzar desarrollos en la
maquina, y no de realizar una produccion de alta calidad. Por tanto, pensando en el
proposito real del proyecto, y disponiendo del visto bueno del departamento, adquirimos
un kit de linux para comenzar el desarrollo sobre la PlayStation2.
3.1.3. Programacion de las unidades
EE Core (procesador MIPS)
Aunque disponemos del repertorio completo de este procesador en los manuales
que ofrece Sony en los DVD del kit adquirido, sabemos por experiencia propia que el
compilador de C nativo disponible en el sistema, el compilador GNU C Compiler (gcc),
es un producto muy competente para arquitecturas de proposito general. Consideramos
que el codigo objeto generado es suciente optimo como para descartar la idea de
programar en ensamblador para el MIPS. Si se desea obtener mas informacion sobre la
programacion de esta arquitectura, puede remitirse al Manual de Referencia sobre los
MIPS [32], o concretamente al manual de instrucciones [25] del MIPS especco de la
PlayStation.
Por tanto, lo que aprovecharemos de este procesador es su arquitectura de proposi-
to general, para aprovechar el uso de bibliotecas ya disponibles y la programacion con
los componentes de entrada/salida del resto de consola, siendo el procesador ((central))
de la aplicacion, que repartira tareas y se encargara de coordinar el resto de unidades.
3.1. DESARROLLO DEL PROYECTO 53
Como hemos dicho, todo lo relativo al sistema operativo linux que tenemos eje-
cutandose en la maquina se ejecuta en este procesador, por lo que nuestra aplicacion
competira por cuantums de procesamiento con el resto de servicios del sistema opera-
tivo, suponiendo una disponibilidad del procesador variable y dependiente del tiempo
para nuestra aplicacion. Este hecho conlleva tambien a que la ejecucion de un progra-
ma en dicho procesador sea inmediato, ya que basta crear un programa y ejecutarlo
tal y como se llevara a cabo en cualquier otro linux ejecutandose en una arquitectura
soportada cualquiera.
Unidades Vectoriales (VU0 y VU1)
Este tipo de unidades conforman, junto al sintetizador graco, los elementos mas
especcos de la arquitectura de la consola. Aunque sus caractersticas dieren, basi-
camente se trata del mismo dise no, por lo que las consideraremos de momento como
una unica unidad en cuanto a programacion.
La informacion detallada sobre su repertorio de instrucciones viene en el manual
de las unidades vectoriales proporcionado por el DVD de documentacion que acompa na
al kit de linux. El manual se reere a ambas unidades vectoriales, donde se hacen las
distinciones oportunas a la hora de explicar las instrucciones que posee y los modos de
funcionamiento disponibles.
La forma de ejecutar un programa en la unidad vectorial diere bastante de la
forma explicada para el procesador central. Al contrario que este, no es un procesador
de proposito general, y no ejecuta ning un fragmento del sistema operativo. De hecho,
es necesario el uso del procesador principal para poder ejecutar algo en la unidad vec-
torial, ya que la carga del programa en la memoria de la unidad vectorial se debe hacer
mediante instrucciones del procesador central. La Figura 3.3 muestra un esquema con
los pasos necesarios para ejecutar un programa en la unidad vectorial. Como mencio-
namos anteriormente, disponemos de un ensamblador para dicha unidad, con el que
generamos el codigo objeto para luego cargarlo en la unidad vectorial, como ya veremos
posteriormente.
Figura 3.3: Esquema para la ejecucion de un programa en las unidades vectoriales
El Sintetizador Graco (GS)
La programacion del sintetizador graco siempre se muestra de forma relativa-
mente indirecta, ya que no se programa como tal, simplemente se le envan ordenes
desde la VU1 o desde el EE, y esta realiza su funcion de forma automatica. No hay una
programacion ((real)) tal y como sucede con el MIPS o las VU, en las que cargamos un
54 CAP

programa y vamos interactuando con los datos que recibimos. El sintetizador se limita
a recibir una serie de paquetes gracos llamados ((GIF tags)), y realiza su salida en
pantalla. Estos ((GIF tags)) estan compuestos de una geometra y unos atributos a nivel
de vertice, que usa el hardware inherente a dicha unidad y los transforma en polgonos
2D proyectados en la pantalla, con los atributos determinados.
3.1.4. Distribucion en las unidades
Debemos distribuir las tareas que necesitamos implementar entre las unidades que
queremos usar, para ver lo que podemos usar y lo que tenemos que hacer desde cero,
as como lo que necesitamos aprender a hacer en cada una de ellas.
Teniendo en cuenta las tareas consideradas en la Figura 1.2 y el uso normal de
las unidades mostrado en la Figura 3.1, determinamos que para la decodicacion
de ogg vorbis usaremos el procesador principal. Si no tuviera suciente potencia para
dicha tarea, distribuiramos la carga entre las unidades vectoriales, aunque el hecho
de que el algoritmo de decodicacion no sea computacionalmente muy pesado y el
procesador principal del que hablamos es un procesador a 300MHz hace que pensemos
que sera mas que suciente para dicha tarea.
Tras todo este proceso, obtenemos un buer con la salida de audio, lista para
ser enviada al dispositivo de sonido. Ahora debemos pensar en el procesamiento de
audio que haremos para obtener unos patrones dependientes del sonido momentaneo
y que sean representables de forma graca, para poder obtener la imagen a dibujar. Al
nal nos hemos decidido por hacer un espectrograma del sonido. Siguiendo los detalles
mostrados en la Figura 3.1, distribuiremos las tareas pertinentes siguiendo el criterio
mostrado en la Figura 3.4.
Figura 3.4: Criterio a seguir para la distribucion inicial de las tareas
En el apendice correspondiente a ogg vorbis se detalla todo lo referente a dicho
formato. Aqu simplemente mostraremos el esquema de las tareas que necesita realizar
la decodicacion, representado en la Figura 3.5. Si desea mas detalles sobre su fun-
cionamiento o mas informacion sobre los terminos usados, debe referirse al apendice
mencionado.
3.2. Implementacion del proyecto
3.2.1. Decodicacion de sonido
En la pagina WEB de Xiph [23] podemos encontrar una implementacion realizada
para sistemas unix/linux. Disponemos de dos bibliotecas, ya que ogg vorbis corresponde
a dos conceptos distintos: mientras que vorbis hace mencion al codec de audio en s,
que contiene el sonido codicado, ogg hace referencia a la encapsulacion de las tramas
de vorbis en el chero, para su almacenamiento fsico y su transmision. En lugar de ogg
3.2. IMPLEMENTACI
ON DEL PROYECTO 55
Figura 3.5: Tareas de las que se compone la decodicacion de Ogg Vorbis
56 CAP

se podra usar uno distinto para realizar una transmision streaming de vorbis mediante
red, por ejemplo. Por tanto, Xiph ha desarrollado una biblioteca para cada uno de
ellos, ambas disponibles en la direccion http://www.vorbis.com/download_unix_
1.0.1.psp:
libogg: es una biblioteca que se encarga de la decodicaci on del encapsulado
ogg, que es donde viajan las tramas vorbis. Esta biblioteca es requisito para la
biblioteca de vorbis.
libvorbis: es la biblioteca encargada de decodicar el audio contenido en las
tramas vorbis encapsuladas en un ujo ogg de datos. Contiene tambien otra
biblioteca a mas alto nivel denominada vorbisle, que presenta una capa de abs-
traccion mayor sobre el chero ogg vorbis, ofreciendo un interface al programador
mas sencillo en cuanto a manipulacion del mismo.
Al estar implementado para un linux en un lenguaje portable como C, y ser por
tanto independiente de la arquitectura, nuestra primera opcion es probar a compilarlo
para nuestra arquitectura MIPS, y probar alguno de los programas de ejemplo que traen
las bibliotecas. Procedemos a realizar la prueba inicial, para comprobar si la biblioteca
es totalmente portable a nuestra maquina o si por el contrario necesitamos reprogramar
ciertas partes del codigo para hacer que se pueda ejecutar sin problema.
Como es com un en los productos desarrollados para linux, simplemente tenemos
que instalar las dependencias necesarias y compilar el paquete. Una vez instalada, en
el directorio libvorbis-1.0/examples/ encontramos unos peque nos programas de
ejemplo que sirven de demostracion del uso de la biblioteca para cargar y decodicar los
cheros ogg vorbis. Nos centraremos principalmente en el chero de ejemplo de la biblio-
teca libvorbisfile. En el chero vorbisfile example.c podemos ver las siguien-
tes llamadas principales a la biblioteca mencionada, acompa nadas de una breve sinopsis
de su funcionamiento, extradas de la documentacion online de la biblioteca, disponible
en la direccion http://www.xiph.org/ogg/vorbis/doc/vorbisfile/reference.
html:
ov comment: devuelve un puntero a la estructura vorbis comment para el chero
especicado. Esta estructura contiene la informacion contenida en los comenta-
rios del chero. Datos como el ttulo de la cancion, el nombre del autor, el a no,
estilo de cancion, album de la cancion y demas informacion de semejante tipo va
almacenada como comentario del chero. Para mas informacion sobre la forma de
almacenar estos comentarios y el formato usado, se puede consultar el apendice
destinado al formato ogg vorbis.
ov info: devuelve la estructura vorbis info del chero especicado. Esta es-
tructura contiene informacion relativa a la version de ogg vorbis, el n umero de
canales y la frecuencia de muestreo, entre otras. Estos dos ultimos parametros
son los que nos interesaran a nosotros.
ov read: esta funcion es la funcion principal de la decodicacion en s. Devuelve
el n umero de bytes de audio PCM decodicado, seg un el tama no de muestra
para cada valor, y el n umero de canales. La decodicacion en el buer genera
un entrelazado en los canales como se muestra en la Figura 3.6. Realmente este
entrelazado no hace mas que facilitarnos la tarea a la hora de reproducir, ya que
como veremos mas adelante, el dispositivo de salida espera este mismo formato
como datos de entrada.
3.2. IMPLEMENTACI
ON DEL PROYECTO 57
Figura 3.6: Entrelazado de los canales
ov clear: con esta funcion cerramos el chero y limpiamos los buers auxiliares
de la decodicacion.
Una vez probado el ejemplo y viendo que compila, tan solo queda cerciorarse
de que el procesador MIPS sera lo sucientemente potente como para decodicar el
chero. Para ello nos basta mirar el uso de la CPU por parte del programa de ejemplo
comentado, para hacernos una idea de los recursos computacionales que emplea en
la decodicacion. Como ya hemos comentado varias veces, el procesador central es
unico encargado de ejecutar el sitema operativo. Por tanto, toda la informacion que el
sistema operativo sea capaz de proporcionar sobre los procesadores que usa se referiran
unicamente a dicho procesador. Esto nos supone una ventaja para lo que pretendemos
realizar a continuacion, ya que podemos emplear una utilidad cualquiera que muestre el
uso de CPU por proceso para saber de forma aproximada que porcentaje del procesador
esta siendo usado por cada una de las tareas. Para esta labor nosotros usaremos el
afamado programa top. Este programa genera una tabla en la que muestra una lista de
procesos activos, ordenados seg un su ocupacion de CPU. Se puede encontar en http:
//www.groupsys.com/top/, y la Figura 3.7 muestra un ejemplo de su salida. Nuestra
aplicacion de ejemplo ocupa aproximadamente el 23 % de los recursos computacionales
del procesador, lo que supone una carga sucientemente baja para no tener que realizar
a priori ninguna optimizacion del codigo proporcionado por Xiph.
Figura 3.7: Un ejemplo de la salida mostrada por top
58 CAP

3.2.2. Reproduccion de sonido
Una vez solventado el tema inicial de decodicacion de audio, nuestro siguiente
objetivo es la reproduccion del sonido decodicado. Por tanto, debemos ahora progra-
mar el dispositivo de salida, y enviar el ujo de datos obtenido tras la decodicacion.
Como ya mencionamos, la unidad encargada de dicha tarea es el procesador de sonido,
capaz de producir sonido digital 3D usando AC-3 y DTS. Sin embargo, ning un docu-
mento de los proporcionados por Sony trae nada referente a dicho procesador. Esto se
debe a que, como ya dijimos anteriormente, el kit de linux abstrae algunas unidades
de la consola, impidiendo su acceso directo. El procesador de sonido es una de ellas.
Toda interaccion con este procesador se realiza a traves del dispositivo de sonido del
sistema linux (/dev/dsp) como si se tratara de la tarjeta de sonido de un PC normal.
Es decir, la programacion del procesador de sonido lo realiza un modulo del n ucleo de
linux, proporcionando una total abstraccion de su hardware al programador.
Esta circunstancia supone una ventaja, pues aunque no tenemos experiencia pro-
gramando sonido desde linux, la informacion que se puede encontrar sobre este punto
en INTERNET es bastante amplia, y todo esta muy documentado. Al ser programa-
cion general de linux podemos acelerar el desarrollo del prototipo realizandolo para
PC, ya que disponemos de nuestro entorno de programacion completo, con todas las
facilidades que ello conlleva.
En el portal linux.com [4] podemos ver un artculo [51] comentando las distintas
alternativas de programacion de sonido que hay en el mercado en cuanto a programa-
cion de sonido en linux se reere. Nosotros no necesitamos un sistema muy elaborado
de sonido, necesitamos uno lo mas simple y rapido posible, con el menor retardo aso-
ciado. Normalmente esto implica una programacion a un nivel mas bajo de lo que
supondra emplear una API de mayores caractersticas y abstraccion. Otra razon es
la dependencia de bibliotecas externas. Estamos intentando minimizar la cantidad de
aplicaciones necesarias para la ejecucion de nuestro programa. Por tanto, decidimos
programar directamente el sonido usando con el driver que proporciona el n ucleo del
sistema. Con la informacion obtenida del libro Linux Multimedia Guide [49] en su
version WEB, y de la informacion proporcionada por 4Front Technologies [1] sobre
la programacion [47] de OSS (Open Sound System), creamos una aplicacion prototipo
que genera una salida por el dispositivo de audio. Los pasos a seguir para el funcio-
namiento del dispositivo de audio se representan en la Figura 3.8. El orden ha de ser
ese, pues la conguracion de un parametro hace que otro parametro vuelva a tomar
su valor por defecto, por lo que se requiere un orden especco para poder congurar
todos los parametros a valores personalizados.
Como podemos leer en las anotaciones que se realizan para la reproduccion de
varios canales, debe mandarse entrelazado cada canal, tal y como aparece en la parte
inferior de la Figura 3.6. Tras modularizar ambas partes en audio y ch, lo pasamos
a la PlayStation2 para cerciorarnos de que funciona como habamos previsto, y no
tenemos que cambiar nada. El programa funciona perfectamente en la consola tal y
como esperabamos, por lo que podemos dar por nalizada la primera parte del desarrollo
inicial sobre el procesador central MIPS.
3.2.3. Modelo graco. Procesamiento de audio
Ahora es momento de implementar el sistema graco. Antes de representar gra-
camente el sonido debemos procesar los datos PCM que obtenemos de la decodicacion
de ogg vorbis y transformarlos en una serie de valores utiles para su representacion en
pantalla. Determinamos antes que vamos a realizar un espectrograma de la se nal.
3.2. IMPLEMENTACI
ON DEL PROYECTO 59
Figura 3.8: Orden de conguracion del dispositivo
Con espectrograma nos referimos al analisis espectral de la se nal, dividiendo frag-
mentos del sonido en trozos en los que analizaremos las frecuencias presentes, para
realizar un estudio estadstico de las frecuencias principales que estan presentes en ca-
da trozo. La Figura 3.9 muestra una se nal representada mediante su onda y su espectro
en frecuencias en la parte inferior.
Figura 3.9: Ejemplo de espectograma (abajo) y se nal de origen (arriba)
Lo primero que debemos hacer para poder contabilizar las frecuencias de la cancion
es un cambio de dominio. La onda que obtenemos al decodicar esta en el dominio
60 CAP

del tiempo, un dominio que no nos es util. Tenemos los valores que toma la se nal a lo
largo del tiempo de forma discretizada, como representamos en la Figura 1.3.
El dominio mas ((frecuente)) con el que se trabaja en sonido para la reproduccion
es el del tiempo. Es la forma mas natural de pensar en el sonido, ya que representara
el estado de excitacion de la se nal en un tiempo determinado, que sera reejado en la
vibracion que recibira el altavoz, reproduciendo dicho sonido. Sin embargo, el domi-
nio en frecuencia es mucho mas util para determinados campos, ya que permite una
manipulacion mucho mas comoda de la se nal. Es capaz de extraer la frecuencia del
sonido, obviando el resto de factores que conforman la textura del sonido. Para una
breve introduccion sobre los elementos que conforman un sonido, puede visitar la pagi-
na del Centro de Estudios Avanzados en las Artes [41], de la Universidad de Texas. En
la Figura 3.10 se puede ver la diferencia conceptual existente entre ambos dominios,
viendo la representacion de varios tipos de se nal tanto en tiempo como en frecuencia.
Por tanto, debemos convertir nuestra se nal al dominio en frecuencia, que es el que
nos proporciona informacion util para nuestro proposito: caracterizar el fragmento de
sonido que decodicamos. Para pasar del dominio del tiempo al dominio de la frecuencia
necesitamos realizar una transformada de Fourier [52] a la se nal. Aqu veremos una
explicacion sencilla sobre la transformada de Fourier. Si quiere profundizar mas, le
recomendamos que lea la bibliografa anteriormente citada.
Figura 3.10: Se nal en el dominio en tiempo y en el dominio en frecuencia
Transformada de Fourier
Un proceso fsico puede describirse tanto en el dominio del tiempo como en el
dominio de la frecuencia, por una serie de valores, denominados parametros. Pode-
mos tener h(t) o bien H(f) si estamos reriendonos a la expresion gobernada por
un parametro que depende del tiempo (dominio en tiempo) o de un parametro que
depende de la frecuencia (dominio en frecuencia). Normalmente se entienden ambas
formas como dos representaciones distintas de una misma funcion. Podemos denir la
relacion entre ellas como aparece en la ecuacion (3.1). En dicha ecuacion vemos que
la transformada de Fourier es una operacion lineal. La transformacion de la suma de
dos funciones es igual a la suma de las transformaciones de cada se nal por separado.
3.2. IMPLEMENTACI
ON DEL PROYECTO 61
H(f) =
_
+
h(t)e
2ift
dt
h(t) =
_
+
H(f)e
2ift
dt
(3.1)
Transformada de Fourier sobre un conjunto de datos discretos
En la mayora de las ocasiones, la funcion h(t) esta muestreada a intervalos espa-
ciados en el tiempo. Si usamos para denotar el intervalo de tiempo entre muestras
consecutivas, la secuencia de valores muestreados se muestra en la ecuacion (3.2). El
inverso de se denomina tasa de muestreo.
h
n
= h(n) n = . . . , 3, 2, 1, 0, 1, 2, 3, . . . (3.2)
Como sabemos, para cualquier existe una frecuencia especial, f
c
, denominada
frecuencia crtica de Nyquist, dada por la expresion
f
c

1
2
(3.3)
Esta frecuencia es importante por dos razones. Una de ellas es por el teorema de
muestreo, que viene a determinar la frecuencia mnima a la que hay que muestrear una
se nal para poder ser reconstruda sin error. La otra razon ocurre cuando se muestrea
una se nal sin cumplir el teorema anterior. El efecto obtenido es que toda la densidad de
potencial espectral que cae fuera del rango f
c
< f < f
c
se desplaza de forma erronea
a ese rango. Cualquier componente en frecuencia fuera de dicho rango es transladado
a ese rango al muestrear. La unica opcion contra este efecto es conocer el rango de la
funcion a muestrear y muestrear a la suciente velocidad para proporcionar al menos
dos puntos por ciclo de la frecuencia mas alta presente.
Transformada Discreta de Fourier
Podemos estimar la transformada de Fourier desde un n umero nito de puntos
muestreados de la curva original. Supongamos que tenemos N muestras, como expre-
samos en
h
k
h(t
k
), t
k
k, k = 0, 1, 2, . . . , N 1 (3.4)
Con N valores de entrada, solo obtendremos N valores independientes a la salida,
por lo que en lugar de calcular H(f) en todo el rango de f entre f
c
y f
c
, calcularemos
el valor de H(f) para dichos puntos concretos, como mostramos en
f
n

n
N
, n =
N
2
, . . . ,
N
2
(3.5)
Una vez aproximada la integral por una suma discreta, obtenemos la relacion (3.6),
llamada transformada discreta de Fourier, a la que denotaremos como H
n
. Como puede
apreciarse, no depende de ning un parametro dimensional, como era la escala temporal
.
H
n

N1
k=0
h
k
e
2ikn/N
(3.6)
62 CAP

Figura 3.11: La funcion original (a) es distinta de cero en un intervalo T de tiempo.
Su transformada de Fourier (b) no tiene limitacion por ancho de banda, pero tiene
amplitud en todas sus frecuencias. Si muestreamos con el intervalo como aparece
en (a), la transformada de Fourier (c) esta denida entre f
c
. La potencia fuera de
ese rango se desplaza a dicho rango.
La relacion entre la transformada discreta y la transformada contnua cuando las
vemos como muestras de una funcion contnua muestreada a un intervalo , puede
escribirse como
H(f
n
) H
n
(3.7)
donde f
n
viene dada por (3.5). La transformada discreta de Fourier tiene las mismas
propiedades de simetra que la transformada continua de fourier.
Transformada Rapida de Fourier (FFT)
Si analizamos la carga computacional que supone calcular la transformada discreta
de Fourier para N puntos, podramos llegar a la conclusion de que, deniendo W como
W e
2i/N
(3.8)
podemos expresar (3.6) como
H
n
=
N1
k=0
h
k
W
kn
(3.9)
Tenemos un vector de h
k
multiplicado por una matriz cuyo (n, k)-esimo elemento
es la constante W elevado a la nk potencia. Dicha multiplicacion produce un vector
3.2. IMPLEMENTACI
ON DEL PROYECTO 63
cuyas componentes son las H
n
. Esta multiplicacion requiere N
2
multiplicaciones com-
plejas, y un menor n umero de operaciones para generar las potencias de W necesarias.
Por tanto, parece que la transformada discreta de Fourier es de (N
2
). Sin embargo, se
puede calcular en (Nlog
2
N) con el algoritmo llamado transformada rapida de Fourier
(FFT).
En 1942, Danielson y Lanczos probaron que una transformada discreta de longitud
N puede ser reescrita como la suma de dos transformadas discretas de Fourier, cada
una de longitud N/2. Una tiene los puntos pares y otra los puntos impares de la original.
La prueba es La demostracion es la siguiente:
F
k
=
N1
j=0
e
2ijk/N
f
j
=
N/21
j=0
e
2i(2j)k/N
f
2j
+
N/21
j=0
e
2i(2j+1)k/N
f
2j+1
=
N/21
j=0
e
2ijk/(N/2)
f
2j
+W
k
N/21
j=0
e
2ijk/(N/2)
f
2j+1
= F
e
k
+W
k
F
o
k
(3.10)
Lo bueno de este lema es que puede usarse recursivamente. Habiendo reducido el
proglema de calcular F
k
al de calcular F
e
k
y F
o
k
, podemos hacer la misma reduccion
para F
e
k
, transformandolo en su N/4 entrada impar y N/4 entrada par. As, podemos
denir F
ee
k
y F
eo
k
como la transformada discreta de Fourier de los puntos que son
los par-par y par-impar en las sucesivas subdivisiones de los datos. Por razones de
sencillez, supondremos simpre que N es una potencia de 2. As, podremos aplicar esta
subdivision hasta que tengamos transformaciones de logitud 1. La transformada en ese
caso es simplemente la operacion identidad que copia una entrada en una salida. Para
cada patron de log
2
N de e y o, hay una transformada de un punto que es simplemente
uno de los n umeros de entrada f
n
F
eoeeoeooee
k
= f
n
para alg un n (3.11)
El siguiente paso es determinar que valor de n corresponde a que patron de e y o en
la ecuacion 3.11. La solucion es invertir la secuencia de e y o, y sustituir e = 0 y o = 1,
y el n umero formado sera el valor en binario de n. Supongamos que cogemos el vector
original de valores f
j
y lo reordenamos en su orden inverso de bits, como muestra la
Figura (3.12), obteniendo un vector ordenados seg un el inverso de j. Sobre este vector,
la aplicacion recursiva del lema de Danielson-Lanczos es extraordinariamente sencilla.
Podemos combinar parejas adjacentes de puntos para obtener transformaciones de
dos puntos, y combinamos parejas adjacentes de parejas para obtener transformadas
de cuatro puntos, y as hasta la primera y segunda mitad de todo el conjunto de
datos se combine en la transformada nal. Cada combinacion conlleva un orden de N
operaciones, y son log
2
N combinaciones, lo que hace un total de Nlog
2
N.
64 CAP

Figura 3.12: Reordenacion de un vector (longitud 8 en este caso) por inversion de bits,
(a) entre dos vectores, (b) en un vector
Implementacion e integracion de la FFT
Dada la importancia de una implementacion optimizada y la gran difusion de este
proceso por doquier, pensamos buscar una implementacion able y sucientemente op-
timizada para evitar sorpresas futuras al encontrar errores durante la depuracion dadas
por un fallo en la implementacion del algoritmo, as como la creacion de un innecesa-
rio cuello de botella, pues la velocidad de la FFT es crtica en nuestro procesamiento
visual. Podemos encontrar gran cantidad de implementaciones en la WEB, bibliotecas
[56] completas incluso. Sin embargo, recurrimos a una implementacion usada para algo
similar a nuestro proposito, entendiendo que es una implementacion sucientemente
valida para nuestra aplicacion al ser usada para propositos similares. Una vez mas re-
currimos al programa XMMS [46], que contiene en su codigo [11] unas funciones que
transforman los datos de sonidos decodicados a su espectro de frecuencias mediante
una transformada rapida de Fourier.
Llegado este momento, decidimos realizar una implementacion de prueba aparte
de la consola, con una representacion en calidad de prototipo bajo el estandard graco
OpenGL [33], para denir el algoritmo de espectrograma, con el proposito de aislar
los errores posibles encontrados. Esto es posible dadas las circunstancias actuales: (i)
la parte de decodicacion, reproduccion y transformacion al dominio en frecuencia se
realizaran en el procesador central MIPS de la consola, (ii) el codigo referente a cada
uno de los pasos anteriores es codigo C portable entre plataformas, (iii) la indepen-
dencia del codigo de visualizacion, que sera necesario reimplementar en ensamblador
para la unidad vectorial VU1. Esta decision se toma por diversas razones, que supo-
nen una mayor facilidad y rendimiento del desarrollo de esta parte. Las razones son
principalmente:
N umero de herramientas disponibles: como comentamos anteriormente, nuestra
plataforma de desarrollo habitual es el PC, y disponemos de diversas utilidades
que facilitan la tarea de desarrollar y depurar codigo en el mismo. Por contra, la
consola no esta concebida para ser una plataforma de desarrollo directamente, y
aunque la cantidad de herramientas disponibles no es despreciable, dista mucho
del repertorio del que dispone un PC.
3.2. IMPLEMENTACI
ON DEL PROYECTO 65
Familiaridad con la API de OpenGL: poseemos cierta experiencia con el sistema
de programacion graco OpenGL, lo que repercute en una gran sencillez a la
hora de desarrollar un prototipo graco en el que mostrar un avance del efecto
producido por el algoritmo de caracterizacion de sonido.
Independencia del hardware y la programacion nativa de la consola: este punto
quizas sea el mas importante. Nos referimos a la posibilidad de desarrollar el
algoritmo que generara a su salida una serie de propiedades que usaremos para
representar gracamente un patron que identique las caractersticas del sonido
sin tener que lidiar de momento con el hardware de dibujo de la consola, esto
es, el sintetizador graco. Con esto conseguimos comprobar que resultado se
obtiene en el algoritmo, y desligar completamente los errores de programacion
del mismo a los errores de programacion relativos al apartado graco. Dado
nuestra inexperiencia con este hardware especco, hemos sido realistas al pensar
que el n umero de errores de programacion en este apartado seran numerosos y
su desarrollo sera lento, pues supone la etapa de aprendizaje mas dura a priori.
Por todo esto, preferimos aislar todo lo posible los errores de otras fuentes para
evitar errores en cadena.
Como comentamos en la itroduccion a la FFT, tener un n umero de muestras
N potencia de dos facilita mucho la aplicacion de las propiedades de recursividad,
lo que hace que sea mas eciente de implementar. La implementacion usada en el
XMMS hace uso de esta propiedad, como era logico suponer. El tama no concreto para
dicha implementacion es de 512. Los valores de salida deben ser tratados para poder
clasicarlos en los conjuntos de datos que usaremos nosotros a modo de barras.
Lo primero que necesitamos hacer es convertir los datos de salida de la FFT
para nuestro uso. Aplicando ese algoritmo obtenemos una salida en frecuencia, que
debemos adaptar a nuestros intereses. El primer paso consiste en escalar el rango de
valores que obtenemos de la FFT a un rango que nosotros podamos manipular. Primero
describiremos el efecto que pretendemos obtener, antes de entrar en los detalles del
procesamiento de calculo.
La intencion inicial es obtener un graco de bandas en el que quede representado
el espectro de la se nal. Como disponemos de un n umero bastante limitado de barras
para representar un espectro sucientemente amplio de frecuencias, debemos agrupar
valores de frecuencias en conjuntos. Iremos contabilizando el n umero de apariciones
en cada ((conjunto de frecuencia)) para un determinado fragmento de tiempo. Este
valor contabilizado ya supone una medicion en bruto que nos es util a la hora de
denir un espectro de bandas. Teniendo una medida sobre la aparicion de cada banda
de frecuencias considerada, podemos representar proporcionalmente a dicha medida
cada una de las bandas. As, como muestra la Figura 3.13, podramos dibujar una
altura diferente a una primitiva (en este caso un triangulo), proporcional al valor de
dicho conjunto. Si notamos a las frecuencias como f, podemos expresar las bandas de
frecuencia como
=
f
k
, k cte (3.12)
siendo k el valor que determina el ancho de cada ((banda de frecuencia)).
El rango completo de valores obtenido por la FFT es demasiado grande para
poder clasicarlo directamente en ((bandas de frecuencia)). Tengamos en mente que
aproximadamente el 80 % de los valores pertenecen al primer 15 % del rango de abscisas.
Si hicieramos una division lineal, en las primeras barras concentraramos casi todos los
valores, provocando una saturacion en ellas y una carencia de valores en las restantes.
66 CAP

Figura 3.13: Para poder considerar un espectro de frecuencia sucientemente amplio
con un n umero bastante reducido de barras a representar, necesitamos denir unas
((bandas de frecuencia)), considerando que cualquier frecuencia contenida en dichas
bandas pertenece a un ((conjunto de frecuencia))
Por tanto, para normalizar los valores a un espectro mas lineal antes de distribuirlos
en bandas haremos exactamente lo mismo que hace el programa XMMS [46]. Primero
realiza una raz cuadrada para eliminar parte de su condicion de no linealidad, y luego
divide por 256 para mover el dominio de valores a un rango mas reducido. Nosotros
normalizaremos la escala de valores a [0, 1] para los valores comprendidos en el rango
[0, 1024]. La cota de 1024 que hemos empleado aqu no es mas que un parametro
obtenido de forma emprica. La nalidad del parametro es jar la cota superior de
frecuencia que sera procesada en la representacion graca. Un valor de salida de la FFT
superior a sera ignorado, ya que siendo N el n umero de barras disponibles, caera en
un ((conjunto de frecuencia))
, siendo > N.
Por tanto, para todo [0, 1], una salida cualquiera de la FFT tras la norma-
lizacion, le corresponde un ((conjunto de frecuencia))
, tal que = N|.

3.2.4. Deteccion de la cadencia de la cancion
Antes de implementar el apartado graco en la consola, vamos a dotar a nuestro
prototipo con otro elemento que le dotara de un complemento visual. Queremos que
nuestra aplicacion reaccione tambien al ritmo de la cancion. Una denicion de ritmo la
encontramos en El liceo digital [35], donde queda denido como la relacion que existe
entre el transcurso del tiempo medido en sus propias unidades (por ejemplo, segundos o
sus fracciones), y la duracion de las notas, para lo cual puede tomarse como base el valor
de una ((redonda)). Para ello, detectaremos la cadencia de la misma, e iremos mostrando
un efecto visual cada vez que detectemos la subida de intensidad en la cancion. Esta
subida se detetara en relacion a un historico de la energa calculada anteriormente.
Es decir, tendremos una deteccion dinamica de la cadencia, que se ajustara a medida
que avanza la cancion. La ventaja de tener una deteccion dinamica es la posibilidad de
poder distinguir las variaciones en la intensidad de la se nal a un cuando la energa de
toda la cancion ha aumentado o disminudo.
3.2. IMPLEMENTACI
ON DEL PROYECTO 67
Gracias a la utilizacion de un historico adaptativo con el que ir comparando la evo-
luci on de la cancion evitamos la necesidad de denir empricamente una cota superior
de energa para la que determinaramos que se produce un golpe de intensidad, con el
consiguiente problema producido por la saturacion posible en los pasajes muy energi-
cos. Al ser dinamico, evitamos la posible saturacion, ya que aislamos la componente
media de energa.
Nosotros emplearemos un algoritmo de deteccion de cadencia descrito por Frederic
Patin, en concreto el algoritmo mas simple de los que describe en su artculo [42],
aplicando las optimizaciones pertinentes. Basicamente se trata de calcular la energa
del buer que consideramos como sonido en cada momento, un buer de longitud 1024
muestras. Sean y los buers de los canales derecho e izquierdo, podemos calcular
la energa como
=
stereo
=
=
i
0
k=i
0
([k]
2
+[k]
2
) (3.13)
Calculamos la energa local media con el buer del historico de energa E.
Deseamos registrar un historico de energa de aproximadamente un segundo de du-
racion. Supondremos que la m usica esta muestreada en calidad CD, lo que conlleva
unas 44100 muestras por segundo. Como hemos dicho, cada buer que decodicamos
de audio contiene 1024 muestras, lo que implica que necesitamos 44100/1024 43
valores. Por tanto, calculamos la energa local media haciendo
=
1
43

43
i=0
(E[i])
2
(3.14)
Tras calcular , desplazamos el buer E un lugar a la derecha para dejar espacio
a la nueva muestra, desechando el valor antiguo. Apilamos pues la nueva energa
en E[0]. Ahora solo debemos comprobar si se produce o no un golpe de ritmo. Para
ello, solo resta comparar con , donde es una constante umbral de sensibilidad.
Este valor ajusta la sensibilidad global del algoritmo a la deteccion de golpe de ritmo.
Cuanto mayor sea , mas variacion de la energa se requiere para detectar el cambio
como ritmo. Empricamente se demuestra que un valor = 1, 3 es acertado en la
mayora de los casos. Si obtenemos que > , podemos decir que hemos detectado
un golpe de ritmo. En la Figura 3.14 hemos representado un fragmento de una cancion
en su representacion de onda, y las cadencias detectadas.
3.2.5. Reimplementacion del plugin graco
Antes de comenzar la programacion de las unidades vectoriales vamos a migrar el
prototipo a la consola. Para ello no tenemos mas que eliminar toda la parte a nadida
para la representacion. Teniendo una version de prototipo minimizada en la consola,
comenzamos a construir la base sobre la que implementaremos la aplicacion nal. Todo
el desarrollo independiente del hardware de la maquina se ha acabado, y solo resta la
parte que implica una programacion del hardware.
Como hemos dicho, el primer paso es formar la base sobre la que integrar el
programa en C para el MIPS con el programa en ensamblador para las VU. Tras realizar
algunas pruebas para encontrar que programa de ejemplo contena una estructura y
unos requisitos mas parecidos para nuestro proposito, descartamos las demos de la VU
Demo Coding Contest [15], ya que suponan demasiadas limitaciones en cuanto a lo
68 CAP

Figura 3.14: De una onda (rojo) se puede estimar los golpes de ritmo (verde). Aqu he-
mos representado todo el buer de 1024 muestras como golpe de ritmo, ya que cal-
culamos la existencia o no de cadencia para cada uno de ellos, y no para muestras
concretas.
que intercomunicacion MIPS VU se reere. Su dise no inicial consista en disponer de
un programa en el MIPS, cuya unica mision era la de ser un cargador de las demos, que
se ejecutaban unicamente en la VU1. El programa cargador simplemente se encargaba
de cargar las distintas demos en la VU1. Por tanto, no se adapta a nuestro modelo de
aplicacion.
Por el contrario, las demos pertenecientes a la biblioteca libps2dev [13] s poseen
una estructura mas similar a la que nosotros pretendemos desarrollar. La aplicacion de
demostracion demo3d proporciona un grado de interaccion entre las unidades vectoria-
les y el procesador principal que podremos emplear como base para nuestro programa.
Esta aplicacion de ejemplo dibuja un cubo con texturas en sus caras e iluminacion, y
permite controlar el angulo de cada uno de los tres ejes con el mando de control de la
consola.
Desarrollo de la base para el MIPS
En este apartado vamos a describir los elementos necesarios que conforman la
conguracion de lo que es la consola. Se prescindiran de las partes correspondientes al
prototipo que desarrollamos anteriormente, es decir, a cualquier parte correspondiente
a nuestra aplicacion. Aqu solo vamos a explicar lo que necesitamos para formar lo que
se conoce como ((plantilla)) o ((esqueleto)), y se reere al conjunto de sentencias mnimas
que hay que escribir en cada uno de los programas para su correcto funcionamiento.
Analizaremos a continuacion las partes mas importantes del programa plantilla por
3.2. IMPLEMENTACI
ON DEL PROYECTO 69
fragmentos, indicando la nalidad de dichas lneas. Se omiten las partes de declaracion
de variables y semejante tipo de codigo, que pueden encontrarse en los cheros fuente
asociados y no requieren de ninguna explicacion.
Lo primero que debemos hacer es abrir cada una de las unidades que vamos a
usar. Para ello hacemos uso de las llamadas que proporciona la biblioteca libps2dev, y
abrimos el sintetizador graco (GS) y las dos unidades vectoriales (VU0 y VU1).
// abrimos el GS, VU0 y VU1
g fd gs = ps2 gs open(1);
g vpu0 = ps2 vpu open(0);
g vpu1 = ps2 vpu open(1);
// pasamos a modo graco
ps2 gs vc graphicsmode();
Tras esto, lo que hacemos es cargar en memoria el codigo objeto del programa a
ejecutar en la unidad vectorial. En nuestro caso, dicho chero se llama basic.elf.
// cargamos el programa de la VU1
vfd = vpuobj open("basic.elf", O DATA PS2MEM);
if (vfd == NULL) {
perror("vpuobj_open");
release();
exit(1);
}
Ahora realizamos una serie de pasos referidos al apartado graco. Primero con-
guramos el sintetizador graco con una serie de parametros que determinan el modo
de vdeo a generar. Como sabemos, la consola es apaz de generar distintos modos
de vdeo, tanto a resolucion (640x480,800x600. . .) como a formato (PAL, NTSC,
VGA. . .). Despues conguraremos el doublebuer, y crearemos cada uno de los buers
de pantalla a utilizar.
// reseteamos el GS
ps2 gs reset(0, g inter, g out mode, g mode, g resolution,
g refresh rate);
next2k = ps2 gs set dbu(&g db, g psm, gp>width, gp>height,
(g zbits == 0) ? 0 : PS2 GS ZGREATER,
g zpsm, 1);
// denimos los dos buers
*( u64 *)&g db.clear0.rgbaq = PS2 GS SETREG RGBAQ(0x00, 0x00, 0x00, 0x80,
0x3f800000);
*( u64 *)&g db.clear1.rgbaq = PS2 GS SETREG RGBAQ(0x00, 0x00, 0x00, 0x80,
0x3f800000);
Una vez denido lo anterior, limpiamos el buer y esperamos la sincronizacion con
el procesador principal, para continuar cuando la entidad graca este lista. Tras esto,
comenzamos la visualizacion graca.
// clear back buer
ps2 gs put drawenv(&g db.giftag1);
70 CAP

// wait clear done
ps2 gs set nish(&g nish);
ps2 gs wait nish(&g nish);
odev = !ps2 gs sync v(0);
ps2 gs start display(1);
ps2 gs vc enablevcswitch(acquire, release);
Ahora entramos en lo que sera el bucle innito de accion. Es decir, cada fotograma
dibujado pasara por este bucle, as que es en su interior donde debemos procesar la
informacion que queramos mostrar. Su estructura es muy sencilla. Se limita a detener
el sintetizador graco, cambiar el buer sobre el que se dibuja (debido al uso de double
buer que hacemos). Luego ira todo el procesamiento de datos que se desea realizar en
el MIPS, y una vez nalizados denimos el inicio del programa de la VU1 que vamos a
ejecutar mandando mediante DMA la informacion necesaria. La variable My dma start
esta denida en el chero ensamblador de la VU1, y en el codigo del MIPS la hemos
importado gracias a la macro IMPORT VPU SYMBOL, tal y como se puede apreciar en el
codigo fuente completo. Solo resta incrementar el fotograma en el que nos encontramos
(para que el programa sepa decidir que buer mostrar), y reanudamos el funcionamiento
del sintetizador graco.
// bucle innito
for (; ;) {
// detenemos el GS
ps2 gs vc lock();
ps2 gs swap dbu(&g db, frame);
// use ioctl
ps2 dma start(ps2 vpu fd(g vpu1), vfd,
(ps2 dmatag *)My dma start);
frame++;
ps2 gs vc unlock();
}
El trozo que encontramos a continuacion corresponde a la secci on posterior al bucle
innito. Depende de la forma de programacion del bucle, puede que se ejecute o no,
seg un la forma de salir del bucle. Aqu usaremos siempre que se permite la instruccion
break para salir del bucle innito, por lo que supondremos que dichas instrucciones
s son ejecutadas salvo comportamiento anomalo del programa, y terminacion erronea.
Solo resta liberar los recursos tomados al inicio, para lo que cerraremos primero el codigo
objeto del programa de la VU1, y el sintetizador graco, y las unidades vectoriales.
// cerramos los recursos
vpuobj close(vfd);
ps2 gs close();
ps2 vpu close(g vpu0);
ps2 vpu close(g vpu1);
3.2. IMPLEMENTACI
ON DEL PROYECTO 71
Introduccion a las unidades vectoriales
Llega por n el turno de la unidad vectorial. Las unidades vectoriales poseen dos
cauces de instrucciones, ya que son capaces de ejecutar dos instrucciones por ciclo de
forma simultanea. Sin embargo, ambos cauces no son simetricos, es decir, no todas las
instrucciones se pueden ejecutar en ambos. Hay algunas instrucciones que solamente
se pueden ejecutar en uno de ellos.
Figura 3.15: Arquitectura de las VU dentro del Emotion Engine
Como se aprecia en el esquema, las diferencias principales en la arquitectura de
las unidades VU0 y VU1 radican en la capacidad de la memoria de datos y la memoria
de programa, as como la carencia de una Unidad de Funciones Elementales (EFU) por
parte de la VU0. La otra caracterstica principal que hace que sean tan diferenciadas en
cuanto a uso viene determinada por las conexiones a las unidades circundantes. Como
se puede apreciar en la Figura 3.15, la VU0 esta unida directamente al EE, siendo lo que
se denomina su COP2 (su segundo coprocesador de calculo). Por contra, la memoria
de la unidad VU1 esta conectada al GIF (el interface hacia el sintetizador graco), y
los registros de la VU1 estan ((mapeados)) a la memoria de la unidad VU0. Una vision
mas detallada de una unidad vectorial puede contemplarse en la Figura 3.16.
FMAC: realiza suma, resta, multiplicacion y suma-producto sobre n umeros o-
tantes. Hay cuatro unidades para realizar ecientemente la operacion sobre vec-
tores de puntos en el plano (x, y, z, w).
FDIV: realiza division y raz cuadrada en aritmetica otante. El resultado se
almacena en el registro Q.
LSU: controla la carga/almacenamiento de la memoria de la VU. Debe realizar-
se de 128 en 128 bits, aunque las componentes del vector (x, y, z, w) pueden
enmascararse para no ser alteradas.
IALU: realiza computos sobre los n umeros enteros de 16 bits.
72 CAP

Figura 3.16: Arquitectura de las VU en profundidad
BRU: es la unidad encargada de controlar los saltos. Los saltos condicionales se
hace comparando uno o dos n umeros enteros.
RANDU: es el generador de n umeros aleatorios en el intervalo ]1,0, 2,0[.
EFU: es la unidad de funciones elementales, como exponenciales, logartmicas y
trigonometricas. Como se aprecia, solo esta disponible en la VU1.
Como hemos dicho, la unidad VU0 se considera el COP2 del procesador central
MIPS, lo que repercute en un modo de funcionamiento adicional del que el VU1 no es
capaz. Ambas unidades son capaces de cargar un programa en su memoria y comenzar
a ejecutarlos de forma independiente. A este modo de funcionamiento se la conoce
como micro modo de operacion. Sin embargo, la unidad vectorial VU0 posee un
modo adicional de funcionamiento integrado en el MIPS. Podemos pensar en el como
cuando programamos porciones de ensamblador empotrado en un codigo C mediante
la primitiva asm. No hace falta enviar un programa aparte a la unidad vectorial como
mostrabamos en el esqueleto del MIPS. A esta forma de funcionamiento de la VU0
se la conoce como macro modo. A continuacion mostraremos una tabla resumen con
las caractersticas de cada unidad vectorial, para que sirva como gua para hacerse una
idea de las diferencias funcionales entre las unidades vectoriales de las que disponemos.
3.2. IMPLEMENTACI
ON DEL PROYECTO 73
Micro modo (VU0/VU1) Macro modo
Operacion Opera como un procesador indepen-
diente
Opera como coprocesador del MIPS
Codigo de ope-
racion
Instrucciones LIW de 64 bits Instrucciones MIPS COP2 de 32 bits
Conjunto de ins-
trucciones
Instrucciones superiores + inferio-
res (pueden especicarse simultanea-
mente), EFU (solo la VU1), de con-
trol de unidades externas (solo la
VU1)
Instrucciones superiores, inferiores
(solo una parte), instrucciones
COP2 de transferencia (VCALLMS,
VCALLMSR)
N umero total de
instrucciones
127 instrucciones 90 instrucciones
EFU Se puede usar como opcion (solo
VU1)
No hay soporte
Registros 32 registros otantes de 128 bits, 16
registros enteros, registros especia-
les: ACC, I, Q, R {,P}
32 registros otantes de 128 bits, 16
registros enteros, registros especia-
les: ACC, I, Q, R y 16 registros de
control
Generacion de codigo objeto para la VU
Hemos mencionado que las unidades vectoriales disponen de dos unidades de ejecu-
cion, tal y como mostraba la Figura 3.16. Esto implica la emision de dos instrucciones
por ciclo, por lo que a la hora de programar se deben especicar concurrentemente
ambas instrucciones.
A continuacion mostraremos un ejemplo de la forma de programacion de estas
unidades, extrada del manual proporcionado por Sony para las unidades vectoriales
[30].
MULAw.x ACCx, VF16x, VF14w LQI VF17, (VI04++)
MSUBw.x VF16x, VF01x, VF14w LQI VF18, (VI05++)
MULAw.y ACCy, VF16y, VF14w LQI VF19, (VI04++)
MSUBw.y VF16y, VF01y, VF14w LQI VF20, (VI05++)
MULA.xyzw ACC, VF01, VF17 RNEXT VF16z
Cada columna de instrucciones corresponde a una unidad de ejecucion. Como
vemos, se especican en parejas. Cuando se debe esperar a la nalizacion de un cauce
para poder seguir computando, se emplea la instruccion NOP para rellenar el cauce que
ha de permanecer ocioso.
Como se puede intuir, este metodo de programacion dista mucho de ser comodo,
y es bastante propenso a errores y supone una gran dicultad a la hora de generar
mantenible y legible, ya que hay que tener en cuenta dos cauces distintos de codigo al
mismo tiempo. Tambien es difcil de editar debido a la naturaleza de los editores, ya
que la insercion de una instruccion en una columna supondra tener que modicar la
otra columna por completo de forma manual para dejarla intacta si no se desea rellenar
con una instruccion de NOP el hueco nuevo formado.
Como Sony es consciente de todo esto, y sabe ademas que una de las propiedades
necesarias para la difusion de su consola es la acogida de los programadores, se en-
cargo de programar un preprocesador para la unidad vectorial, que es lo que nosotros
usaremos. Se trata de VCL [31], cuya nalidad es la de procesar un chero ensambla-
dor secuencial con ciertas directivas especiales, y convertirlo en un chero ensamblador
con dos cauces de instrucciones en paralelo, optimizando fuertemente el codigo, a un
cuando es de cierta complejidad. A continuacion presentamos un extracto de un codi-
go ensamblador correspondiente a VCL, para apreciar la diferencia en complejidad de
74 CAP

desarrollo entre ambas formas.
sq RGBAval, 0(iRGBAQ out) ; store RGBA0
iaddiu iRGBAQ out, iRGBAQ out, 9
sq STVecs[0], 0(iST out)
iaddiu iST out, iST out, 9
sub vPos, vPos, vVel
add vVert, OsetVecs[0], vPos
vec x mat vTopLeft, vVert, PerspMat
div q, vf00[w], vTopLeft[w]
mulq vTopLeft, vTopLeft, q
Como podemos apreciar a simple vista, es mas sencillo seguir el ujo del programa
con un unico cauce de ejecucion que con un cauce dual. Tambien se simplica de
forma considerable la programacion al disponer de deniciones de macros, a nadido a
la coleccion de funciones denidas como macros para las operaciones entre vectores y
matrices mas usuales en el calculo 3D. VCL simplica la programacion ensamblador
en otro sentido tambien. Agrupa las instrucciones en instrucciones mas genericas, y
detecta automaticamente que uso de la instruccion se esta usando para a nadir los
sujos pertinentes.
El codigo ensamblador escrito para VCL se procesa y origina como salida un chero
ensamblador de las VU con un programa equivalente al especicado en VCL, con
su cauce dual y desenrollado de macros y demas conversiones pertinentes. Una vez
obtenido, se operara de semejante forma para convertirlo a codigo objeto, tal y como
si hubiera sido programado directamente en lugar de empleando VCL.
Para generar codigo objeto en formato legible por la funci on de la biblioteca
libps2dev necesitamos enlazarlo usando unas opciones especiales proporcionadas en
el chero vpu.cmd. Su nalidad no es mas que la de denir un objeto para el MIPS
5900, deniendo donde esta la memoria de programa y donde la memoria de datos.
Este chero lo proporciona Sony, y se puede encontrar en cualquier ejemplo. Al chero
ensamblador generado para VCL lo mentaremos basic.vcl, que producira un chero
basic.vsm al procesarlo. La extension vsm se reere a Vectorial Assembler, un juego
de palabras de la tradicional extension para cheros en ensamblador asm.
Necesitamos un chero donde deniremos informacion necesaria para que la VU
sea capaz de trabajar con el. La informacion relativa al paquete DMA, variables globales
que se exportaran hacia el MIPS, y valores determinados en posiciones de memoria de
datos de la VU se rellenan en este chero, que denominaremos cube.dsm, donde
incluiremos el chero generado mediante VCL basic.vsm en la seccion del codigo
relativo al programa. Analizaremos las secciones mas importantes de este chero, de
manera similar a lo que hicimos con el chero ((plantilla)) del MIPS.
Comenzamos deniendo el tipo de informacion a contener, y posteriormente in-
clumos el chero de macros que proporciona Sony para facilitar la denicion de cons-
tantes para rellenar la memoria de datos de forma manual. Esto viene en el chero
vumacros.h. A continuacion, denimos una lista de smbolos globales que usaremos
para exportarlos al MIPS, entre los que cabe destacar:
My dma start: representa el punto de inicio del programa a ejecutar en la VU1. Es
el que usabamos en el ((esqueleto)) del MIPS, ya que todo programa debe contener
una etiqueta que lo identique. El nombre no es relevante, pero decidimos dejar
el original para que sea mas facil relacionarlo si se ojea el codigo de ejemplo que
proporciona Sony.
3.2. IMPLEMENTACI
ON DEL PROYECTO 75
Mis valores, Mis valores1: representan un conjunto de valores que se usaran
posteriormente para los calculos. La anchura de las barras y la deteccion de la
cadencia forman parte de estos valores, entre otros.
Mis barras1, Mis barras2: corresponden a dos vectores de valores, cada uno
de ellos de longitud N, siendo N el n umero de barras a dibujar. Cada valor i-
esimo representa al ((conjunto de frecuencia))
i
, ponderado por una constante
s de escalado, determinada por la representacion graca de la consola.
El trozo de codigo que reeja todo lo anteriormente expuesto es:
.data
.DmaPackVif 0
.include "vumacros.h"
.global My dma start
.global My matrix
.global My cube start
.global My dma next
.global Mis valores
.global Mis valores1
.global Mis barras1
.global Mis barras2
Seguidamente denimos el inicio del codigo a ejecutar, My dma start. Como se
puede observar, basicamente es la inclusion del codigo vsm obtenido del programa
basic.vcl, encapsulado en una trama DMA.
My dma start:
.align 0
DMAcnt *
MPG 0, *
.include "basic.vsm"
.EndMPG
.EndDmaData
La siguiente seccion comienza precedida del smbolo global denido anteriormente
como My dma next, que no hemos tenido a bien de denir con anterioridad. El nombre
en realidad es simplemente herencia del original, aparecido en el codigo de ejemplo.
Como puede observarse, es una mera denicion adicional para My cube start. Se-
guidamente se dene lo que s es importante en esta seccion de codigo: el smbolo
My matrix. Este smbolo global tampoco ha sido explicado con anterioridad. Repre-
senta la matriz de transformacion de vista entre el mundo 3D y su proyeccion asociada
2D. Mas informacion sobre las transformaciones de vista se explican en el apendice
de visionado graco. Como podemos observar atentamente en la sentencia unpack, el
cuarto argumento es un 0. Este argumento determina la posicion que ocupa el valor
inmediatamente asignado dentro de la memoria de datos de la VU. En este caso, la
primera la de la matriz (recordemos que una direccion de memoria corresponde a un
cuarteto (x, y, z, w) de valores) estara en la posicion de memoria 0. La macro fwzyx
sirve para especicar un cuarteto de valores en coma otante en el orden (w, z, y, x).
Hay que tener esto en cuenta cuando se intenta observar la matriz usada.
76 CAP

My dma next:
DMAnext *, My cube start
unpack 4, 4, V4 32, 0, *; Screen Matrix
My matrix:
fwzyx 0.000000, 0.000000, 0.000000, 35.752483
fwzyx 0.000000, 0.000000, 14.765776, 0.000000
fwzyx 0.050000, 4995000.000000, 102.400002, 102.400002
fwzyx 1.000000, 100000000.000000, 2048.000000, 2048.000000
.EndUnpack
A estas alturas ya deberamos estar familiarizados con la denicion de valores
en zonas de memoria concretas. Como podemos observar, estamos deniendo nuestro
cuarteto de valores auxiliares en la posicion de memoria 8. Seguiran al codigo una
serie de deniciones semejantes que obviaremos dada su similitud con este codigo
aqu presentado.
unpack 4, 4, V4 32, 8, * ; mios
Mis valores:
fxyzw 4, 0, 0, 0
.EndUnpack
Llegamos al nal del chero, donde radica la parte mas interesante. Podemos ver
el smbolo global My cube start, cuyo nombre lo dejamos inalterado del original. Co-
mo vemos, denimos una serie de valores con la macro iwzyx. Esta macro representa
exactamente lo mismo que fwzyx con la salvedad de tratarse esta vez de n umeros
enteros (prejo i en lugar de f). Sin embargo, lo realmente importante es lo que se
esta deniendo aqu. Esa secuencia de cuatro cifras enteras representa el paquete GIF
que se mandara al sintetizador graco en la VU1. No es que se mande de forma direc-
ta, pero nuestro programa de la unidad vectorial cargara estos valores para fabricar en
tiempo de ejecucion un paquete GIF y mandarselo al GS, como veremos mas adelante.
Solo diremos que deniremos como primitiva graca un par de triangulos que confor-
maran una cara rectangular. El resultado sera equivalente a un rectangulo al que se le
traza la diagonal, dividiendolo en dos triangulos. Tras esto, denimos una posicion en
el mundo que usaremos de referencia, y cuatro colores, que emplearemos en el dibujo
de la imagen. Tras esto, cerramos el paquete DMA.
My cube start:
DMAcnt *
unpack[r] 4, 4, V4 32, 0, *
iwzyx 0x00000000, 0x00000041, 0x2005c000, 0x00008006
.EndUnpack
unpack[r] 4, 4, V4 32, 1, *
; position
fxyzw 0.0, 0.0, 0.0, 1.0
; color
fxyzw 255.0, 200.0, 0.0, 128.0
fxyzw 255.0, 0.0, 0.0, 128.0
fxyzw 170.0, 170.0, 255.0, 128.0
fxyzw 0.0, 100.0, 255.0, 128.0
.EndUnpack
MSCNT
3.2. IMPLEMENTACI
ON DEL PROYECTO 77
.EndDmaData
DMAend
Una vez comentada la estructura de cheros necesaria para la generacion del
codigo objeto, podremos comprender los pasos que se muestran en la Figura 3.17, que
ilustra la generacion de un chero objeto para ser cargado en la unidad vectorial.
Figura 3.17: Proceso necesario para obtener el codigo objeto desde el chero ensam-
blador.
Introduccion al sintetizador graco
Antes de explicar la programacion del sintetizador graco que necesitamos para
mostrar nuestro graco de barras por pantalla, haremos una breve introduccion al
sintetizador graco con la nalidad de entender un poco que conforma y como funciona
dicha unidad. Si se desea una informacion mas detallada y exahustiva, remitimos como
siempre al manual [29]. La Figura 3.18 muestra un esquema de su estructura interna.
Ahora comentaremos brevemente que es cada bloque denotado en dicho esquema,
para poder identicarlos.
Host I/F: es el interface encargado de transferir datos con el procesador. La
transferencia del buer y de la informacion de dibujado pasan por este interface.
Setup/Rasterizing (preprocesamiento): se encarga de generar las formas que se
dibujaran como puntos basandose en la informacion recibida sobre los vertices,
calculando a su vez su valor RGBA, valor Z y niebla para cada pixel.
Pixel Pipeline: realiza procesos como texturizacion, niebla, transparencias, y
determina el color nal con el que se debe dibujar basandose en la informacion
calculada en el Rasterizing. Puede procesar hasta dieciseis pixels concurrente-
mente.
Memory I/F: es el modulo encargado de leer y escribir en la memoria local
del sintetizador graco. Escribe los valores RGBA+Z del pixel a dibujar al nal
78 CAP

Figura 3.18: Descomposicion en bloques del sintetizador graco.
3.2. IMPLEMENTACI
ON DEL PROYECTO 79
de la operacion de dibujado, lee de memoria los valores de los pixels del frame
buer que se usan para las transparencias, y lee los valores RGBA de la imagen
representada.
Local Memory: se trata de la memoria local del sintetizador graco, compuesta
por 320Mbit, que contiene el frame buer, Z buer, las texturas y el CLUT (Color
Look Up Table o paleta de colores). Dispone de un puerto de lectura de 1024
bits y un puerto de escritura de 1024 bits para dibujar y acceder al frame buer
y al Z buer, y un puerto de 512 bits para leer la textura.
PCRTC: muestra el contenido del frame buer en el formato especicado.
Un detalle muy a tener en cuenta con el sintetizador graco para evitar problemas
mas adelante es el sistema de coordenadas que emplea. Es distinto al ((standard)) en
bibliotecas y sistemas de representacion habituales, lo que puede llegar a crear una
confusion si no se ha tenido en cuenta.
Sistema de Coordenadas de Mundo: usa una representacion de 16 bits de coma
ja, es decir 12 bits para la parte entera y 4 bits para la parte decimal, permitiendo
un rango de 0 a 4095,9375. Es decir, la parte de mundo que quedara plasmada
en la pantalla es la que corresponde a la ventana denida por este rango, tanto
horizontal como vertical. Por ejemplo, el punto central de la pantalla sera el
punto (2048, 2048). Hay que tener cuidado con esto cuando se quiera visualizar
algo.
Sistema de Coordenadas de Dispositivo: el punto de origen se sit ua en la esquina
superior izquierda del rectangulo de visualizacion.
La Figura 3.19 representa el ujo de dibujado necesario para convertir la infor-
macion que recibe del procesador (((host))) en datos representables gracamente por
pantalla. Los pasos que se siguen son:
Setup (Preprocesamiento): tanto el gradiente como los valores iniciales del al-
goritmo digital diferencial (DDA) necesarios para dibujar primitivas se calculan
basandose en la informacion de vertices que recibe desde el ((host)). Si la primi-
tiva graca es un triangulo, el gradiente del valor RGBA, el valor Z, el valor de
textura, y el valor de niebla en las tres aristas y en el scan line se calculan.
Rasterizing (DDA): los pixels correspondientes a una primitiva se calculan usan-
do el DDA. De forma concurrente se generan 8 o 16 pixels. El valor RGBA, valor
Z, de textura y la niebla para cada pixel se calculan del gradiente obtenido en la
etapa de preprocesamiento anterior.
Texture Mapping: la textura se aplican sobre los pixel. El color del pixel se
determina aplicando la funcion de textura al valor RGBA de la textura ledo de
la memoria, y al RGBA calculado por el DDA.
Antialiasing: el valor alfa se sustituye por la cobertura de pixel calculada por el
DDA (la cobertura del pixel se reere a la proporcion de pixel ocupada por el
lado de la primitiva teorica). Los lados se suavizan cuando las transparencias se
implementan usando este valor alfa.
Fogging: el valor RGB y el valor de niebla obtenidos del bloque de aplicacion de
textura se mezclan en concordancia con el valor de niebla del punto calculado
por el DDA.
80 CAP

Figura 3.19: Flujo de datos del sintetizador graco.
3.2. IMPLEMENTACI
ON DEL PROYECTO 81
Pixel Test: pintar un punto o no queda determinado por sus valores XYZ y
RGBA. Se realizan cuatro comprobaciones para determinarlo (recorte, prueba
de transparencia, transparencia destino y comprobacion de profundidad), que se
realizan una a una.
Alpha-blending: la mezcla del color RGB de un pixel y el valor RGB del frame
en memoria se implementa seg un el valor alfa del pixel o el valor alfa del frame
en memoria.
Formatting: se convierte el formato de los valores del pixel al formato usado en
el frame buer. Se suavizan o truncan los colores si es necesario.
Memory I/F: la lectura/escritura sobre la memoria se realiza a memoria local
en el chip. Las operaciones principales son: escribir pixels (RGBA,Z) en memoria
tras una operacion de pixel, leer valores de pixels al frame buer desde memoria,
y leer valores RGBA de memoria para representarlos.
Environment Register: conforman una serie de registros que contienen infor-
macion necesaria para el dibujado.
El hardware de la consola permite dibujar primitivas gracas directamente. Tiene
un hardware sucientemente complejo como para permitir que trabajemos en un nivel
de abstraccion superior a puntos en la pantalla. Mostraremos las distintas opciones que
soporta el sintetizador graco, con una breve descripcion aclarativa.
Punto (point):
Un punto suelto, dibujado con la informacion de
un vertice.
Lnea (line):
Una lnea independiente que une dos puntos,
dibujado con la informacion de dos puntos.
Lneas encadenadas (linestrip):
Sucesion de lneas que comparten el punto nal
como inicial de la siguiente, de forma encade-
nada. La primera necesita informacion de dos
puntos, y el resto solo de uno mas.
Triangulo (triangle):
Un triangulo independiente, formado con la in-
formacion de tres vertices.
Triangulos encadenados (trianglestrip):
Una sucesion de triangulos que comparten un la-
do con el triangulo siguiente. El primer triangulo
necesita informacion de tres vertices, y el resto
solo necesita un vertice por triangulo.
82 CAP

Triangulos en abanico (trianglefan):
Sucesion de triangulos que comparten un verti-
ce. El primer triangulo necesita informacion de
tres vertices, y el resto de triangulos solo nece-
sitan la informacion de un vertice mas.
Sprite:
Rectangulo dibujado con solo dos vertices, que
marcan la diagonal del mismo.
Programacion del sintetizador graco
Una vez examinadas por encima las capacidades del sintetizador graco, vamos a
explicar los pasos que hay que realizar para comunicar nuestras intenciones de pintar
algo en la pantalla.
El procedimiento general es bastante sencillo una vez comprendido el procedimien-
to. Primero debemos decirle al sintetizador graco que vamos a pintar. Esto incluye
tanto tipo de primitiva (una de la lista anterior), como propiedades de la misma, den-
tro de lo que se incluye tanto si queremos antialiasing, texturas, niebla, etc. como si
queremos especicar solamente la posicion de los vertices, o si queremos especicar
posicion y color, o cualquier combinacion de los posibles atributos, entre los que se
encuentran tambien las coordenadas UV de aplicacion de textura. Ademas, tambien
debemos especicar el n umero de vertices que vamos a denir, ya que es parte de la
primitiva la cantidad de aristas que estamos dibujando. Despues solo resta dar toda la
informacion que le hemos dicho que bamos a usar, y enviar la orden al sintetizador
graco. Daremos una informacion mas detallada sobre las opciones de cada paso, para
comprender las posibilidades.
1. Congurando el tipo de primitiva y los atributos de representacion: primero se
elige el tipo de primitiva y las opciones que tendra. Las opciones aparecen en la
Tabla 3.1
Atributo Descripcion Opciones
IIP Metodo de sombreado Flat/Gouraud
TME Aplicacion de Textura S/No
FGE Niebla S/No
ABE Transparencia S/No
AA1 Suavizado S/No
FST Coordenadas de Textura STQ/UV
CTXT Contexto 1/2
FIX Interpolacion FIX S/No
Cuadro 3.1: Antes de especicar la lista de informacion, se debe denir el tipo de
primitiva y las caractersticas que tendra.
2. Informacion de los vertices: en este apartado veremos los tipos de registros dis-
ponibles para especicar informacion variada sobre el vertice denido. Los tipos
de registros quedan recogidos en la Tabla 3.2.
3.2. IMPLEMENTACI
ON DEL PROYECTO 83
Elemento Registro Vertex
Kick
Drawing
Kick
Coordenadas XYZ2 S S
Coordenadas y coecientes de niebla XYZF2 S S
Coordenadas XYZ3 S No
Coordenadas y coecientes de niebla XYZF3 S No
Color y parametro Q de las coordenadas
de textura
RGBAQ No No
Parametros ST de las coordenadas de
textura
ST No No
Coordenadas UV del texel UV No No
Coeciente de niebla FOG No No
Cuadro 3.2: Registros existentes para especicar informacion asociada a un vertice.
Figura 3.20: Desplazamiento realizado en la cola de vertices como consecuencia de un
vertex kick.
3. Vertex Kick: si los registros usados tenan la funcion vertex kick la informacion
concerniente al vertice especicada hasta ese momento se sit ua en la cola de
vertices, y la cola avanza una posicion. A este proceso se le conoce como vertex
kick. La Figura 3.20 muestra una ilustracion de lo que supone este proceso.
4. Comenzar el dibujado (drawing kick): cuando toda la informacion necesaria
esta en la cola de vertices, el dibujado comienza.
Programa de la VU1: basic.vcl
En esta seccion detallaremos el codigo que compone el programa de la VU1, para
entender que hacemos en dicha unidad. Como hemos venido haciendo, explicaremos
fragmentos de codigo, relevando detalles signicativos del mismo.
Lo primero que haremos sera denir las constantes que referenciaran a las zonas
de memoria de datos que usamos en la VU1. Como ya vimos, escribamos algunos datos
tales como matrices o las barras en la memoria de datos de la VU1. Aqu denimos
84 CAP

un nombre para referirnos a dichas posiciones de memoria, haciendo mas legible el
programa que proseguira a continuacion.
; direcciones de memoria donde se encuentran los datos a usar
kScreenMat0 .assign 0
kMisValores0 .assign 8
kMisValores1 .assign 9
kBarras1 .assign 512
kBarras2 .assign 819
Ahora especicamos unas primitivas para el preprocesador, indicando que quere-
mos darle libertad en el empleo de todos los registros (no necesitamos usar manual-
mente ninguno impidiendo que lo use para sus nes), y le especicamos tambien que
queremos usar la sintaxis ((nueva)) del VCL. Y tras esto, comenzamos la seccion de
codigo.
.init vf all ; deja que el vcl use todos los registros otantes
.init vi all ; deja que el vcl use todos los registros enteros
.syntax new
.vu
enter
endenter
Inicialmente, cargaremos las constantes que necesitaremos emplear posteriormen-
te. Haciendo uso de las constantes denidas al inicio de todo, cargamos la matriz de
transformacion geometrica de la zona de memoria kScreenMat al vector Transform.
Tambien cargamos las ((constantes)) varias que denimos, donde pasaremos ciertos
parametros entre el EE y la VU1.
; cargamos la matriz de tranformacion geometrica
lq Transform[0], kScreenMat0(vi00)
; cargamos las constantes
lq MiValor, kMisValores0(vi00)
lq MiValor2, kMisValores1(vi00)
cont
Comenzamos la seccion de codigo que se ejecuta al inicio una unica vez. Recorda-
remos de apartados anteriores, cuando comentamos la denicion del chero cube.dsm,
que denamos un cuarteto de valores enteros que eran el GIF o especicacion de la
primitiva graca que bamos a emplear. Lo que realizamos en la primera seccion de
codigo es cargar aquellos valores que denimos (primitiva, vertice de referencia y los
colores). Destacaremos la instruccion xtop, que obtiene la direccion de la memoria
donde se encuentra el primer GIF (en nuestro caso, el unico). Por tanto, iniciamos
3.2. IMPLEMENTACI
ON DEL PROYECTO 85
unos punteros a dichos atributos para cargarlos posteriormente. Como podemos obser-
var, en la variable GifTag hemos almacenado el GIF, y la variable iKick apunta a la
primera direccion de memoria posterior al GIF libre. Es decir, tras los cuatro colores
que denieramos en su momento. En esa posicion guardamos el GIF mediante la ins-
truccion de almacenamiento (sq en este caso). Tal y como rezan los comentarios del
codigo, nos limitamos posteriormente a cargar la informacion que rellenamos en otro
chero de datos.
START0:
xtop iBase
lq GifTag, 0(iBase) ; carga el tag GIF
iaddiu iVert in, iBase, 1 ; puntero al vertice
iaddiu iColor in, iVert in, 1 ; puntero al color
iaddiu iKick, iColor in, 4 ; puntero a memoria libre para grabar
; nuestro tag GIF
sq GifTag, 0(iKick) ; graba el GIF
lq vert in, (iVert in) ; carga vertice
lqi color, (iColor in++) ; carga color 1
lqi color2, (iColor in++) ; carga color 2
lqi color3, (iColor in++) ; carga color 3
lq color4, (iColor in) ; carga color 4
Prosiguiendo los calculos que se realizan una unica vez por fotograma, nos encon-
tramos el paso de coordenadas de mundo a coordenadas de ((dispositivo)). El proceso
consiste en multiplicar la matriz de transformacion por el vector que contiene las coor-
denadas del punto, y normalizar seg un la coordenada W. Para ello usamos la macro
vec x mat para hacer T /, y en lugar de dividir por W, multiplicara por el inverso.
Recordemos que el registro otante vf00, al igual que el entero vi00 contiene valores
constantes en el, que no se pueden modicar. Por tanto, vf00 contiene el cuarteto
(0, 0, 0, 1) siempre. Aqu se usa la coordenada w, es decir, el 1. Estamos calculando
el inverso, ya que dividimos 1 por el valor. Con este valor (que resulta ser 1/W),
normalizamos el resultado obtenido en el producto anterior.
; calcula la transformacion de geometria y normaliza por W,
; guardando el resultado en oatScreenVec
vec x mat trans vert, vert in, Transform
div q, vf00[w], trans vert[w]
mulq oatScreenVec, trans vert, q
Como el vertice de referencia que usamos es el centro de la pantalla, y queremos
pintar barras ordenadas en frecuencia, lo mas sencillo para simplicar el bucle futuro
es movernos unicamente en una direccion, en lugar de tener que hacerlo en ambas.
Por tanto, lo que hacemos es desplazar la posicion de origen a uno de los lados, para
que el bucle solo tenga que ir desplazando en el contrario. En este caso, decidimos
mover el origen a la izquierda (unos 240 pixels), por lo que pintaremos de izquierda
a derecha las barras. Denimos el n umero de iteraciones que hara el bucle en 15, ya
que pintaremos cuatro barras por vuelta y canal, lo que hace un total de 60 barras por
canal. En iBarras e iBarras2 mantendremos el puntero a los datos del canal derecho
e izquierdo respectivamente.
86 CAP

; desplaza el punto 240 a la izquierda para que este en el margen
; en lugar de en el centro de la pantalla
loi 240.0
subi.x oatScreenVec, oatScreenVec, I
; vamos a dar 15 vueltas (en cada una pintamos 4 barras por canal)
iaddiu cuenta, vi00, 15
; cargamos las barras
iaddiu iBarras, vi00, kBarras1 // puntero a las barras
iaddiu iBarras2, vi00, kBarras2 // puntero a las barras
Comenzamos ahora con el bucle LOOP. Primero situamos el puntero de zona libre
a una zona realmente libre (recordemos que estamos especicando triangulos, lo que
implica tres vertices con tres colores). Cargamos el valor de las cuatro primeras barras
de cada canal en las variables barrasOrig y barrasOrig2.
LOOP:
; apunta a una posicion libre de memoria
iaddiu iKick, iBase, 6
; carga los valores Y de las barras y avanza los punteros
lqi barrasOrig, (iBarras++)
lqi barrasOrig2, (iBarras2++)
Esta parte del codigo trata la iniciacion de las variables necesarias para calcular
temas relativos al dibujado de las barras. Situamos los punteros donde grabaremos
la informacion de los vertices (color y posicion). En MiValor2.y tenemos el valor
detectado de cadencia de la se nal. Es decir, el indicador de ritmo. Valor que usaremos
para producir una separacion vertical entre las barras de cada canal, por lo tanto,
desplazamos el punto de origen hacia arriba para pintar el canal derecho. Antes de
dibujar las barras, cargamos el valor proporcional de altura que debe tener la barra,
obtenido tras el procesamiento del valor de la FFT. Cargamos de cuatro en cuatro
valores, de modo que la primera barra se dibujara con el valor de barrasOrig.x, la
segunda con el valor de barrasOrig.y, y as sucesivamente.
; canal derecho
iaddiu iRGBAQ out, iKick, 1 ; puntero para grabar los RGBAQ
iaddiu iXYZF2 out, iKick, 2 ; puntero para grabar los XYZF2
; sube el origen de la barra segun el beat detection
sub.y oatScreenVec, oatScreenVec, MiValor2
; carga la altura de la barra
add.y MiValor, vf00, barrasOrig[x]
3.2. IMPLEMENTACI
ON DEL PROYECTO 87
El dibujo de las primitivas se realiza en esta parte. Lo que
hacemos es calcular la posicion de cada vertice relativa a la
posicion de referencia debidamente desplazada seg un la ca-
dencia anterior. As, denimos los seis vertices que conforman
nuestra primitiva, cada uno de ellos con la correspondiente
informacion relativa al color. La distribucion de los seis verti-
ces se muestra en la gura de la derecha. Como se aprecia,
tras grabar el valor del vertice o color, incrementamos los
respectivos punteros. Disponemos de dos colores por canal,
que generaran un gradiente. Los vertices de la base (1, 2 y
6) usan uno, y los del techo (3, 4 y 5) usan el otro.
; crear primitivas
; vertice 1
move oatX1Y1, oatScreenVec
ftoi4 ScreenVec, oatX1Y1
sq ScreenVec, 0(iXYZF2 out) ; graba XYZF2
iaddiu iXYZF2 out, iXYZF2 out, 2
; color
ftoi0 screenCol, color
sq screenCol, 0(iRGBAQ out)
Proporcionada la informacion relativa a los seis vertices que forman nuestra pri-
mitiva, podemos enviarla a la cola de vertices para que sea dibujada. Antes de eso,
desharemos el desplazamiento que realizamos para separar las barras verticalmente,
como efecto especial para representar la cadencia de la cancion. La instruccion xgkick
manda la informacion de los vertices al sintetizador graco. Adelantamos el puntero a
una zona libre, y escribimos el nuevo GIF para denir el canal que resta.
; deshace la subida para el beat detection
add.y oatScreenVec, oatScreenVec, MiValor2
; manda el GIF al GS y mueve el puntero a una posicion libre
xgkick iKick
iaddiu iKick, iKick, 25
sq GifTag, 0(iKick) ; graba el tag GIF
Una vez hemos terminado de pintar la barra de un canal, dibujaremos la barra del
canal restante antes de pasar a dibujar la siguiente barra. Iniciamos punteros de color y
posicion, desplazamos esta vez hacia abajo seg un la cadencia determine, y cargamos el
valor de esta barra, contenido en barrasOrig2.x. A partir de aqu, volvemos a hacer lo
mismo de antes: comenzamos a denir los seis vertices que conformaran el rectangulo.
iaddiu iRGBAQ out, iKick, 1 ; puntero para grabar los RGBAQ
iaddiu iXYZF2 out, iKick, 2 ; puntero para grabar los XYZF2
add.y oatScreenVec, oatScreenVec, MiValor2
add.y MiValor, vf00, barrasOrig2[x]
; crear primitivas
; vertice 1
move oatX1Y1, oatScreenVec
ftoi4 ScreenVec, oatX1Y1
sq ScreenVec, 0(iXYZF2 out) ; graba XYZF2
88 CAP

iaddiu iXYZF2 out, iXYZF2 out, 2
; color
ftoi0 screenCol, color3
sq screenCol, 0(iRGBAQ out)
De manera similar a lo que ocurra en el otro canal, una vez concluda la especi-
cacion de los vertices que forman la barra, se enva al sintetizador graco. Movemos
el puntero al inicio, para escribir la informacion relativa a las barras del canal derecho
siempre en la misma zona de memoria, y volvemos a escribir el GIF por si se hubiera
sobreescrito por el canal izquierdo. Una vez concludo, nos desplazamos horizontalmen-
te por la pantalla, para pintar la siguiente barra con una separacion hasta la anterior,
como hemos hecho entre cada par de barras.
; deshace la subida para el beat detection
sub.y oatScreenVec, oatScreenVec, MiValor2
; manda el GIF al GS y mueve el puntero a una posicion libre
xgkick iKick
isubiu iKick, iKick, 50
sq GifTag, 0(iKick) ; graba el tag GIF
; deja separacion para la siguiente barra
add.x oatScreenVec, oatScreenVec, MiValor ; MiValor.x = ancho
add.x oatScreenVec, oatScreenVec, MiValor ; MiValor.x = ancho
Llegado a este punto, tenemos dibujadas cuatro barras en pantalla, as que hemos
formalizado una vuelta del bucle. Actualizamos el valor del bucle, y vemos si quedan
mas vueltas que realizar. Si es armativo, volvemos a LOOP para comenzar a dibujar
las siguientes cuatro barras. En caso contrario, reiniciamos el programa desde START0.
; n de la vuelta, queda una menos
iaddi cuenta, cuenta, 1
ibne cuenta, vi00, LOOP
cont
b START0
.END
Captulo 4
Optimizaci on del programa
sobre el hardware
En este captulo nos centraremos sobre la distribucion de la carga inicial del pro-
cesador central hacia la unidad vectorial VU0, funcionando como coprocesador para el,
logrando una integracion de computo entre el MIPS y la VU0 dentro del mismo codigo
gracias a la posibilidad de insertar codigo ensamblador en cualquier programa de C, y
a la posibilidad que ofrece la VU0 para ello.
4.1. Uso de la VU0 como ayuda del MIPS
Cuando probamos el prototipo del programa descubrimos que la velocidad del
MIPS no era suciente para procesar toda la carga que le habamos propuesto. Sin
embargo, conocedores de que era facil distribuir gran parte de la carga pesada del
procesador central a calculos en la VU0 ejecutandose como coprocesador (en lo que
denimos como macro modo), proseguimos con la programacion del apartado graco
sin prestarle mayor atencion entonces, como explicamos en el apartado 3.2.5.
Ahora es el momento de distribuir parte de la carga asignada al MIPS y su FPU
a la VU0. Usando top, la herramienta ya comentada para medir el uso de CPU de la
que disponemos, aislamos las partes de codigo que suponan un uso muy considerable
de CPU, y que podan ser facilmente transladadas en su totalidad.
Primero haremos una breve introduccion a la forma empleada para programar el
codigo para usar la VU0 como unidad de coprocesamiento, y los detalles a tener en
cuenta cuando usemos esta modalidad de programacion. Posteriormente, analizaremos
en mayor profundidad las secciones de codigo a transladar, y expondremos el codigo
equivalente una vez programado para la VU0.
4.1.1. Programacion in line de la VU0 como preprocesador
Tal y como hemos dicho en secciones anteriores, la unidad vectorial VU0 tiene
la capacidad de trabajar como coprocesador para el EE. De forma similar a como
ocurre en un PC compatible x86 con su coprocesador matematico, la forma de usar el
repertorio ((expandido)) gracias al coprocesador consiste en invocar a cualquiera de las
instrucciones que forman parte del coprocesador, y de manera automatica, se ejecutaran
en la unidad correspondiente. Es decir, solo necesitamos programar en el ensamblador
89
90 CAP
ITULO 4. OPTIMIZACI
ON DEL PROGRAMA SOBRE EL HARDWARE

correspondientepara que el programa resultante se ejecute de forma correcta en la
unidad vectorial. El tipo de instrucciones que provee la VU0 al MIPS al actuar de
coprocesador se divide en cuatro categoras:
Instrucciones de transferencia: empleadas para la transferencia de datos entre el
EE y la VU0. Podemos enviar de una unidad a otra tanto n umeros otantes como
enteros.
Instrucciones de salto: eval uan las se nales condicionales del MIPS COP2. Se usan
para preguntar por el estado de la VU1.
Instrucciones de calculo de coprocesador: conforman el repertorio de operaciones
que se pueden realizar con los datos. Valor absoluto, sumas, productos, restas,
divisiones, producto-suma, maximos, mnimos, races cuadradas, operaciones logi-
cas y generacion de n umeros aleatorios entre otras. Les precede la letra V para
distinguirlas de instrucciones con nombres similares, propias del repertorio del
MIPS.
Instrucciones de llamadas a microsubrutinas: hacen posible la ejecucion de un
programa hecho en micro codigo desde la forma de ejecucion como coprocesador,
realizando una llamada a dicha subrutina. As, se puede mezclar macro codigo
con micro codigo.
Una forma de empotrar codigo ensamblador en el codigo C es usar el metodo
((in line)). Este metodo consiste en emplear la sentencia asm para escribir una por-
cion de codigo en ensamblador. Debido a la circunstancia de encontrarnos bajo un
entorno de desarrollo linux con el compilador gcc de C, la sintaxis empleada es la de
dicho compilador. Gracias al conocimiento adquirido sobre programacion en ensambla-
dor empotrada en un programa de C, recibido en las asignaturas de Arquitectura de
los Computadores I [55], Arquitectura de los Computadores II [37] y Arquitectu-
ras Especializadas [43], asignaturas cursadas por ambos, estabamos sucientemente
familiarizados con el proceso de integracion comentado, y optamos directamente por
este metodo de programacion. Para aquellos que no hayan tenido contacto anterior con
la programacion de ASM y C al mismo tiempo, existe una pagina [12] donde re unen in-
formacion sobre la programacion de ensamblador bajo linux. En dicha pagina podemos
encontrar un enlace a un artculo [44] que hace una descripcion sobre la forma de de
programacion ((in line)). Aqu resumiremos lo esencial para entender el codigo que usa-
remos nosotros. Si se desea profundizar mas, se remite a las referencias proporcionadas
en este parrafo, as como a las asignaturas mentadas.
La estructura general de la sentencia asm la mostramos a continuacion:
asm ( codigo en ensamblador
: operandos de salida (opcional)
: operandos de entrada (opcional)
: lista de registros sobreescritos (opcional)
);
Un ejemplo sencillo donde se perciba la utilidad de cada uno de los campos expues-
tos anteriormente sin crear confusion adicional puede tratarse de hacer una asignacion
equivalente a una del tipo a = b en C, solo que realizada en ensamblador dentro de
un programa en C. Quedara:
int a = 12, b;
asm ( "
4.1. USO DE LA VU0 COMO AYUDA DEL MIPS 91
movl %1, %%eax # eax <- oper[1]
movl %%eax, %0 # oper[0] <- eax
"
: "=r"(b) /* b es el operando de salida (oper[0]) */
: "r"(a) /* a es el operando de entrada (oper[1]) */
: "%eax" /* %eax es el registro usado en el codigo asm */
);
Con lo descrito hasta aqu, consideramos que se entendera la mecanica basica de
esta forma de insercion de codigo ensamblador dentro de programas C. Quien desee
profundizar mas puede remitirse a las referencias dadas, as como al tutorial de Brennan
[50] y el Linux Assembly HOWTO [54], cosa que aqu no trataremos debido princi-
palmente a que no consideramos necesario desarrollar en toda su extension el potencial
de este tipo de incrustacion de codigo, y maxime teniendo en mente que el repertorio
de instrucciones que emplearemos sera totalmente distinto, ya que no se trata de una
arquitectura mentada en ninguno de los documentos que hemos propuesto, cuya nali-
dad principal es la de mostrar como se puede interactuar en una mezcla de alto y bajo
nivel con el sistema operativo.
Haciendo las primeras pruebas para probar a insertar codigo VU0 en el MIPS
llegamos al principal inconveniente: cuando cargamos algunas variables de la memoria
del EE a la de la VU0, recibimos un error en el bus. Como bien se puede leer en
la documentacion, el problema es simplemente la alineacion de las variables: ((si la
direccion efectiva (GPR[base]+oset) no esta situada en una frontera de 128 bits, es
decir, los 4 bits menos signicativos no son cero, el EE generara una excepcion de error
en la direccion)). Por tanto, debemos alinear las variables que vayamos a usar para la
VU0.
Para ello generaremos una funcion encargada de tal tarea. El funcionamiento basi-
co es reservar el n umero suciente de bits para poder desplazar el inicio del puntero, de
forma que este alineado con una frontera de 128 bits. Necesitamos que los ultimos cua-
tro bits de la direccion de memoria sean cero. Si hacemos un algoritmo ((siempre hacia
delante)), es decir, siempre desplazando el puntero hacia delante para alinear, aunque el
mnimo cambio para alinear el puntero se consiguiera desplazandolo hacia atras, pode-
mos determinar que la cantidad maxima de bits a desplazar siempre sera inferior a 128
bits. Por tanto, reservarmos 128 bits adicionales de memoria. Como el direccionamiento
a memoria, y en general cualquier operacion con la memoria, se realiza a nivel de byte
como mnima unidad, calculamos la direccion de memoria mas cercana hacia delante
que es frontera de 128 bits, y desplazamos el puntero a ella. La funcion resultante la
escribiremos a continuacion por si se quiere analizar.
/*
* Funcion que alinea un vector de tam componentes otantes a una
* frontera de 128 para evitar un bus error al enviarlo del EE a la VU
*/
oat * alineaF128 (int tam)
{
oat * tmp;
int d;
tmp = (oat *) malloc(sizeof (oat)*(tam+4));
fprintf (stderr, "reservado de %p a %p -->", tmp, tmp+(tam+3));
d = (0x10 ((int)tmp & 0x0F))/sizeof (oat);
if (d < 4)
tmp += d;
fprintf(stderr, " %p\n", tmp);
92 CAP
ITULO 4. OPTIMIZACI

return tmp;
}
4.2. Secciones de codigo a optimizar
Haciendo uso de las herramientas de las que disponemos para hacer analisis de
recursos y uso de procesamiento de nuestro programa, operacion tambien conocida
como ((proling)). El programa principal en el MIPS esta formado por una serie de
tareas secuenciales, que son:
1. Decodicacion de una trama ogg vorbis en PCM.
2. Mandar el PCM al sintetizador de audio para reproducir el sonido.
3. Deshacer el entrelazado de los canales para realizar la FFT.
4. Calcular la FFT de la se nal.
5. Procesar las frecuencias en conjuntos de frecuencias.
6. Calcular la existencia o no de un golpe de cadencia.
7. Convertir los conjuntos de frecuencias en un valor de altura para la barra a dibujar,
ponderando con un historico.
Realizando un estudio del ((peso)) de cada tarea en la ocupacion nal del procesador
mediante la utilidad top, determinamos que las tareas mas pesadas computacionalmen-
te conforman la decodicacion a PCM, el calculo de la FFT, el proceso de frecuencias
en conjuntos de frecuencias y la conversion de conjuntos de frecuencias a altura.
Ahora debemos seleccionar tareas para migrarlas a la unidad vectorial VU0, de
manera que su implementacion se adapte a las propiedades de computo que provee
dicha unidad. Recordemos que, en general, toda la arquitectura de computo especca
de la PlayStation2 esta dise nada para operar con vectores de cuatro elementos, repre-
sentacion de un punto en un espacio tridimensional. Nuestro programa no posee ese
tipo de datos, sino que maneja un tipo de dato completamente escalar, por lo que
debemos convertir nuestro tipo de dato escalar en vectorial para procesarlo.
Como dijimos antes, la decodicacion de la trama ogg vorbis es una de las prin-
cipales cargas del sistema, aunque no hay que entender que sea muy pesada con este
comentario. En realidad, aproximadamente cada una de las cuatro tareas que hemos
nombrado son practicamente similares en cuanto ocupacion, rondando en torno al 20 %
cada una. Sin embargo, esta tarea de decodicacion de ogg vorbis s representa una
caracterstica especial que no presentan ninguno de los tres restantes procesos: su es-
tructura es completamente distinta a la requerida para la VU0. Aunque ninguna cumpla
el requisito de cuadrupla en el espacio 3D, la decodicacion no cumple siquiera un ujo
de operaciones similares sobre una secuencia de datos de entrada. Por tanto, no es
un proceso deseable para migrar a la unidad vectorial VU0, ya que no sigue un ujo
facilmente trasportable a la unidad vectorial, lo que implica una integridad en la VU0
bastante limitada, lo que supone una optimizacion muy baja, en caso de producirse.
El calculo de la FFT por contra, s sigue una estructura de operacion amoldable
al calculo de las unidades vectoriales. Mantiene para una serie de datos las mismas
operaciones, y va almacenando el resultado. Podra visualizarse como un procedimiento
4.2. SECCIONES DE C
ODIGO A OPTIMIZAR 93
SIMD (una instruccion, m ultiples datos) sobre un conjunto de valores de entrada, la
PCM en este caso concreto. Es un proceso con una proyeccion hacia la VU0 valida.
El calculo de los conjuntos de frecuencias se basa en realizar un peque no n umero de
operaciones de gran complejidad computacional sobre cada uno de los valores obtenidos
por la FFT. Tambien presenta una clara estructura SIMD, y su proyeccion en la VU0
es bastante inmediata. El procesamiento de los conjuntos de frecuencias realiza una
serie de operaciones ponderadas con un historico para cada conjunto. Es claramente
un proceso SIMD.
El algoritmo que empleamos en la FFT se supone optimizado para una arquitec-
tura general, ya que como hemos comentado, esta extrado de una aplicacion real, y
se requiere una velocidad de computo aceptable para no generar cuellos de botella en
el funcionamiento de dicha aplicacion. Por contra, nuestros algoritmos de clasicacion
en conjuntos de frecuencias y procesamiento de los conjuntos de frecuencias no han
sido optimizados ni si quiera para una arquitectura generica, y presentan al menos la
misma complejidad computacional que el calculo de la FFT optimizado, convirtiendose
ambos procesos en una de las principales ocupaciones de la CPU. Por tanto, aunque
optimizar la FFT supondra una mejora notable, optimizar uno cualquiera de los otros
dos procesos supondra la misma mejora como mnimo, ya que la complejidad computa-
cional es semejante, y hay que tener en cuenta que el codigo de los mismos ni siquiera
esta optimizado, por lo que se hara una doble mejora. Tambien repercute el hecho
de que la implementacion de la FFT es mas compleja y posee un cauce menos lineal
que paralelizar, ya que requiere de inversion de bits y distintas conversiones internas
para funcionar. Sin embargo, el otro par de procesos no requieren procesamientos in-
ternos aparte del computacional, simplicando el ujo de operacion a un simple ujo
de computo, sin ramicaciones condicionales o incondicionales siquiera.
4.2.1. Procesamiento de frecuencias a conjuntos de frecuencias
El codigo original de procesamiento posterior a la FFT es uno de los cuellos de
botella que presenta nuestra aplicacion en el procesador MIPS. El calculo que se realiza
es, para cada uno de los valores de salida que proporciona la FFT en cada canal, calcular
la banda de frecuencia , e incrementar el conjunto de frecuencia
en uno. Siendo
OUT SIZE la longitud del vector de salida de la FFT mas uno, N BAR el n umero de
conjuntos de frecuencia disponibles, 1024 el valor umbral hasta el que recogeremos
las frecuencias en bandas de frecuencias, y siendo barras el vector que representa los
conjuntos de frecuencia, podemos escribir el algoritmo como sigue:
for (i=0; i<OUT SIZE1; i++)
{
//dest[0][i] = ((int)sqrt(tmp out[0][i+1]))>>8;
//d = (int) (((dest[0][i])/1024.0)*N BAR);
// === (1/(2^8)/1024)*N BAR = (1/(2^8)/1024)*64 = 0.00024414
d = (int)(sqrt(tmp out[0][i+1])*0.00024414);
barras[0][d]++;
d = (int)(sqrt(tmp out[1][i+1])*0.00024414);
barras[1][d]++;
}
Como podemos observar, simplicamos todos los computos de escalado en una
constante para evitar operaciones innecesarias. Nos queda para cada canal un producto
94 CAP
ITULO 4. OPTIMIZACI

y una raz cuadrada. El problema reside principalmente en la raz cuadrada. El procesa-
dor MIPS no dispone de raz cuadrada como instruccion, ya que su unidad aritmetica
se limita a operaciones con n umeros enteros. Para ello se a nadio la FPU, encargada de
realizar todos los computos con aritmeticas otantes. Por tanto, aunque nos reramos
constantemente al MIPS, debemos tener en cuenta que la carga esta repartida entre el
procesador MIPS y la FPU a la hora de realizar las operaciones de computo que, como
sabemos, son practicamente en su totalidad con n umeros otantes.
La raz cuadrada como instruccion la proporciona el coprocesador matematico
COP1, o bien la unidad vectorial VU0. Hemos comprobado que la velocidad del COP1
(la FPU del MIPS) no es suciente para realizar todo el n umero de operaciones que
debe completar en un tiempo determinado. Debido a la mayor velocidad y capacidad de
computo de la unidad vectorial, as como las mayores ventajas de procesamiento elabo-
rado y paralelo que supone poder operar de cuatro en cuatro valores simultaneamente,
optamos sin dudarlo por una implementacion ntegra en la VU0 del procedimiento. La
instruccion VSQRT calcula la raz cuadrada de un n umero otante en 7 ciclos, en
contraposicion de los 31 ciclos que tarda el COP1. Como la unidad vectorial nos
permite realizar operaciones de cuatro en cuatro valores (no es el caso de la division ni
de la raz cuadrada), calcularemos el post procesamiento de cuatro valores por iteracion,
lo que supone reducir en una cuarta parte el n umero de iteraciones, con la ganancia
de ciclos inherentes a los posibles fallos de prediccion de saltos. Calcularemos los
dos canales tambien, para evitar tener que cargar la constante dos veces, minimizando
la latencia asociada a la transferencia. La mecanica que seguiremos sera calcular las
cuatro races cuadradas primero de forma secuencial, debido unicamente a la impo-
sibilidad de realizarlas en paralelo, ya que es una de las pocas operaciones que solo
operan con un valor de forma simultanea. Tras obtener el resultado de las cuatro races
cuadradas, las juntaremos en un registro, y luego multiplicaremos el registro resultado
por la constante.
asm volatile ("
lqc2 vf1, 0x00( %4) # carga 0.00024414
lqc2 vf2, 0x00( %5) # carga vector 0
# entrada 1
lqc2 vf5, 0x00( %2) # carga entrada1
vsqrt Q, vf5x # sqrt
vwaitq
vaddq.x vf6x, vf2x, Q
vsqrt Q, vf5y # sqrt
vwaitq
vaddq.y vf6y, vf2y, Q
vsqrt Q, vf5z # sqrt
vwaitq
vaddq.z vf6z, vf2z, Q
vsqrt Q, vf5w # sqrt
vwaitq
vaddq.w vf6w, vf2w, Q
vmul vf6, vf6, vf1 # resultados * 0.00024414
sqc2 vf6, 0x00( %0) # graba
# entrada 2
lqc2 vf4, 0x00( %3) # carga entrada1
vsqrt Q, vf4x # sqrt
vwaitq
vaddq.x vf7x, vf2x, Q
vsqrt Q, vf4y # sqrt
vwaitq
vaddq.y vf7y, vf2y, Q
vsqrt Q, vf4z # sqrt
4.2. SECCIONES DE C
ODIGO A OPTIMIZAR 95
vwaitq
vaddq.z vf7z, vf2z, Q
vsqrt Q, vf4w # sqrt
vwaitq
vaddq.w vf7w, vf2w, Q
vmul vf7, vf7, vf1 # resultados * 0.00024414
sqc2 vf7, 0x00( %1) # graba
" : :
"r" (salidaASM),
"r" (salida2ASM),
"r" (entradaASM),
"r" (entrada2ASM),
"r" (alfaASM),
"r" (c00ASM));
La Figura 4.1 muestra el ujo de datos y operaciones que realiza cada una de las
implementaciones a lo largo del tiempo, as como el n umero de veces que debe realizarla.
Aunque puede que a simple vista no se perciba, hay que recordar que la instruccion de
la raz cuadrada en la VU0 es mucho mas rapida que la del MIPS, ademas de que, como
se indica, la multiplicacion opera cuatro n umeros al mismo tiempo. Es una lastima que
la instruccion de calculo de la raz cuadrada solo pueda operar con un valor de
entrada a la vez, lo que hace necesaria la secuencializacion del calculo de las races,
como se comprueba en el diagrama del ujo.
Figura 4.1: Flujo de datos que sigue la implementacion del clasicador de frecuencias
en conjuntos de frecuencias: (a) en el MIPS, (b) el ujo de datos perteneciente a la
implementacion en la VU0.
96 CAP
ITULO 4. OPTIMIZACI

4.2.2. Procesamiento de los conjuntos de frecuencias
Otra parte del codigo que requiere gran procesamiento de calculo conforma la
parte que procesa los conjuntos de frecuencia y los convierte en un valor directamente
procesable por el algoritmo de dibujar barras implementado ya en el VU1. No es mas
que la interpolacion entre el valor actual calculado y el valor anterior, para realizar una
transici on suave entre ambos y evitar posibles parpadeos al cambiar el dibujo de la
barra de forma muy brusca. Tras calcular el valor actual, se satura el valor a un lmite
maximo, que situaremos seg un la altura maxima posible que queramos darle a la barra.
La saturacion es necesaria para asegurarnos unos lmites en cuanto a valores que recibe
el procedimiento de dibujar la barra, ya que al situar los vertices fuera del area de
dibujo puede provocar errores en la visualizacion. Esta operacion la calcularemos una
vez por canal, para cada una de las barras a mostrar. El codigo en C que conforman
estas operaciones se muestra a continuacion:
// sin usar la VU0
Mis barras1[j1]=ytamH[0][j]= ytamH[0][j]*0.9
+ barras[0][j]*alfa;
if (Mis barras1[j1] < LIMITE)
Mis barras1[j1] = LIMITE;
Mis barras2[j1]=ytamH[1][j]= ytamH[1][j]*0.9
+ barras[1][j]*alfa2;
if (Mis barras2[j1] > LIMITE)
Mis barras2[j1] = LIMITE;
Como hemos comentado, realizamos una interpolacion entre el valor anterior y
el presente, cada uno de ellos ponderados por una constante. Las unidades vectoriales
disponen de una instruccion de producto y suma a la vez, que emplearemos para realizar
el segundo producto y la interpolacion en un paso. La saturacion con el lmite la haremos
empleando las instrucciones de maximo y mnimo que ofrecen, que permiten rellenar
un registro con el valor maximo de dos registros, campo a campo. A continuacion
pondremos el procedimiento para el canal derecho. El canal izquierdo es identico salvo
el uso de la instruccion vmin en lugar de vmax para la cota de lmite.
asm volatile ("
lqc2 vf1, 0x00( %3) # carga 0.9
lqc2 vf2, 0x00( %4) # carga alfa
lqc2 vf3, 0x00( %5) # tope
lqc2 vf5, 0x00( %2) # carga barras
vmula.xyzw ACC, vf5, vf2 # barras*alfa
lqc2 vf4, 0x00( %1) # carga ytamH
vmadd.xyzw vf6, vf4, vf1 # ytamH*0.9 + barras*alfa
vmax vf6, vf6, vf3 # max (actual, tope)
sqc2 vf6, 0x00( %0)
" : :
"r" (salidaASM),
"r" (ytamASM),
"r" (entradaASM),
"r" (c90ASM),
"r" (alfaASM),
"r" (topeASM));
4.3. AN
ALISIS DE LA GANANCIA OBTENIDA 97

Como se aprecia en la Figura 4.2, se consigue un ujo mas paralelo de ejecu-
cion, ya que operamos de cuatro en cuatro valores, y conseguimos ademas reducir
una operacion gracias a la ya mencionada operacion de producto-suma que ofrece la
unidad vectorial. Esto nos permite trabajar de cuatro en cuatro valores, y hacer un
n umero menor operaciones ademas. Gracias a la compatibilidad para cuatro operandos
simultaneos de las instrucciones de maximo y mnimo, podemos realizar la saturacion
para los cuatro valores calculados simultaneamente, evitando la comprobacion valor
por valor. Al contrario de lo que ocurra en el procedimiento analizado en la seccion
4.2.1 debido a la operacion de raz cuadrada, en esta ocasion todas las operaciones
que necesitamos realizar soportan cuatro operandos simultaneos sobre los que operar,
no teniendo necesidad de detener el paralelismo de cuatro en cuatro datos en todo el
ujo.
Figura 4.2: Flujo de datos que sigue la implementacion del procesamiento de conjuntos
de frecuencias: (a) en el MIPS, (b) el ujo de datos perteneciente a la implementacion
en la VU0.
4.3. Analisis de la ganancia obtenida
Vamos a intentar calcular la ganancia que hemos obtenido con la optimizacion
realizada. Para ello, vamos a intentar aplicar la Ley de Amdahl, tal como hemos visto
en las asignatura de Arquitectura de los Computadores I [55].
Ley 1 (Amdahl) La mejora obtenida en el rendimiento de un sistema
informatico al utilizar alg un modulo o componente de ejecucion mas rapido
esta limitada por la fraccion de tiempo que se puede utilizar ese modulo o
componente.
Si expresamos la Ley 1 como una formulacion matematica, obtenemos la expresion
(4.1), donde f es la fraccion de codigo que se puede mejorar, y a la aceleracion de la
98 CAP
ITULO 4. OPTIMIZACI

mejora.
Ganancia =
rendimiento con mejora
rendimiento sin mejora
=
T sin mejora
T con mejora
=
1
(1 f) +
f
a
(4.1)
Intentaremos aplicar dicha formulacion para obtener la fraccion de codigo que
hemos paralelizado, y la ganancia maxima teorica. Para ello debemos calcular primero
la aceleracion que produce el uso de la unidad vectorial VU0 en lugar de la FPU.
Dada la ausencia de herramientas de monitorizacion para las unidades vectoriales,
procederemos a realizar una estimacion basada en el tiempo de calculo empleado para
realizar las secciones optimizadas. Dicha estimacion la realizamos en base a la siguiente
suposicion: el tiempo necesario para realizar los calculos sujetos de optimizacion ya
mentados es el mismo esten formando parte del todo de la aplicacion o bien se ejecuten
como procedimientos independientes aislados del mismo.
Para calcular la aceleracion, haremos un programa de diagnostico, que realizara un
n umero considerable de veces los procedimientos sujetos de optimizacion, tanto con
la implementacion para el MIPS+FPU como para la VU0. El n umero de veces que
se repite la operacion de calculo ha de ser sucientemente grande como para poder
considerar que tiende al lmite teorico de su capacidad de procesamiento, intentando
minimizar la sobrecarga de las transiciones de DMA, memorias y fallos en la posible
prediccion de saltos. Se calculara el tiempo de ejecucion de ambas, y se obtendra la
mejora que supone el uso de la VU0 frente al MIPS+FPU.
Captulo 5
Formato Ogg Vorbis
En este captulo detallamos de forma exhaustiva el formato de codicacion vorbis,
as como los pasos necesarios para su decodicacion, y las partes de las que se compone
el formato de chero en el que va encapsulado.
5.1. Introduccion al formato
El formato ogg vorbis puede codicar desde 8kHz a 192kHz, y desde 1 hasta
255 canales digitales, considerando stereo, cuadrafonico y similares, con tasa variable
de bits en la compresion (VBR).
Aqu nos centraremos unicamente en la decodicacion del formato. Para una breve
introduccion a la codicacion de Ogg Vorbis, puede consultarse un resumen [39] sobre
la compresion.
El n ucleo principal de funcionamiento en la reproduccion es la Transformada Dis-
creta Modicada del Coseno (MDCT).
El formato vorbis es tan exible que no provee proteccion de ninguna clase frente
a errores. Los paquetes de datos que conforman el chero no tienen tama no mnimo,
ni maximo ni un tama no esperado. Estan dise nados para poder ser truncados y que su
decodicacion sea posible. La capa de transporte que se encarga de detectar los fallos
es en nuestro caso ogg.
Vorbis puede iniciar la decodicacion de cualquier paquete en cuanto el deco-
dicador haya sido iniciado con las cabeceras de conguracion que especica las pro-
piedades de la onda a producir. Los componentes del decodicador se muestran en la
Figura 5.1.
Figura 5.1: Componentes del decodicador de Ogg Vorbis
99
100 CAP
ITULO 5. FORMATO OGG VORBIS

donde:
mode: consiste en la conguracion del tama no del frame, el tipo de ventana
(siempre 0 en Vorbis I), el tipo de transformada (siempre 0, la MDCT, en
Vorbis I), y el n umero de mapping, que especica la conguracion a usar para
la decodicacion y sntesis de los paquetes de bajo nivel
mapping: contiene una descripcion de los canales y una lista de submapas sobre
canales para la codicacion decodicacion en grupo. Los submapas indican el
oor y el residue apropiado para la decodicacion. Por ejemplo, si es un audio en
formato 5.1, el sexto canal sera solo el bajo, por lo que para este canal se usara un
oor que solo codica bajos, en lugar de emplear uno de rango completo, lo que
sera un gasto innecesario.
floor: uno de los pilares de la decodicacion. Es la representacion a baja reso-
lucion del espectro de audio para el canal dado en el frame actual. Puede ser de
dos tipos:
Floor 0 usa una representacion LSP (Line Spectrum Pair) con amplitud en
decibelios y la frecuencia en la escala Bark (la escala de Bark va desde 1 a 24
Barks, correspondientes a las 24 primeras bandas crticas del odo humano.
La escala se dene en terminos de frecuencia en Hz entre el n umero de
Bark)
Floor 1 representa la curva como una representacion lineal a trozos inter-
polada de la amplitud en decibelios en una escala de frecuencia lineal.
Ambos tipos son semanticamente equivalentes, pero se preere siempre el tipo
1, debido a que es mas estable entre frames y es considerado tambien computa-
cionalmente mas sencillo que el tipo 0.
Los valores codicados/decodicados por un oor se compactan mediante una
codicacion entropica para ahorrar espacio. Una conguracion normalmente se
reere a m ultiples codebooks de la lista. La codicacion entropica es una abs-
traccion, y cada oor puede elegir un codebook cualquiera cuando esta codi-
cando/decodicando.
residue: es el detalle de la onda de audio una vez que se le ha restado el oor.
Se codica usando vectores cuantizados conforme uno de los tres algoritmos
especcos de codicacion/decodicacion, numerados de 0 a 2. Los detalles del
algoritmo de empaquetamiento los especica el residue en concreto. Al igual que
en los oor, la codicacion entropica nal se provee en codebooks externos y
cada residuo se puede elegir de entre todos los codebooks disponibles
codebooks: son abstracciones que realizan la decodicacion entropica y opcional-
mente, se usa el valor entero decodicado comondice en una tabla de vectores de
salida, devolviendo dicho conjunto de valores. El codicador entropico empleado
en el Vorbis I es un arbol binario representado en codigo Human estandar.
5.2. Funcionamiento general del decodicador
5.2.1. Conguracion del decodicador
Lo primero que debemos hacer, es congurar el decodicador, usando para ello las
tramas de cabecera. Vorbis usa tres paquetes de cabecera, necesarios en orden, para
5.2. FUNCIONAMIENTO GENERAL DEL DECODIFICADOR 101
la conguracion. En Vorbis I, todo paquete posterior a estos tres de cabecera, es un
paquete de audio. Los paquetes de cabecera son:
Identification Header: contiene la identicacion de que es una trama vorbis,
la frecuencia de muestreo, y el n umero de canales
Comment Header: contiene la informacion de texto sobre la trama, como es la
informacion sobre el codicador, y los campos asociados a la trama en s, como
puede ser el autor, ttulo, album...
Setup Header: contiene informacion extensiva sobre la conguracion del CO-
DEC, as como los codebooks VQ y Human necesarios para decodicar
5.2.2. Pasos de la decodicacion
Los pasos a seguir en general son:
Decodicacion del tipo de paquete: Vorbis I usa cuatro tipos de paquetes.
Los primeros tres son los descritos antes. El cuarto indica que es de audio. Cual-
quier otro tipo esta reservado, y un paquete con otro tipo debera ser ignorado.
Una vez pasados los tres primeros, el resto deben ser siempre de tipo audio, por
lo que si llega uno de tipo cabecera, sera ignorado ese paquete.
Decodicacion del modo: especica el modo a usar, ya que como hemos dicho
antes, se pueden denir varios modos de decodicacion. Es un entero que se usa
como ndice en la tabla de modos directamente.
Decodicacion de la forma de la ventana (solo ventanlas grandes): el frame
puede ser de uno de los dos tama nos especicados durante la conguracion del
CODEC. En Vorbis I puede ser cualquier potencia de dos entre 64 y 8192. Hay
que tener en cuenta que cada canal se gestiona independiente, y el tama no se
dene por canal.
Vorbis usa la MDCT, que solapa ventanas, para mezclar un frame con el sie-
guiente, evitando la mayora de las anomalas en las fronteras de los bloques. Tal y
como necesita la MDCT, las ventanas se solapan un 50 % con la salida del bloque
anterior. La Figura 5.2 muestra un ejemplo de estos tipos de solapamiento.
Como se puede apreciar, ambas ondas han de ser simetricas respecto al punto de
solapamiento entre los bloques. Para conocer que la siguiente ventana es peque na,
se puede tener el tama no de la ventana anterior, la actual, y la siguiente. Aunque
sera preferible hacer uso de la informacion redundante que utiliza vorbis, ya que
en las ventanas grandes guarda dos bits que especican la forma de la ventana
anterior y siguiente. Esto permite poder decodicar la ventana en ese mismo
punto, sin necesidad de leer el siguiente. Esto permite tambien alcanzar un mayor
grado de paralelismo.
La informacion relativa a la MDCT se puede encontrar en un documento [48] de
la European Signal Processing Conference.
Decodicacion de los residue: aunque el n umero de vectores de residues debe
ser igual que el n umero de canales, el emparejamiento de canales puede hacer
que los vectores de residues obtenidos tras la decodicacion no se correspondan
directamente a los canales especicados. Cuando se emplea emparejamiento de
canales, algunos vectores corresponderan a magnitud o a angulo. La relacion se
102 CAP

Figura 5.2: Tipo de solapamiento entre ventanas consecutivas.
especica en la cabecera de conguracion, y puede cambiar de frame a frame
debido a la posibilidad de eleccion de uno de los modos en cada frame.
La codicacion de los vectores de residues se hace en el orden de los submapas,
desde el 0 hasta el n 1. En los oors en cambio se codica en orden de los
canales de audio.
Deshaciendo el emparejamiento de canales: el emparejamiento se realiza a
parejas de vectores de residuos. El emparejamiento se deshace en el orden y con los
vectores especicados en la conguracion del mapping actual. Es la misma para
todas las parejas, convertir la representacion polar en cartesiana. Tras deshacerlo,
el vector resultante contiene el detalle espectral de cada uno de los canales de
salida.
Generando la curva de oor: se puede generar esta curva en el momento que
el decodicador desee. Puede ser cuando el oor se decodica del paquete, o se
puede generar tras el paso anterior y aplicado directamente al residuo espectral
obtenido, combinando la generacion y el producto escalar en un unico paso.
Tanto el oor de tipo 0 como el de tipo 1 generan un vector de salida de ran-
go lineal/dominio lineal que ha de ser multiplicado escalarmente con el residuo
espectral de rango lineal/dominio espectral.
Calculando el producto escalar oor/residue: este paso es bastante abierto.
Para cada canal de salida, el decodicador multiplica ambos vectores elemento
a elemento, produciendo el espectro de audio nal de cada canal.
Un error com un es considerar que una representacion de punto jo de 32 bits es
suciente para el oor y el residue, y que el producto directo sera suciente para
una resolucion aceptable de espectro porque funciona casi siempre con cheros
generados por el codicador de Xiph.
Los oors pueden ser de 140dB ( 24 bits), y el espectro de audio debe re-
presentar un mnimo de 120dB( 21 bits con signo), incluso cuando la salida es
5.3. CONFIGURACI
ON DEL CODEC Y DECODIFICACI
ON DEL PAQUETE 103

de 16 bits. Para los residuos deben poder variar entre 0 y 140dB si el oor vale
140dB para alcanzar la escala completa, y entre 140 y 0dB si el oor vale
140dB. Por tanto, los residuos deben oscilar entre 140 y 140dB si queremos
ser capaces de alcanzar siempre la escala completa. Un rango de 280dB es apro-
ximadamente 48 bits con signo. Por tanto, el producto escalar entre el oor y
el residue sera un producto de 24 48 bits, por lo que se usara un tipo de dato
de al menos 64 bits o una representacion de coma otante.
Transformada inversa del espectro: debemos aplicar una conversion para de-
volver la se nal espectral obtenida en una se nal de dominio temporal nuevamente,
es decir, un audio PCM (Pulse Code Modulation, modulaci on por codicacion
de pulsos). Para ello se emplea la inversa de la transformada discreta modicada
del coseno presentada en el documento [48] mencionado con anterioridad.
Hay que tener en cuenta que la PCM resultante no es la se nal nal a un, ya que
falta solaparla con los frames de su alrededor empleando la ventana adecuada
antes de que la MDCT pueda ser considerada ortogonal.
Superposicion/adicion de los datos: la salida del paso anterior se solapa y se
a nade con la parte derecha de la ventana anterior, de forma que el punto
3
4
de
la ventana anterior este alineado con el punto
1
4
de la ventana actual, seg un se
ve en el dibujo. En ese momento, los datos situados entre las partes centrales de
ambos frames es la onda PCM denitiva que ha de ser devuelta. En la Figura ??
se puede apreciar la parte que se solapa.
Cache del frame actual: el decodicador debe almacenar la parte derecha del
frame actual para solaparlo con el siguiente frame, tal como se ha explicado en
el paso anterior.
Devolviendo el audio nal: como hemos dicho, la parte de audio decodicada
por completo es la parte contenida entre los centros de las ventanas solapadas.
Si ambas eran de igual tama no, se devuelve medio bloque. Si son de distinto
tama no, no todo lo que se devuelve es parte solapada. La cantidad devuelta
ha de ser siempre
window blocksize(previous window)
4
+
window blocksize(current window)
4
desde el centro de la ventana anterior hasta el centro de la ventana actual.
No se devuelve nada del primer frame, ya que se usa para iniciar el decodicador.
Despues del frame inicial, el oset del PCM es 0, ya que a un no se ha enviado
ning un dato.
5.3. Conguracion del codec y decodicacion del pa-
quete
5.3.1. Introduccion
Este documento es una gua para la decodicacion bit a bit del formato Vorbis I.
Se asume un conocimiento general del funcionamiento del formato Ogg Vorbis I.
5.3.2. Decodicacion de la cabecera y conguracion del decodi-
cador
Una trama Vorbis comienza con tres paquetes de cabecera: cabecera de identi-
cacion, cabecera de comentarios y cabecera de conguracion. Se necesitan las tres
104 CAP

para decodicar seg un lo acordado. Una condicion de n-de-paquete durante la deco-
dicaci on del primer o tercer paquete de cabecera hace la trama indecodicable. En la
decodicacion de la cabecera de comentarios produce un error no fatal.
Decodicacion com un de las cabeceras
Cada paquete de cabecera comienza con los mismos campos:
1. [packet type] uint8
2. la secuencia 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73 (los caracteres v, o,
r, b, i, s)
La decodicacion contin ua seg un el tipo de paquete. La cabecera de identicacion
es el tipo 1, la de comentarios es la tipo 3 y la de conguracion es la tipo 5 (todos son
impares porque los paquetes con el bit a 0 son los paquetes de audio). Los paquetes
de cabecera deben llegar en el orden: identicacion, comentario y conguraci on.
Cabecera de identicacion
La cabecera de identicacion es una cabecera corta de pocos campos empleados
para determinar que la trama es denitivamente un Vorbis, y proporcionar informacion
externa relevante sobre la trama de audio. Esta cabecera se decodica:
1. [vorbis version] uint32
2. [audio channels] uint8
3. [audio sample rate] uint32
4. [bitrate maximum] int32
5. [bitrate nominal] int32
6. [bitrate lower int32
7. [blocksize 0] 2
uint4
8. [blocksize 1] 2
uint4
9. [framing flag] 1 bit
[vorbis version] debe ser 0 para ser compatible con este documento. Tanto
el campo [audio channels] como el campo [audio rate] tienen que ser mayores
de cero. Los valores nales permitidos para los blocksize son 64, 128, 256, 512, 1024,
2048, 4096 y 8192 en Vorbis I. Hay que tener en cuenta que [blocksize 0 tiene
que ser menor o igual que [blocksize 1]. El bit de [framing flag] tiene que ser
distinto de cero. Si no se cumple alguna de estas condiciones, el resultado es una trama
indecodicable.
Los campos de bitrate se usan solo como guas. El campo [nominal bitrate]
especialmente se puede considerar in util en ujos VBR (variable bit rate). Los campos
son de interes cuando son mayores de de cero.
Si los tres campos estan al mismo valor, indica que o bien es una tasa constante
de bits por segundo, o bien los lmites estan muy proximos a una de tasa ja,
teniendo poco margen de detalle
5.3. CONFIGURACI
ON DEL PAQUETE 105

Valores superiores o inferiores implican una trama VBR que obedece la limitacion
establecida
Si no se ha asignado ning un valor indica que el codicador no se molesto en
especular
Cabecera de comentarios
Es la encargada de proporcionar la informacion sobre la trama codicada en Vorbis.
Campos como el autor, compositor, estilo de m usica, ttulo de la cancion van en esta
cabecera. Los detalles de decodicacion de esta cabecera van reejados en otra seccion,
separada de esta, pues no es relevante para decodicar el sonido de la trama.
Cabecera de conguracion
EL codec de Vorbis es congurable en extremo: La cabecera de conguracion
contiene la informacion crucial de la conguracion del codec, necesaria para la de-
codicacion. Contiene, en orden, las listas de las conguraciones de codebook, las
conguraciones de la transformada tiempo-dominio, las conguraciones de los oor,
conguraciones de los residuos, conguracion del mapeado de canales y de la con-
guracion de los modos. Finaliza con un bit de frame a 1. La Decodicacion de la
cabecera procede de la siguiente forma:
Codebooks El proceso de conguracion relativa a los codebooks es el mostrado a
continuacion:
1. [vorbis codebook count] uint8 +1
2. Decodicar [vorbis codebook count] codebooks en orden tal y como se des-
cribe en la seccion de codebooks. Grabar la conguracion de cada uno en orden,
en un vector de conguraciones [vorbis codebook configurations].
Transformacion tiempo-dominio Estan de relleno en Vorbis I. No obstante, los
valores deben leerse para mantener el sincronismo de la trama.
1. [vorbis time count] uint6 +1
2. leer [vorbis time count] valores de 16 bits, que deben ser cero. Si alguno no
es cero, es una condicion de error y la trama es indecodicable.
Floors Vorbis usa dos tipos de oors; la decodicacion de la cabecera esta constituda
de forma que es capaz de decodicar seg un el tipo apropiado.
1. [vorbis floor count] uint6 +1
2. para cada uno de los [vorbis floor count] oor:
a) lee el tipo del oor
b) [vorbis floor types]
[i]
uint16
c) si (tipo = 0) decodica la conguracion del oor seg un el tipo 0 y graba
la conguracion en [vorbis floor configurations]
[i]
si no, si (tipo = 1) decodica la conguracion del oor seg un el tipo 1
y graba la conguracion en [vorbis floor configurations]
[i]
si no, (tipo > 1) la trama es indecodicable: CONDICI
ON DE ERROR
106 CAP

Residuos Vorbis usa tres tipos de residuos; la decodicacion de sus cabeceras es
identica.
1. [vorbis residue count] uint6 +1
2. para cada uno de los [vorbis residue count] residuos:
a) lee el tipo de residuo
b) [vorbis residue types]
[i]
uint16
c) si (tipo = 0, 1, o 2) decodica la conguracion de residuos seg un el
tipo, y grabala en [vorbis residue configurations]
[i]
si no, (tipo > 2) la trama es indecodicable: CONDICI
ON DE ERROR
Mapeado Los mapeados se usan para congurar pipelines especcos para la codi-
cacion multicanal de audio con varias aplicaciones de mapeado de canal. Vorbis I usa
un tipo unico de mapeado, con los mapeados de canales PCM implcitos.
1. [vorbis mapping count] uint6 +1
2. para cada [i] de los [vorbis mapping count] mapeados:
leer el tipo: un uint16 (no hay razon para almacenarlo)
si (tipo ,= 0) trama indecodicable
si no, (tipo = 0)
a) bandera booleana 1 bit
b) si esta activa [vorbis mapping submaps] uint4 +1
si no esta activa [vorbis mapping submaps] 1
c) bandera booleana 1 bit
d) si esta activa se usa mapeado de canales por polos cuadrados:
[vorbis mapping coupling steps] uint8 +1
para cada [j] de los [vorbis mapping coupling steps] pasos:
1) [vorbis mapping magnitude]
[j]
lee ilog([audio channels])
bits como entero sin signo
2) [vorbis mapping angle]
[j]
lee ilog([audio channels])
bits como entero sin signo
3) los pasos anteriores indican el canal que representara la mag-
nitud y el canal que representara el angulo, respectivamente.
Si ambos son iguales o el de magnitud o angulo es mayor que
[audio channels]1, la trama es indecodicable
e) lee 2 bits; si es distinto de cero, la trama es indecodicable
f ) si ([vorbis mapping submaps] > 1) para cada [j] de los
[audio channels] canales:
1) [vorbis mapping mux]
[j]
uint4
2) si ([vorbis mapping mux]
[j]
> max(submap)) condicion de
error: trama indecodicable
g) para cada submapa [j] de los [vorbis mapping submaps], lee el
n umero de oor y residuos a usar para decodicarlo:
lee y descarta 8 bits (la conguracion tiempo-dominio no usada)
5.3. CONFIGURACI
ON DEL PAQUETE 107

[vorbis mapping submap floor]
[j]
uint8
verica que el n umero de oor no es mayor que el maximo de los
congurados para la trama. Si lo es, la trama es indecodicable.
[vorbis mapping submap residue]
[j]
uint8
verica que el n umero de residuo no es mayor que el maximo de
los congurados para la trama. Si lo es, la trama es indecodicable
h) [vorbis mapping configurations]
[i]
esta conguracion de ma-
peado
Modos
1. [vorbis mode count] uint6 +1
2. para cada uno de los [vorbis mode count] modos:
a) [vorbis mode blockflag] 1 bit
b) [vorbis mode windowtype] uint16
c) [vorbis mode transformtype] uint16
d) [vorbis mode mapping] uint8
e) comprobar rangos: [vorbis mode windowtype] y [vorbis mode transformtype]
han de valer 0. [vorbis mode mapping] no debe ser mayor que el maxi-
mo de los mapping en uso. Cualquier valor ilegal convierte a la trama en
indecodicable.
f ) [vorbis mode configurations]
[i]
esta conguracion
3. lee 1 bit como bandera de frame.
4. Si (bandera no activa) error en el frame, trama indecodicable
Trase leer las descripciones de los modos, la decodicacion de la cabecera de
conguracion se ha completado.
5.3.3. Decodicacion y sntesis de paquetes de audio
Tras los tres paquetes de cabecera, todos los paquetes de una trama Vorbis I son
de audio. Lo primero que hay que hacer con un paquete de audio es comprobar que
sea del tipo de audio; un paquete de un tipo distinto de audio cuando se espera un
paquete de audio es signo de corrupcion de trama o de una trama que no sigue las
especicaciones. El decodicador debe ignorar el paquete y no intentar decodicarlo a
audio.
Decodicacion del tipo de paquete, modo y ventana
1. [packet type] 1 bit; comprobar que sea 0 (audio)
2. [mode number] ilog([vorbis mode count]-1)
3. si ([vorbis mode blockflag] no activa) [n] [blocksize 0]
si no, ([vorbis mode blockflag] activa) [n] [blocksize 1]
4. seleccion y conguracion de ventana esta se usara luego en la MDCT inversa:
108 CAP

a) si ([vorbis mode blockflag] activa) ventana larga
1) [previous window flag] 1 bit
2) [next window flag] 1 bit
3) si ([previous window flag] no activa) la mitad izquierda de la
ventana es una mezcla de ventana larga y corta
si no, ([previous window flag] activa) la mitad izquierda de la
ventana es de tama no normal
4) si ([next window flag] no activa) la mitad derecha de la ventana
es una mezcla de ventana larga y corta
si no, ([next window flag] activa) la mitad derecha de la ventana
es de tama no normal
si no, ([vorbis mode blockflag] no activa) ventana corta la
ventana solapada siempre sera corta
Las ventanas de Vorbis usasn siempre la misma curva envolvente y = sin(2sin
2
(
x
n
)),
pero un solapamiento de ventanas de distintos tama nos pueden afectar a la forma nal
de la curva. La generacion de la ventana es como se indica a continuacion:
1. [window center] [n]/2
2. [left window start]
3. si ([vorbis mode blockflag] activa [previous window flag] no activa)
a) [left window start] [n]/4 [blocksize 0]/4

b) [left window end] [n]/4 + [blocksize 0]/4
c) [left n] [blocksize 0]/2
si no
a) [left window start] 0
b) [left window end] [window center]
c) [left n] [n]/2
4. si ([vorbis mode blockflag] activa [next window flag] no activa)
a) [right window start] [n]*3/4 [blocksize 0]/4
b) [right window end] [n]*3/4 + [blocksize 0]/4
c) [right n] [blocksize 0]/2
si no
a) [right window start] [window center]
b) [right window end] [n]
c) [right n] [n]/2
5. ventana
0...[left window start]1
0
6. para [i] en el intervalo [left window start]. . .[left window end]-1
ventana
[i]
sin(2sin
2
(
[i][left window start]+0,5
[left n]
2
))
5.3. CONFIGURACI
ON DEL PAQUETE 109

7. ventana
[left window end]...[right window start]1
1
8. para [i] en el intervalo [right window start]. . .[right window end]-1
ventana
[i]
sin(2sin
2
(
[i][right window start]+0,5
[right n]
2
+

2
))
9. ventana
[right window start]...[n]1
0
Una condicion de n-de-paquete hasta este momento debera ser considerado un
error y descartar el paquete entero de la trama. Si ocurre pasado este punto, se puede
considerar un hecho posible.
Decodicacion del oor
Asumimos desde ahora que la decodicacion usa el modo [mode number] del vec-
tor de conguracion [vorbis mode configurations] y el mapeado [vorbis mode mapping]
tomado del vector de conguraciones de mapeado [vorbis mapping configurations].
Las curvas oor se decodican una por una, en el orden de los canales.
para cada oor [i] de [vorbis mapping mux]
1. [submap number] [vorbis mapping mux]
[i]
2. [floor number] [vorbis submap floor]
[submap number]
3. si ([vorbis floor types]
[floor number]
= 0) decodica el oor para el
canal [i] seg un el algoritmo del oor 0
si no, si ([vorbis floor types]
[floor number]
= 1) decodica el oor
para el canal [i] seg un el algoritmo del oor 1
4. guarda la informacion decodicada del canal para la sntesis posterior
5. si (oor decodicado = no usado) [no residue]
[i]
verdad
si no, (oor decodicado ,= no usado) [no residue]
[i]
falso
Una condicion de n-de-paquete durante la decodicacion debera resultar en una deco-
dicacion de todo ceros en los canales de salida, y saltando la fase de suma/solapamiento.
Propagacion de los vectores no nulos
Un resultado posible de la decodicacion del oor es que un vector especco
este marcado como no usado, lo que indica que ese vector nal sera un vector lleno
de ceros (lo que implica un oor de cero). El vector de residuos de ese vector no
esta codicado en la trama, evitando una complicacion. Si algunos vectores se usan y
otros no, el emparejamiento de canales puede producir una mezcla de un vector nulo y
otro no nulo para producir dos vectores no nulos.
para cada [i] en el intervalo 0 . . .[vorbis mapping coupling steps]1
1. si (([no residue] de [vorbis mapping magnitude]
[i]
|
[no residue] de [vorbis mapping angle]
[i]
) = falso) ambos tienen
que ponerse a falso
110 CAP

Decodicador de residuos
A diferencia de los oors, que se decodican seg un el orden del canal, los residuos
se decodican en orden de submapas.
para cada [i] en orden en el intervalo 0 . . .[vorbis mapping submaps]-1
1. [ch] 0
2. para cada [j] en orden en el intervalo 0 . . .[audio channels]
si ([vorbis mapping mux]
[j]
= [i])
si ([no residue]
[j]
= cierto)
[do not decode flag]
[channels in bundle]
activo
si no, ([no residue]
[j]
= falso)
[do not decode flag]
[channels in bundle]
no activo
[ch]++
3. [residue number] [vorbis mapping submap residue]
[i]
4. [residue type] [vorbis residues types]
[residue number]
5. decodicar los [ch] vectores usando el residuo [residue number], seg un
el tipo [residue type], pasando tambien el vector [do not decode flag]
para indicar que vectores no deben ser decodicados. La longitud decodi-
cada correcta por vector es [n]/2
6. [ch] 0
7. para cada canal [j] en orden en el intervalo 0 . . .[audio channels]
si ([vorbis mapping mux]
[j]
= [i])
a) el vector de residuos para el canal [j] se iguala al vector de residuos
decodicados [ch]
b) [ch]++
Emparejamiento inverso
para cada [i] en el intervalo [vorbis mapping coupling steps]-1. . . 0
1. [magnitude vector] [vorbis mapping magnitude]
[i]
2. [angle vector] [vorbis mapping angle]
[i]
3. para cada valor [M] de [magnitude vector] y el correspondiente valor
[A] de [angle vector]
si ([M] > 0)
si ([A] > 0)
a) [new M] [M]
b) [new A] [M]-[A]
si no, ([A] ,> 0)
a) [new A] [M]
b) [new M] [M]+[A]
si no, ([M] > 0)
si ([A] > 0)
a) [new M] [M]
5.3. CONFIGURACI
ON DEL PAQUETE 111

b) [new A] [M]+[A]
si no, ([A] ,> 0)
a) [new A] [M]
b) [new M] [M]-[A]
4. pon los valores [M] de [magnitude vector] a [new M]
5. pon los valores [A] de [ang vector] a [new A]
Producto escalar
Para cada canal, tenemos que sintetizar la curva oor del oor decodicado, seg un
el tipo de paquete. Hay que tener en cuenta que la longitud del vector para el calculo
del oor es de [n]/2.
Para cada canal, debemos multiplicar cada elemento de la curva de oor por cada
elemento del vector de residuos de dicho canal. El resultado es el producto escalar de
los vectores de oor y residuos de cada canal; los vectores resultantes son los espectros
de longitud [n]/2 de cada canal.
Hay que mentar un aspecto de este producto escalar; un error frecuente en una
implementacion de punto jo es asumir que una representacion de 32 bits de punto
jo para oor y residuos, y la multiplicacion directa de ambos es suciente para un
nivel de detalle del espectro aceptable en todos los casos porque parece funcionar con
el codicador de referencia de Xiph.
MDCT inversa
Convierte nuevamente el vector espectral de cada canal al dominio de tiempo, un
audio PCM, mediante la inversa de la Transformada Discreta Modicada del Coseno
(MDCT). La informacion mas detallada aparece en www.iocon.com/resource/docs/
ps/eusipco_corrected.ps. La ventana usada por la MDCT es la ventana que se
determino anteriormente.
Suma de ventanas solapadas
La salida de la MDCT es solapada y sumada con la parte derecha de la ventana
anterior de forma que el punto 3/4 de la ventana anterior este alineada con el punto
1/4 de la actual (tal y como se ilustro al inicio). La parte solapada obtenida del solapa-
miento del frame anterior y del actual son los datos nalizados que deben ser devueltos
por el decodicador. Estos datos desde el centro de la ventana anterior hasta el cen-
tro de la actual. En caso de tener ventanas del mismo tama no, la cantidad de data a
devolver es de medio bloque, consistente en la parte solapada unicamente. Cuando se
solapa una ventana corta y otra larga, parte de los datos devueltos no estan realmente
solapados, cosa que no supone un da no a la ortogonalidad de la transformacion. Sim-
plemente hay que prestar atencion a la porcion devuelta; la cantidad de datos a devolver
es:
window blocksize(previous window)
4
+
window blocksize(current window)
4
desde el centro de la
ventana anterior (elemento
windowsize
2
), hasta el centro de la ventana actual (elemento
windowzise
2
1 inclusive).
No se devuelve datos del primer frame; se usa para iniciar el motor de decodica-
cion. Tras el primer frame, el desplazamiento de la salida de PCM es 0 (ya que a un no
se han devuelto dato alguno).
112 CAP

Orden de canales de salida
El formato Vorbis I solo especica un tipo de mapeado de canales. En el, el
mapeado de canales esta implcitamente denido como sigue para las aplicaciones
estandar de audio:
un canal: la trama es monofonica
dos canales: la trama es estereo, con orden: izquierdo, derecho
tres canales: la trama es 1d-envolvente, con orden: izquierdo, central, derecho
cuatro canales: la trama es envolvente cuadrafonico, con orden: frontal izquier-
do, frontal derecho, trasero izquierdo, trasero derecho
cinco canales: la trama es envolvente de cinco canales, con orden: frontal iz-
quierdo, frontal central, frontal derecho, trasero izquierdo, trasero derecho
seis canales: la trama es envolvente 5.1, con orden: frontal izquierdo, frontal
central, frontal derecho, trasero izquierdo, trasero derecho, LFE (efectos de baja
frecuencia)
mas de seis canales: la aplicacion dene el uso de cada canal y su orden
Las aplicaciones que usen Vorbis para proposito especco pueden denir el ma-
peado de canales como preeran. Futuros mapeados de canales (como el de tres y
cuatro canales Ambisonicos) haran uso de otro tipo de mapeado distinto del 0.
5.4. Floor 0: conguracion y decodicacion
5.4.1. Introduccion
Este tipo de oor usa una representacion LSP (Line Spectral Pair, tambien co-
nocido como LSF por Line Spectral Frecuency) para codicar una curva envolvente
de espectro de forma precisa como la frecuencia de respuesta del ltro LSP. Es una
representacion equivalente al tradicional ltro de respuesta innita de todos los polos
usada en codicacion lineal predictiva. Se puede convertir de una a otra sin problema.
5.4.2. Formato Floor 0
La conguraicon de este decodicador consiste en un campo de seis enteros y
una lista de codebooks VQ para codicar/decodicar los coecientes del ltro LSP
empleado en cada frame.
Decodicacion de la cabecera
La cabecera dispone de los siguientes campos en el mismo orden que se mostrara a
continuacion, y se indicara si es necesario un procesamiento o condicion adicional.
Los tipos de datos se expresaran con una u si es sin signo (unsigned), seguido del
identicador del tipo de dato (int, float, . . . ), y expresando su longitud en bits a
continuacion. Si es un vector o array se expresara debidamente.
[floor0 order]: uint8
5.4. FLOOR 0: CONFIGURACI
ON Y DECODIFICACI
ON 113
[floor0 rate]: uint16
[floor0 bark map size]: uint16
[floor0 amplitude bits]: uint6
[floor0 amplitude offset]: uint8
[floor0 number of books]: uint4 y a nadir 1 al valor
si [floor0 order], [floor0 rate], [floor0 bark map size], [floor0 amplitude bits],
[floor0 amplitude offset] o [floor0 number of books] son menores de
0, la trama no se puede decodicar
array [floor0 book list]: lista de [floor0 number of books] uint8
Una situacion de n-de-trama en alguno de estos bits convierte a la trama en
indecodicable. Ademas, si alg un elemento del array [floor0 book list] es mayor
que el maximo codebook de esa trama es una condicion de error y hace tambien
indecodicable a la trama.
Decodicacion del paquete
Para generar la curva oor0 de un paquete hay primero que decodicar la amplitud
de la curva y los floor0 order coecientes LSP de la trama, y entonces calcular la
curva oor, que se dene como la respuesta en frecuencia del ltro LSP decodicado.
La decodicacion del paquete se hace de la siguiente forma:
[amplitude]: uint de [floor0 amplitude bits] bits
si ([amplitude] > 0)
1. [coefficients] es vector vaco de 0 elementos
2. [booknumber] leer un uint de ilog ([floor0 number of books])
bits
3. si ([booknumber] > mayor n umero de decodicacion del codebook))
paquete indecodicable
4. [lastval] = 0
5. vector [temp vector] leer vector de la trama usando [booknumber]
como n umero del codebook en el contexto VQ
6. a nade el valor escalar last a cada escalar de vector [temp vector]
7. concatena [temp vector] al nal del vector [coefficients]
8. si (longitud de [coefficients] < [floor0 order]) continuar por el
paso 4
9. n
Ahora veremos algunas propiedades de la decodicacion:
Un valor [amplitude] de 0 hara que se devuelva un codigo indicando que este
canal no se usa en este frame (la salida del canal sera una sucesion de ceros).
Muchas de las etapas siguientes de decodicacion no se realizan para un canal
no usado.
114 CAP

Si se encuentra una condicion de n-de-paquete durante la decodicacion, sim-
plemente se marcara el canal como no usado, al igual que en el caso anterior.
El n umero del book usado para decodicar se podra haber guardado en ujo
de datos en ilog([floor0 number of books]-1) bits, pero la especiccion
anterior es correcta, y los valores mayores que el book maximo posible estan
reservados.
El n umero de elementos ledos en el vector [coefficients] puede ser mayor
que [floor0 order], el valor requerido en realidad para calcular la curva. Por
ejemplo, si el codebook VQ usado para el oor que esta siendo decodicado tiene
un [codebook dimensions] de 3 y [floor0 order] vale 10, la unica forma
de rellenar todos los valores necesarios en [coefficients] es leer un total de
12 valores, como 4 vectores de 3 escalares cada una. No es una condicion de
error, y hay que tener cuidado de no permitir un desbordamiento del buer en la
decodicacion. Los valores extra no se usan y pueden ser ignorados o descartados.
Calculo de la curva
Dada un entero [amplitude] y un vector [coefficients] de la decodica-
cion de un paquete, y [floor0 order], [floor0 rate], [floor0 bark map size],
[floor0 amplitude bits] y [floor0 amplitude offset] de la conguracion del
decodicador, y un vector de salida de tama no [n] especicado en el proceso de de-
codicacion, calcularemos un vector de oors como salida.
Si [amplitude] es cero, devolveremos un vector de [n] elementos con el valor
escalar 0. En caso contrario, supondremos las siguientes deniciones para el vector a
sintetizar:
bark(x) = 13,1atan(,00074x) + 2,24atan(,0000000158x
2
) +,0001x
map
i
= mnimo
for i = 0 . . . [n] 1
_
_
[floor0 bark map size] 1,
_
bark(
[floor0 rate] i
2 [n]
)
[floor0 bark map size]
bark(,5 [floor0 rate])
_
Esto se usa para sintetizar la curva LSP en una escala Bark en el eje de frecuencias,
y luego mapearla en un eje de frecuencias lineal. El trozo siguiente calcula el calculo
de la curva LSP de salida [output] en una escala logartmica (dB) de amplitud.
1. [i] 0
2. si ([coefficients] es impar) calcular [p] y [q] seg un:
p = (1 cos
2
())
[floor0 order]3
2
j=0
4(cos([coefficients]
2j+1
) cos())
2
q = ,25
[floor0 order]2
2
j=0
2j
) cos())
2
ON Y DECODIFICACI
ON 115
3. sino ([coefficients] es par) calcular [p] y [q] seg un:
p =
(1 cos())
2
[floor0 order]2
2
j=0
2j+1
) cos())
2
q =
(1 +cos())
2
[floor0 order]2
2
j=0
2j
) cos())
2
4. calcular [linear floor value] de acuerdo con:
e
[amplitude] floor0 amplitude offset
(2
[floor0 amplitude bits]
1)
2
p +q
5.5. Floor 1: conguracion y decodicacion
5.5.1. Introduccion
Este metodo usa una representacion de funcion a trozos lineales para codicar una
curva envolvente del espectro. La representacion dibuja esta curva de forma mecanica
en un eje lineal de frecuencia y un eje logartmico (en dB) de amplitud. El algoritmo
empleado para representarla es similar al algoritmo de Bresenham.
5.5.2. Formato Floor 1
Modelo
La curva espectral queda representada como una serie de segmentos de lnea. La
sntesis construye una curva oor usando prediccion iterativa en un proceso aproxima-
damente equivalente a la siguente descripcion simplicada:
el primer segmento (caso base) es una lnea completa desde x 0, y 0 hasta x 1,
y 1, donde en el caso base x 0 = 0 y x 1 = [n], el rango completo del oor
espectral a calcular.
el paso de induccion elige un punto x new en un segmento logico existente y
produce una y new en ese punto, para el valor y en x new, y la diferencia deco-
dicada del paquete del ujo de datos.
el calculo del oor produce dos nuevos segmentos de lnea, uno desde (x 0,y 0)
hasta (x new,y new) y otro desde (x new,y new) hasta (x 1,y 1). Este paso
se realiza incluso si y new no supone ning un cambio al valor de la amplitud en
x new, de forma que renamientos posteriores tambien usaran x new como valor
del extremo.
el paso de induccion se repite, usando una lista de valores de x especicada en
la cabecera del codec en la iniciacion del oor 1. El calculo se completa en el
ultimo valor de la lista de valores para x.
116 CAP

Ahora veremos un ejemplo graco para entender con mayor facilidad los puntos
anteriores.
Supongamos una conguracion del oor con [n] = 128. La lista de valores elegidos
de X en orden incremental es 0, 16, 32, 48, 64, 80, 96, 112 y 128. Los valores de los inter-
valos van en el orden siguiente: 0, 128, 64, 32, 96, 16, 48, 80 y 112. Para estos valores, los
valores Y que se han decodicado de un paquete han sido 110, 20, 5, 45, 0, 25, 10, 30
y 10. Hacemos el oor de la siguiente forma, primero empezamos pintando la pri-
mera lnea, y calcularemos el valor de new Y para la primera coordenada X del vector,
teniendo en cuenta el valor de Y que decodicamos del paquete, como se ilustra en la
Figura 5.3
Figura 5.3: Reconstruccion del oor con dos puntos, y calculo de la diferencia en Y
con respecto a la estimacion inicial.
Ahora dibujaremos las nuevas lneas para reejar la correcion de new Y, y repeti-
remos el paso para los valores de X de 32 y 96, como vemos en la Figura 5.4.
Figura 5.4: Realizamos la correccion de la Y anterior y calculamos las nuevas para 32
y 96.
Aunque el valor de new Y para la coordenada 96 no ha cambiado de valor, se
seguira usando como el extremo de los renamientos asociados a esa parte de la curva.
El siguiente paso sera continuar con los subintervalos producidos, ilustrado con la
Figura 5.5.
Se contin ua de la misma forma hasta completar todas las coordenadas del vector
de valores para X, representado en la Figura 5.6:
ON Y DECODIFICACI
ON 117
Figura 5.5: Proseguimos renando la curva con los valores asociados, corrigiendo cuan-
do es necesario.
Se usa un algoritmo mas eciente con un comportamiento de redondeo a entero
cuidadosamente denido para la decodicacion real, como se vera mas adelante. El
algoritmo real parte el calculo de los valores de Y y el trazado de la curva en dos pasos
con modicaciones sobre el algoritmo anterior, para eliminar la acumulacion del error
producido por el redondeo/truncado de enteros.
Figura 5.6: Cuando todos los valores se han calculado, tenemos la reconstruccion de la
curva original.
5.5.3. Decodicacion de la cabecera
En la cabecera del paquete se almacena una lista de los valores X del oor en
formato entre (usado en orden de lista durante la decodicacion del paquete y la
sntesis). Esta lista se parte en dos trozos, cada uno de los cuales se asigna a una clase
de particion. Las posiciones 0 y [n] de X son implcitas y no pertenecen a ninguna
particion explcita o clase de particion.
Una clase de particion consiste en un ancho de representacion del vector (el n umero
de valores Y que la particion codica a la vez), un valor de subclase que representa
el n umero de books entropicos alternativos que puede usar la clase de particion para
representar los valores Y, la lista de [subclass] books y un book principal usado
para codicar que books fueron elegidos para la representacion de un paquete dado. El
mecanismo de principal/sublcase esta pensado para ser usado como una representacion
118 CAP

exible en cascada, mientras se mantiene el uso de los codebooks solo en un contexto
escalar.
Los pasos para obtener la informacion asociada de cabecera del paquete se indican
a continuacion.
1. [floor1 partitions] uint5
2. [maximum class] = 0
3. itera [i] en el intervalo 0 . . . [floor1 partitions] 1
[floor1 partition class list]
[i]
uint4
4. [maximum class] = max([floor1 partition class list])
5. itera [i] en el intervalo 0 . . . [maximum class]
vector [floor1 class dimensions]
[i]
uint3+1
vector [floor1 class subclasses]
[i]
uint2
si ([floor1 class subclasses]
[i]
,= 0)
vector [floor1 class masterbooks]
[i]
uint8
itera [j] en el intervalo 0 . . . 2
[floor1 class subclasses]
[i]
1
array [floor1 subclass books]
[i],[j]
uint8 1
6. [floor1 multiplier] uint2 +1
7. [rangebits] uint4
8. vector [floor1 X list]
[0]
0
9. vector [floor1 X list]
[1]
2
[rangebits]
10. [floor1 values] 1
itera [j] en el intervalo 0 . . . [floor1 class dimensions]
[i]
1
vector [floor1 X list]
([j]+[floor1 values])
leer [rangebits] bits
como entero sin signo
floor1 values] = [floor1 values] + [floor1 class dimensions]
[i]
12. n
Una condicion de n de paquete mientras se esta leyendo en cualquier parte du-
rante la conguracion del oor 1 hace que la trama sea indecodicable. Ademas, la
existencia de un valor del vector [floor1 class masterbooks] o del vector
[floor1 subclass books] superior al ndice maximo del codebook congurado pa-
ra esa trama es una condicion de error que convierte a la trama en indecodicable
tambien.
ON Y DECODIFICACI
ON 119
5.5.4. Decodicacion del paquete
La decodicacion comienza comprobando el ag [nonzero]:
1. [nonzero] 1 bit como booleano
Si [nonzero] no esta activado, indica que este canal no contiene energa de audio
en ese frame. La decodicacion inmediatamente devuelve un estado indicando que esta
curva oor (y por tanto este canal) no se usa en el frame. (Devolver un estado de no
usado es distinto de decodicar un oor en el que todos los puntos estan situados en
la amplitud mnima, que suele ser aproximadamente 140dB).
Suponiendo que [nonzero] esta activado, la decodicacion es:
1. [range] 256, 128, 86, 64
([floor1 multiplier]1)
2. [floor1 Y]
[0]
leer ilog([range]-1) bits como entero sin signo
3. [floor1 Y]
[1]
leer ilog([range]-1) bits como entero sin signo
4. [offset] 2
a) [class] [floor1 partition class]
[i]
b) [cdim] [floor1 partition class]
[class]
c) [cbits] [floor1 class subclasses]
[class]
d) [csub] 2
[cbits]1
e) [cval] 0
f ) si ([cbits] > 0)
[cval] lee del paquete usando el codebook
[floor1 class masterbooks]
[class]
en contexto escalar
g) itera [j] en el intervalo 0 . . . [cdim] 1
[book] [floor1 subclass books]
([class],[cval][csub])
si ([book] ,< 0)
[floor1 Y]
([j]+[offset])
lee del paquete usando el codebook [book]
en contexto escalar
si no, [book] < 0
[floor1 Y]
([j]+[offset])
0
h) [offset] [offset] + [cdim]
6. n
Una condicion n-de-paquete durante la decodicacion de la curva debera ser
considerada una ocurrencia puntual. Si se alcanza un n-de-paquete en alguna de las
operaciones de lectura anteriores, la decodicacion del oor devolvera un estado de no
usada como si el bit [nonzero] no hubiera estado activo al inicio de la decodicacion.
El vector [floor1 Y] contiene los valores de la decodicacion del paquete necesarios
para la sintetizacion de la oor1.
120 CAP

5.5.5. Calculo de la curva
El calculo de la curva se divide de forma logica en dos pasos. El primer paso obtiene
las amplitudes Y nales de la codicacion, usando los valores diferencia tomados del
ujo de datos. El segundo paso traza las lneas de curvas. Aunque los valores con
diferencias de cero se usan en la prediccion iterativa para calcular los valores nales de
Y, estos puntos se saltan de forma condicional durante el calculo nal del paso segundo.
Saltar los valores de diferencia cero permite un ajuste mas preciso de la curva.
Aunque algunos aspectos del algoritmo siguiente pueden parecer optimizaciones
inconsecuentes, se advierte a los implementadores que siguan la especicacion elmen-
te. La no implementacion de un algoritmo estrictamente equivalente puede resultar en
graves errores de decodicacion.
Sntesis de los valores de amplitud
Desenvolver los valores (siempre mayores o iguales a 0) del paquete a valores de
diferencias +/-, y ahora se aplica la prediccion lineal.
1. [range] 256, 128, 86, 64
([floor1 multiplier]1)
2. itera [i] en el intervalo 2 . . . [floor1 values] 1
a) [low neighbor offset] low neighbor([floor1 X list], [i])
b) [high neighbor offset] high neighbor([floor1 X list], [i])
c) [predicted] render point ([floor1 X list]
[low neighbor offset]
,
[floor1 X list]
[high neighbor offset]
,
[floor1 Y]
[low neighbor offset]
,
[floor1 Y]
[high neighbor offset]
,
[floor1 X list]
[i]
)
d) [val] [floor1 Y]
[i]
e) [highroom] [range] [predicted]
f ) [lowroom] [predicted]
g) si ([highroom] < [lowroom])
[room] [highroom] 2
si no, [highroom] ,< [lowroom]
[room] [lowroom] 2
h) si ([val] ,= 0)
[floor1 step2 flag]
[low nieghbor offset]
activada
[floor1 step2 flag]
[high nieghbor offset]
activada
[floor1 step2 flag]
[i]
activada
si ([val] [room])
si ([hiroom] > [lowroom])
[floor1 final Y]
[i]
[val] [lowroom] + [predicted]
si no, ([hiroom] ,> [lowroom])
[floor1 final Y]
[i]
[predicted] ([val] [lowroom]) 1
si no, ([val] < [room])
si ([val] es impar)
ON Y DECODIFICACI
ON 121
[floor1 final Y]
[i]
[predicted] (([val] 1) /
Z
2)
si no, ([val] es par)
[floor1 final Y]
[i]
[predicted] + ([val] /
Z
2)
si no, ([val] = 0)
[floor1 step2 flag]
[i]
no activada
[floor1 final Y]
[i]
[predicted]
3. [floor1 step2 flag]
[0]
activada
4. [floor1 step2 flag]
[1]
activada
5. [floor1 final Y]
[0]
[floor1 Y]
[0]
6. [floor1 final Y]
[1]
[floor1 Y]
[1]
7. n
Sntesis de la curva
La sntesis de la curva devuelve un vector [floor] de longitud [n] (donde
[n] viene dada desde el proceso de decodicacion que llama a la decodicacion del
oor). La sntesis de la curva del oor 1 hace uso de los vectores [floor1 X list],
[floor1 final Y y [floor1 step2 flag], as como de los valores de [floor1 multiplier]
y [floor1 values].
La decodicacion comienza ordenando los elementos de los vectores [floor1 X list],
[floor1 final Y] y [floor1 step2 flag] en tres vectores nuevos, [floor1 X list],
[floor1 final Y] y [floor1 step2 flag] de acuerdo a los valores ordenados de
forma ascendente en [floor1 X list]. Por tanto, ordenamos los valores de [floor1 X list]
y aplicamos la misma permutacion a los elementos de los otros dos vectores, para que
se siga correspondiendo elemento a elemento de forma correcta.
Tras esto, calcular la curva nal es solo un paso:
1. [hx] 0
2. [lx] 0
3. [ly] [floor1 final Y]
[0]
[floor1 multiplier]
4. itera [i] en el intervalo 1 . . . [floor1 values] 1
a) si ([floor1 step2 flag]
activa )
[hy] [floor1 final Y]
[i]
[floor1 multiplier]
[hx] [floor1 X list]
[i]
render line([lx],[hx],[ly],[hy],[floor])
[lx] [hx]
[ly] [hy]
b) si ([hx] < [n])
render line([hx],[hy],[n],[hy],[floor])
c) si ([hx] > [n])
truncar [floor] a [n] elementos
5. para cada elemento [v] del vector [floor], cambiar su
valor por el de [floor1 inverse dB static table]
[v]
6. n
122 CAP

5.6. Conguracion y decodicacion de los residuos
5.6.1. Introduccion
Un vector de residuos representa el grano no del espectro de audio de un canal
en un frame de audio despues de que el codicador elimine la curva oor y realice el
emparejamiento de canales. Puede representar lineas espectrales, magnitudes espectra-
les, fases espectrales o hbridos cuando se mezcla con el emparejamiento de canales.
La semantica del vector no inuye en la abstraccion de residuo.
Represente a lo que represente, la abstraccion de residuo codica el vector de
residuos en el paquete de vorbis, y reconstruye los vectores durante la decodicacion.
Vorbis hace uso de tres tipos diferentes de codicacion (numeradas como 0, 1, y 2) de
la misma abstraccion de codicacion de vector.
5.6.2. Formato de residuos
El formato de residuos particiona cada vector del vector empaquetado en trozos,
clasicando cada uno, codicando la clasicacion de los trozos y nalmente codicando
los trozos mismo usando la clasicacion VQ especca denida para cada clasicacion
elegida. El particionamiento y la intercalacion vara seg un el n umero de codicacion del
residuo, aunque en los procesos de mas alto nivel empleados para clasicar y codicar
el vector del residuo es el mismo en las tres variantes.
Un conjunto de vectores de residudos codicados tienen todos la misma longitud.
La estructura de codicacion de alto nivel, ilustrada en la Figura 5.7, es de la siguiente
forma:
Cada vector se divide en multiples trozos de igual tama no, de acuerdo a la
conguracion especicada. Si tenemos un vector de longitud n, un tama no de
particion de residue partition size, y un total de ch vectores de residuos, el
n umero total de trozos codicados es
n
[residue partition size]
ch. Hay que destacar
que la division entera trunca. Para el ejemplo que veremos despues, supondremos
un [residue partition size] de 8.
Cada particion de cada vector tiene un n umero de clasicacion que especica cual
de los codebooks VQ congurados se empleara para decodicar la particion. Los
n umeros de clasicacion de cada particion pueden imaginarse como si formara
un vector por ellos mismos, tal y como aparece en la imagen de abajo. As como
los vectores de residuos se codican en particiones agrupadas para incremen-
tar la eciencia de la codicacion, el vector de clasicacion tambien esta divido
en fragmentos. Los elementos de tipo entero que conforman cada trozo de una
clasicacion se construyen como un escalar que representa el n umero de clasi-
cacion en ese trozo. En el ejemplo de abajo, el codigo de clascacion codica
dos n umeros de clasicacion.
Los valores en un vector de residuos pueden codicarse en bloque de una sola
pasada por el vector de residuos, pero dise nos mas ecientes de codebook acon-
sejan que cada vector se codique como la suma aditiva de varias pasadas por el
vector de residuos, usando mas de un codebook VQ. As, cada valor del residuo
acumula de forma potencial valores de m ultiples pasadas del decodicador. El
valor de clasicacion asociado con una particion es el mismo en cada pasada, por
lo que la clave de clasicacion se codica solo en la primera pasada.
5.6. CONFIGURACION Y DECODIFICACION DE LOS RESIDUOS 123
Figura 5.7: Empaquetamiento de los residuos.
124 CAP

Residuo 0
El residuo 0 y el 1 solo dieren en la forma en la que los valores de una particion
de residuos se intercalan en la codicacion de la particion (lo que en la gura anterior
eran las cajas de color marron y cyan).
La codicacion 0 de residuos intercala las codicaciones VQ seg un la dimension
del codebook usdo para codicar una particion en una pasada especca. La dimension
del codebook no necesita ser la misma en m ultiples pasadas, solo se necesita que el
tama no de la particion sea un m ultiplo exacto de la dimension del codebook.
Como ejemplo, asumiremos un tama no de particion de 8, para ser codicado seg un
un residuo de tipo 0 usando codebook de tama nos 8, 4, 2 y 1:
residuos: 0 1 2 3 4 5 6 7
codebook
8
: 0 1 2 3 4 5 6 7
codebook
4
: 0 2 4 6 1 3 5 7
codebook
2
: 0 4 1 5 2 6 3 7
codebook
1
: 0 1 2 3 4 5 6 7
Residuo 1
Este tipo de residuo no intercala las codicaciones VQ. Representa los escalares de
las particiones en orden. De todas formas, tal y como ocurra con el residuo 0, el tama no
de la particion tiene que ser un m ultiplo entero del tama no del codebook, aunque el
tama no del codebook pueda variar de pasada a pasada. En el ejemplo asumiremos un
vector de tama no 8, codicado seg un el residuo 1 usando tama nos de 8, 4, 2 y 1:
residuos: 0 1 2 3 4 5 6 7
codebook
8
: 0 1 2 3 4 5 6 7
codebook
4
: 0 1 2 3 4 5 6 7
codebook
2
: 0 1 2 3 4 5 6 7
codebook
1
: 0 1 2 3 4 5 6 7
Residuo 2
Se puede pensar en este tipo como en una variante del resido de tipo 1. En lugar
de codicar las m ultiples pasadas en el vector como hace el tipo 1, los ch vectores de
entrada se convierten en un unico vector de longitud chn con todos sus elementos
intercalados. La codicacion procede entonces como en el tipo 1. La decodicacion es
como en el tipo 1, pero con la intercalacion invertida. Si se esta operando en un unico
vector para comenzar, los residuos de tipo 1 y tipo 2 son equivalentes. Un ejemplo
sencillo que ilustra rapidamente este tipo de residuo se muestra en la Figura 5.8:
5.6.3. Decodicacion de los residuos
Decodicacion de la cabecera
La cabecera de los tres tipos de residuos es identica, y se procede de la siguiente
forma:
Figura 5.8: Codicacion y decodicacion de un residuo de tipo 2.
1. [residue begin] uint24
2. [residue end] uint24
3. [residue partition size] uint24 +1
4. [residue classifications] uint6 +1
5. [residue classbook] uint8
[residue begin] y [residue end] seleccionan la sub-porcion especca de cada
vector que esta realmente codicado. Implementa algo parecido a un ltro paso ban-
da, orientado a la codicacion, haciendo que el vector empieze en [residue begin]
y termine en [residue end] de forma efectiva. Los valores anteriores y posteriores
de los vectores desempaquetados se ponen a cero. Destacar que para los residuos
de tipo 2, estos valores as como el [residue partition size] se reeren al vec-
tor intercalado y no a cada uno de los vectores individuales antes de intercalarlos.
[residue partition size] es tal y como se ha explicado antes, [residue classifications]
es el n umero de posibles clasicaciones a los que una particion puede pertenecer, y
[residue classbook] es el n umero de codebook que se han usado para codicar las
claves de clasicacion. El n umero de dimension del book [residue classbook] de-
termina cuantos valores de clasicacion se agrupan en una unica clave de clasicacion.
Despues leemos un patron de mapa de bits que especica que codigo de clases de
particion se usa en cada pasada.
1. itera [i] en el intervalo 0 . . .[residue classifications]1
a) [high bits] 0
b) [low bits] uint3
126 CAP

c) [bitflag] 1 bit como booleano
d) si ([bitflag] es activo ) [high bits] uint5
e) [residue cascade]
[i]
[high bits]8+[low bits]
2. n
Para terminar, leemos en una lista de n umeros de book cada uno correspondiente a
un bit especco activado en el bitmap. Iteramos los posibles codebook de clasicacion
y el n umero maximo posible de etapas de codicacion (8 en Vorbis I, restringido al ser
de 8 bits los elementos del bitmap):
1. itera [i] 0 . . .[residue classifications]1
itera [j] 0 . . . 7
si ([residue cascade]
[i]
bit
[j]
esta activo )
[residue books]
[i][j]
uint8
si no, ([residue cascade]
[i]
bit
[j]
no esta activo )
[residue books]
[i][j]
no usado
2. n
Una condicion n-de-paquete en alg un punto de la cabecera hace la trama inde-
codicable. Ademas, cualquier n umero en el codebook mayor que el maximo codebook
numerado congurado en esa trama tambien la convierte en indecodicable.
Decodicacion del paquete
La decodicacion de los paquetes de tipo de residuos 0 y 1 es identico excepto
para el intercalado especco de la particion. El formato de tipo 2 se puede hacer fuera
del proceso de decodicacion del formato 1. As, primero describiremos la estructura
de decodicacion com un a los tres formatos.
Ademas de la informacion de la conguracion, el proceso de decodicacion de
residuos hace tantas pasadas como el n umero de vectores que conforman el conjunto
del submapa, y el vector de valores bandera indica si alguno de esos vectores no se tiene
que decodicar. Si el n umero de pasadas es 3 y el vector n umero 1 esta marcado para
no decodicarse, el decodicador ignora el vector 1 en el bucle de decodicacion. De
todas formas, incluso los vectores que no se van a decodicar se reservan en memoria
y se inician a cero.
Estos valores son utiles conceptualmente para claricar el proceso de decodica-
cion:
1. [classvals per codeword] [codebook dimensions] del
codebook [residue classbook]
2. [n to read] [residue end] [residue begin]
3. [partitions to read] [n to read] / [residue partiton size]
El proceso de decodicacion sigue los pasos que especicaremos a continuacion,
seg un la descripcion ofrecida anteriormente. Asumimos que el n umero de vectores
codicados, notado por [ch], se proporciona desde el nivel de decodicacion superior.
1. Reservar en memoria y poner a cero todos los vectores que se devolveran
2. itera [pass] en el intervalo 0 . . . 7
a) [partition count] 0
b) si ([pass] = 0)
itera [j] en el intervalo 0 . . .[ch]1
[temp] lee del paquete usando el codebook [residue classbook]
como elemento
itera [k] en el intervalo [classvals per codeword] 1 . . . 0
[classifications]
[j],([partition count]+[k])

[temp] % [residue classifications]
[temp] [temp] /
Z
[residue classifications])
c) [classword count] 0
d) itera [j] en el intervalo 0 . . .[ch]1
si ([j] ,= no-decodicar )
1) [vqclass] [classifications]
[j],([partition count]+[classword count])
2) [vqbook] [residue books]
[vqclass],[pass]
3) si ( [vqbook] ,= no-usado )
decodica la particion en el vector [j] de salida, comenzando en
el [residue begin]+[partition count][residue partition size]
usando el codebook [vqbook] en el contexto VQ
e) [classword count]++
f ) [partition count]++
g) si ([classword count] < [classvals per codeword])
([partition count] < [partitions to read]) ir al paso c)
h) si ( [partition count] < [partitions to read] ) ir al paso b)
3. n
Una condicion de n-de-paquete durante la decodicacion se considera un suceso
puntual. El decodicador devolvera el vector resultante de la decodicacion hasta ese
momento.
Especco para el formato 0
El formato de tipo 0 decodica la particion exactamente como se describio en la
seccion de dicho ttulo. Un pseudocodigo posible para ese algoritmo podra ser el que
se escribira a continuacion. Asumiremos que:
[n] [residue partition size]
[v] vector de residuos
[offset] posicion de inicio de lectura de [v]
1. [step] [n] / [codebook dimensions]
2. itera [i] en el intervalo 0 . . .[step]1
a) [entry temp] lee vector desde el paquete usando el
codebook actual en el contexto VQ
128 CAP

b) itera [j] en el intervalo 0 . . .[codebook dimensions]1
[v]
([offset]+[i]+[j][step])
[v]
([offset]+[i]+[j][step])
+ [entry temp]
[j]
3. n
El formato de tipo 1 decodica la particion exactamente como se describio en la
seccion de dicho ttulo. Asumiremos que:
[n] [residue partition size]
[v] vector de residuos
[offset] posicion de inicio de lectura de [v]
Un pseudocodigo posible para ese algoritmo podra ser el que se escribira a con-
tinuacion:
1. [i] 0
2. [entry temp] lee vector desde el paquete usando el
codebook actual en el contexto VQ
3. itera [j] en el intervalo 0 . . .[codebook dimensions]1
[v]
([offset]+[i])
[v]
([offset]+[i])
+ [entry temp]
[j]
[i]++
4. si ([i] < [n]) ir al paso 2
5. n
El formato 2 se puede convertir al formato 1 mediante una serie de pasos, reali-
zados en orden. Una vez convertido al tipo 1, usaremos el algoritmo ya descrito para
su decodicacion.
1. Asumimos que se van a decodicar ch vectores de n elementos
2. Decodicaremos usando el formato 1 un vector [v] de chn
3. Desharemos la intercalacion del vector [v] en ch vectores independientes notados
por salida [k], siendo k unndice entre 0 . . .ch1, seg un el algoritmo mostrado
a continuacion
1. itera [i] en el intervalo 0 . . .[n]1
itera [j] en el intervalo 0 . . .[ch]1
salida [j]
[i]
[t]
([i][ch]+[j])
2. n
El formato 2 no maneja la bandera no-decodicar de forma diferente del tipo
0 o 1; si todos los vectores se marcan a no-decodicar, no se realiza decodicacion
alguna. Sin embargo, con que uno de ellos este marcado para ser decodicado, todos
los vectores seran decodicados.
5.7. FUNCIONES AUXILIARES DE LA IMPLEMENTACI
ON 129
5.7. Funciones auxiliares de la implementacion
5.7.1. Introduccion
Cuando hemos explicado los distintos algoritmos que implementan el calculo de
elementos necesarios para la decodicacion de la onda, hemos hecho referencia a cier-
tas funciones que, si bien aparecen en los procesos de decodicacion, son totalmente
independientes de estos y no conllevan mas que calculos generales. La intencion de
este texto es determinar que hace cada una de las funciones referenciadas en distintas
partes del documento.
ilog (x)
Esta funcion devuelve el bit activo mas signicativo del complemento a dos del
valor x. Los valores de x menores de cero devuelven cero por denicion.
1. [return value] 0
2. si ([x] ,= 0)
[return value]++
[x] 1
repetir paso 2
3. n
float32 unpack (x)
Su nalidad es traducir la representacion binaria de un valor otante empaquetado
que usa un codebook en la representacion de otante que emplea el decodicador.
Aqu se implementa para un oat32 nativo a la arquitectura del host.
1. [mantissa] [x] 0x1fffff, resultado sin signo
2. [sign] [x] 0x80000000, resultado sin signo
3. [exponent] ([x] 0x7fe00000) 21, resultado sin signo
4. si ([mantissa] ,= 0) [mantissa] -[mantissa]
5. devuelve [mantissa] (2
[exponent]788
)
lookup1 values (codebook entries, codebook dimensions)
Se usa para calcular la longitud correcta de un ndice de la tabla de lookup de tipo
1 para un codebook VQ. Los valores de esta lista estan permutados para construir la
tabla de b usqueda de tama no codebook entries] de vectores VQ.
El valor que devuelve la funcion se dene como el mayor valor entero para el cual
[return value]
[codebook dimensions]
[codebook entries].
low neighbor (v, x)
Devuelve la posicion n del mayor elemento de [v] para el que n < [x], y [v]
n
< [v]
[x]
130 CAP

high neighbor (v, x)
Devuelve la posicion n del menor elemento de [v] para el que n < [x], y [v]
n
> [v]
[x]
render point (x0, x1, y0, y1, X)
Esta funcion calcula el valor Y en la ordenada X perteneciente a la lnea denida
con la pareja de puntos (x0,y0), (x1,y1). Esta funcion usa un algoritmo entero para
solucionar el valor del punto de forma directa, sin calcular los valores sobre la lnea.
1. [dy] [y1] [y0]
2. [adx] [x1] [x0]
3. [ady] [[dy][
4. [err] [ady] ([X] [x0]
5. [off] [err] /
Z
[adx]
6. si ([dy] < 0)
[Y] [y0] [off]
si no,
[Y] [y0] + [off]
7. n
render line (x0, y0, x1, y1, v)
La decodicacion de oor tipo 1 usa este algoritmo de dibujado de lneas entero
para construr una curva contigua a trozos. Es importante aqu que la division ente-
ra redondee hacia cero tanto los n umeros negativos como los positivos, no teniendo
relevancia en otro ambito.
1. [dy] [y1] [y0]
2. [adx] [x1] [x0]
3. [ady] [[dy][
4. [err] [ady] ([X] [x0])
5. [off] [err] /
Z
0
[adx]
6. si ([dy] < 0)
[sy] [base] 1
si no, ([dy] 0)
[sy] [base] +1
7. [ady] [ady] [base] [adx]
5.7. FUNCIONES AUXILIARES DE LA IMPLEMENTACI
ON 131
8. [v] [x] [y]
9. itera [x] en el intervalo [x0]+1 . . .[x1]1
a) [err] [err] + [ady]
b) si ([err] [adx])
[err] [err] [adx]
[y] [y] + [sy]
si no, ([err] < [adx])
[y] [y] + [base]
10. [v] [x] [y]
11. n
132 CAP

Captulo 6
Apendices
6.1. Principios de la Informatica Graca
Aqu explicaremos las operaciones necesarias para realizar la transformacion de un
mundo 3D continuo a una imagen 2D que representa la proyeccion de la escena dada
mediante una camara denida, as como una breve descripcion de las trasnformacio-
nes geometricas basicas. Si desea mas informacion sobre representacion, iluminacion y
trasnformaciones, puede consultar documentacion especializada [22].
Comenzaremos viendo como se transforma en el espacio 3D una geometra. Por
simplicacion, determinaremos toda la geometra como un punto en el espacio tridi-
mensional, ya que la transformacion de una geometra mas compleja se realiza punto
a punto.
6.1.1. Transformaciones en 2D
Primero estudiaremos las transformaciones en un espacio bidimensional, ya que el
tridimensional es una extension de este. Describiremos las transformaciones geometricas
basicas que usaremos, y la forma de representarlo para su computo.
Podemos trasladar puntos en el plano (x, y) a nuevas posiciones simplemente
a nadiendo la cantidad a transladar a las coordenadas del punto. Para cada punto
P(x, y), moverlo d
x
unidades en el eje x y d
y
unidades en el eje y hasta el punto
P
(x
, y
), podemos escribirlo como

x
= x +d
x
, y
= y +d
y
(6.1)
Para simplicar la expresion, deniremos los siguientes vectores columna
P =
_
x
y
_
, P
=
_
x
_
, T =
_
d
x
d
y
_
(6.2)
Ahora podemos reescribir la expresion (6.1)
P
= P +T (6.3)
Como mencionamos en la introduccion, todo se limita a trasladar los vertices que
conforman una gura. Supongamos que tenemos un segmento de recta que queremos
trasladar. Habra que trasladar todos los puntos que conforman la recta, pero como
133
134 CAP
ITULO 6. AP
ENDICES
podemos comprobar facilmente, basta trasladar los puntos que forman el segmento
para trasladar el segmento completo.
La rotacion sobre un angulo desde el origen se dene matematicamente como
x
= xcos ysen , y
= ysen +ycos (6.4)

En forma matricial, la expresion (6.4) se puede expresar como
_
x
_
=
_
cos sen
sen cos
_
_
x
y
_
o bien P
= R P, (6.5)
donde R es la matriz de rotacion de la ecuacion (6.5). Los angulos positivos se miden
en sentido contrario a las agujas del reloj, desde el eje x al eje y.
Coordenadas homogeneas
Hemos obtenido la expresion para trasladar y rotar puntos en un espacio bidi-
mensional, pero nos encontramos ante la situacion de que no realizan las mismas
operaciones, como se puede apreciar. Tenemos que
P
= T +P, P
= R P (6.6)
Lo recomendable sera poder combinar de forma consistente las transformaciones
entre s, para lo cual necesitamos tratarlas de forma semejante. Si expresamos los
puntos en coordenadas homogeneas, ambas pueden tratarse como multiplicaciones.
En coordenadas homogeneas, a nadimos una tercera coordenada al punto. En lu-
gar de disponer de parejas de puntos (x, y), cada punto se representa por una tripleta
(x, y, W). Denimos que (x, y, W) y (x
, y
, W
) corresponden al mismo punto si una

es m ultiplo de la otra. Por tanto, cada punto puede tener varias representaciones de
tripletas en coordenadas homogeneas. La restriccion es que, al menos una de las coorde-
nadas de la tripleta debe ser distinta de cero, por lo que la tripleta (0, 0, 0) es invalida.
Si W = 0, tenemos un punto en el innito, y por tanto no ocuparemos aqu su tra-
tamiento, ya que no entra dentro de nuestros intereses. Si W ,= 0, podemos dividir el
resto de coordenadas por el, teniendo mismo punto representado por (x/W, y/W, 1),
tripleta que contiene las coordenadas cartesianas del punto homogeneo.
Puede impactar ver tripletas de coordenadas para representar un punto bidimen-
sional, pero la explicacion es sencilla. El conjunto de tripletas que representan al mismo
punto conforma una recta en el espacio tridimensional, como se observa en la Figura
6.1. Si homogeneizamos el punto, obtendremos un punto (x, y, 1), que resulta ser el
punto de interseccion de dicha recta con el plano denido por la ecuacion W = 1 en
el espacio (x, y, W).
Al estar formados por una tripleta de valores, la ecuacion de traslacion (6.1) se
reescribe en forma matricial como
_
_
x
1
_
_
=
_
_
1 0 d
x
0 1 d
y
0 0 1
_
_
_
_
x
y
1
_
_
(6.7)
Si consideramos la matriz de traslacion empleada como T, podemos reescribir la
expresion (6.7) como
P
= T P (6.8)
6.1. PRINCIPIOS DE LA INFORM
ATICA GR
AFICA 135
Figura 6.1: El espacio de coordenadas XY W, con el plano W = 1 y el punto
P(X, Y, W) proyectado en el.
Las ecuaciones de rotacion (6.5) se escriben ahora como
_
_
x
1
_
_
=
_
_
cos sen 0
sen cos 0
0 0 1
_
_
_
_
x
y
1
_
_
(6.9)
Sea
R() =
_
_
cos sen 0
sen cos 0
0 0 1
_
_
(6.10)
Sustituyendo en la ecuacion (6.9) lo denido en (6.10) tenemos
P
= R() P (6.11)
Composicion de transformaciones 2D
La nalidad de la composicion es poder combinar las distintas transformaciones
de forma comoda y util para poder obtener los resultados que se deseen. La idea
de componer las operaciones es la de simplicar calculos, ya que en lugar de aplicar
varias transformaciones consecutivas a un conjunto de puntos, basta aplicar una unica
transformacion, la transformacion resultante, al conjunto de puntos.
Combinando la traslacion con la rotacion podemos salvar la limitacion que hemos
impuesto en la rotacion: podemos girar desde un punto P
1
arbitrario, en lugar de estar
limitados a rotar desde el origen. Los unicos pasos que hay que dar son:
1. Realizar una trasladacion que convierta a P
1
en el origen
2. Rotar los puntos deseados seg un los angulos deseados
3. Deshacer la traslacion realizada en el punto primero
Si denimos el punto P1(x
1
, y
1
) como punto sobre el que realizar la rotacion,
podemos denir la secuencia de pasos ilustrados como
136 CAP
ITULO 6. AP
ENDICES
T(x
1
, y
1
) R() T(x
1
, y
1
) =
_
_
1 0 x
1
0 1 y
1
0 0 1
_
_
_
_
cos sen 0
sen cos 0
0 0 1
_
_
_
_
1 0 x
1
0 1 y
1
0 0 1
_
_
=
_
_
cos sen x
1
(1 cos) +y
1
sen
sen cos y
1
(1 cos) x
1
sen
0 0 1
_
_
(6.12)
6.1.2. Transformaciones en 3D
Como hemos visto, las transformaciones en 2D se representaban por matrices
3 3 usando coordenadas homogeneas. De igual forma, las transformaciones en el
espacio tridimensional se representaran por matrices 44, debido al uso de coordenadas
homogeneas para representar un punto de un espacio tridimensional, aportando una
coordenada mas, igual que suceda en el espacio bidimensional. Por tanto, en lugar de
representar un punto por una tripleta (x, y, z), usaremos una cuadrupla (x, y, z, W) para
representar un punto en coordenadas homogeneas. Igual que suceda con las tripletas
en el espacio bidimensional, representan al mismo punto aquellas cuadr uplas que eran
m ultiplo una de otra, sin ser dicho m ultiplo el cero. De la misma forma, la cuadrupla
(0, 0, 0, 0) no es valida. La representacion cartesiana es (x/W, y/W, z/W, 1), de forma
similar a lo dado en espacio 2D. Normalmente el sistema de coordenadas empleado en
espacios matematicos 3D es el llamado de la mano derecha, y es el que se muestra en
la Figura 6.2.
Figura 6.2: Sistema de coordenadas de la mano derecha.
La traslacion en el espacio tridimensional es una simple extension de todo lo
descrito en el espacio bidimensional. Por ello, es facil comprobar que la expresion que
rige la traslacion en coordenadas homogeneas expresada en forma matricial es similar
a la planteada en (6.8), pero teniendo en cuenta que
T(d
x
, d
y
, d
z
) =
_
_
1 0 0 d
x
0 1 0 d
y
0 0 1 d
z
0 0 0 1
_
_
(6.13)
La rotacion denida en el espacio bidimensional corresponde a la rotacion sobre
ATICA GR
AFICA 137
el eje z en el espacio tridimensional, que es
R
z
() =
_
_
cos sen 0 0
sen cos 0 0
0 0 1 0
0 0 0 1
_
_
(6.14)
De forma sencilla se puede obtener la expresion asociada a la rotacion respecto a
los dos ejes restantes, que son
R
x
() =
_
_
1 0 0 0
0 cos sen 0
0 sen cos 0
0 0 0 1
_
_
(6.15)
R
y
() =
_
_
cos 0 sen 0
0 1 0 0
sen 0 cos 0
0 0 0 1
_
_
(6.16)
La composicion de traslacion y rotacion generara una matriz cuya matriz superior
izquierda de 33 proporciona la rotacion, y la ultima columna proporciona la traslacion.
Por tanto, esta matriz sera de la forma
M =
_
_
r
11
r
12
r
13
t
x
r
21
r
22
r
23
t
y
r
31
r
32
r
33
t
z
0 0 0 1
_
_
(6.17)
6.1.3. Proyecciones de visualizacion
Normalmente, la proyeccion se realiza desde puntos pertenecientes a un sistema
de coordenadas de dimension n, a puntos de un sistema de coordenadas de dimension
menor que n. En el contexto al que nos referimos nosotros, simplmente haremos pro-
yecciones desde un espacio 3D a uno 2D. Por tanto, nosotros nos limitaremos a trazar
rayos desde los puntos del espacio 3D, y calcular los puntos de interseccion con un
plano arbitrario al que llamaremos plano de proyeccion. La Figura 6.3 representa los
dos tipos de proyeccion.
Figura 6.3: Tipos de proyecciones: paralela, conservando angulos y distancias, y pers-
pectiva, conservando solo angulos.
138 CAP
ITULO 6. AP
ENDICES
Proyeccion paralela
La proyeccion paralela mas difundida es la llamada proyeccion ortograca, consis-
tente en proyectar cada punto con un proyector paralelo al eje i-esimo en un plano de
visualizacion contenedor de los otros dos ejes. Por ejemplo, la proyeccion ortograca
del eje Z en el plano XY consiste en anular la coordenada z, es decir, convertir el
punto P(x, y, z, W) en P
(x, y, 0, W).
Proyeccion de perspectiva
Todos los proyectores convergen en un punto llamado centro de proyeccion (COP).
Para los calculos sucesivos, supondremos que el plano de proyeccion es perpendicular
al eje Z, a una distancia d del centro de proyeccion, tal y como muestra la Figura 6.4.
Figura 6.4: Calculo de la proyeccion en perspectiva P
del punto P.
Usando semejanza de triangulos podemos decir que
x
=
x
z/d
, y
=
y
z/d
(6.18)
Usando coordenadas homogeneas podemos reescribir la expresion (6.18) como
_
_
X
Y
Z
W
_
_
= M
per
_
x
y
z
1
_
_
(6.19)
siendo
M
per
=
_
_
1 0 0 0
0 1 0 0
0 0 1 0
0 0 1/d 0
_
_
(6.20)
Sustituyendo terminos de (6.20) en (6.19) y simplicando, podemos escribir que
_
_
X
Y
Z
W
_
_
=
_
_
x
y
z
z/d
_
_
(6.21)
Si dividimos la expresion (6.22) por W para obtener las coordenadas cartesianas
equivalentes, obtenemos
ATICA GR
AFICA 139
_
_
x
1
_
_
=
_
_
x
z/d
y
z/d
d
1
_
_
(6.22)
Por tanto, en (6.22) obtenemos la relacion entre el punto proyectado P
y el punto
original P, cumpliendo la restriccion que jamos con respecto a z.
En la Figura 6.5 podemos ver el resultado practico de esta transformacion de P
en P
, que dependa o no de P
z
, y como la proyeccion de dos objetos distintos con
distinto tipo de proyeccion puede resultar identica.
Figura 6.5: Proyeccion perspectiva y proyeccion paralela, y objetos reales que producen
dicha proyeccion.
140 CAP
ITULO 6. AP
ENDICES
CAP
ITULO 6. AP
ENDICES
Glosario
A
AC-3 El sistema de codicacion usado por Dolby Digital. Ambos termino, AC-3
y Dolby Digital, se suelen usar indistintamente, pag. 58.
B
BIOS Acronimo de Basic Input/Output System, se reere al software que se
ejecuta al inicio, que permite controlar pantalla, teclado, unidades de
disco, comunicacion serie y demas, sin acceder a ning un programa del
disco duro. Normalmente se encuentra en la ROM de la placa., pag. 51.
C
codec De ((coder/decoder)) (codicador/descodicador), tecnologa que permite
la compresion y decompresion de datos. Pueden implementarse tanto en
software como en hardware, o en una combinacion de ambos., pag. 54.
compilador cruzado Se usa este termino para referirse a un compilador que genera
codigo objeto de una maquina distinta de la que ejecuta el compilador.
Sirve para generar el codigo objeto de una arquitectura desde otra distinta
en la que se encuentran todas las herramientas de desarrollo., pag. 5.
D
doublebuer Termino referido al uso de dos buers para la representacion visual
en pantalla, de forma que se muestra uno de ellos miestras se dibuja el
siguiente fotograma en el otro. Una vez dibujado, se intercambian los
buers, y se muestra el recien dibujado mientras se comienza a dibujar
en el anteriormente mostrado. Esta tecnica evita el parpadeo propio de
la escena dibujada, ya que evita que se aprecie el dibujado progresivo de
la misma., pag. 69.
DTS Acronimo de Digital Theatre Sound, se trata de un formato que hace que
las pistas de audio se aproximen mas a la grabacion original que otras
pistas comprimidas. En conjuncion con el benecio multidismensional de
la tecnologa de sonido envolvente, la calidad del audio de las pistas
y m usicas en formato DTS mejoran dramaticamente el contenido. Mas
informacion en su web: http://www.dtsonline.com/, pag. 58.
I
II GLOSARIO
F
FPGA Acronimo de Field Programable Gate Array, se trata de una malla de
puertas en la que la red logica puede programarse en el dispositivo tras
su creacion. Esta compuesta por puertas o tablas de consulta en RAM,
ip-ops y cableado de interconexion programable., pag. 1.
free-lance Se dice de la persona que trabaja por su cuenta, haciendo creaciones
propias sin formar parte de la plantilla de ninguna empresa., pag. 6.
M
MIPS Acronimo de Microprocessor without Interlocked Pipeline Stages, es un
procesador RISC desarrollado por la MIPS Computer Systems Inc. (http:
//www.mips.com/), pag. 1.
mod-chip Nombre com un con el que se conoce a los circuitos que se implantan en
las consolas para alterar la funcionalidad de la misma, como puede ser
el bloqueo de codigo de region o el bloqueo por proteccion anti-copia.,
pag. 6.
O
OpenGL OpenGL es el principal entorno de desarrollo graco 2D y 3D portable.
No esta sujeto a ning un sistema operativo y reeja el pensamiento y
talento de desarrolladores software de diferentes trasfondos gracos. Mas
informacion en su web: http://www.opengl.org/, pag. 64.
P
PIC Microcontrolador fabricado por Microchip (http://www.microchip.com/),
normalmente usados como peque nas unidades de procesamiento en cir-
cuitos simples de control., pag. 1.
R
redonda es una nota que tiene una duracion de cuatro tiempos. Su simbolo es un
ovalo sin llenar, y sin barra, de ahi su nombre. Su silencio asociado es
una barra horizontal que ((cuelga)) de la segunda linea del pentagrama.,
pag. 66.
RISC Acronimo de Reduced Instruction Set Computer, es un microprocesador
dise nado para realizar un n umero reducido de tipos de instrucciones para
poder operar a una velocidad mayor, dada la simplicidad de la circuitera
necesaria., pag. 1.
S
SIMD Acronimo de Single-Instruction Stream Multiple-Data Stream, se reere
a un tipo de arquitectura esencial en el mundo del calculo paralelo de los
ordenadores. La idea basica consiste en procesar un conjunto de datos de
forma simultanea, aprovechando que se ha de realizar la misma operacion.
GLOSARIO III
La habilidad de procesar vectores y matrices en tiempo mnimo ha creado
una demanda muy importante en areas como prediccion metereologica o
investigacion de las radiaciones de cancer. El poder de esta arquitectura
se puede contemplar cuando el n umero de procesadores coincide con el
n umero de elementos a procesar. En ese caso, la suma y multiplicacion
de los elementos se puede realizar de forma simultanea. Incluso cuando
el tama no de un vector es mayor al n umero de procesadores disponibles,
la ganancia comparada con el algoritmo secuencia es enorme., pag. 93.
streaming Tecnica para transferir datos de manera que pueden ser procesados con-
forme llegan, de forma contnua. La tecnologa de ((streaming)) estan
tomando relevancia debido al crecimiento de internet, ya que muchos
usuarios no tienen a un un acceso lo sucientemente rapido como pa-
ra poder acceder a cheros multimedia grandes de forma rapida. Con
((streaming)), el cliente puede comenzar su reproduccion antes de recibir
el chero completo., pag. 56.
V
VLIW Acronimo de Very Long Instruction Word, describe una arquitectura de
procesamiento en la que el compilador o el preprocesador dividen la ins-
truccion de programa en operaciones basicas que pueden ser realizadas
por el procesador en paralelo., pag. 1.
X
x86 Se reere a cualquier procesador de la familia Intel 80x86, o a cualquier
procesador compatible, como Cyrix o AMD., pag. 1.
IV GLOSARIO
Bibliografa
[1] 4Front Technologies. http://www.opensound.com/.
[2] Ars Technica. The PC Enthusiasts resource. http://www.arstechnica.com.
[3] Compilador Vector EE. http://www.codeplay.com.
[4] The Enterprise Linux Resource. http://www.linux.com/.
[5] GameDev.net all your game development needs. http://gamedev.net/.
[6] Lista de monitores con los que funciona la PS2. http://playstation2-linux.
com/sog.php.
[7] Pagina ocial de Sony para PlayStation. http://es.playstation.com.
[8] Proyecto ps2stu. http://playstation2-linux.com/projects/ps2stuff/.
[9] PS2RealityCompilador Vector EE. http://www.ps2reality.net.
[10] Sony Computer Ent. Atsushi Kunimatsu; Nobuhiro Ide; Toshinori Sato; Yukio En-
do; Horoaki Murakami; Masaaki Oka; Masakasu Suzuoki. Vector Unit Architecture
for emotion systhesis.
[11] Richard Boulton. Implementacion de la FFT usada en el XMMS. http://cvs.
xmms.org/cvsweb.cgi/xmms/xmms/fft.c, http://cvs.xmms.org/cvsweb.
cgi/xmms/xmms/fft.h.
[12] Karsten Scheibler y Jonathan Leto Dragan Stancevics. Linux Assembly! http:
//linuxassembly.org/.
[13] Sony Computer Entertaintment. Biblioteca de desarrollo de la ps2 bajo linux.
/usr/docu/Playstation2/libps2dev/.
[14] Sony Computer Entertaintment. Pagina de la Comunidad Linux de la PS2. http:
//playstation2-linux.com/.
[15] Sony Computer Entertaintment. VU Demo Coding Contest. http://
playstation2-linux.com/projects/vudemocontest/.
[16] H. Tago et al. Importance of CAD tools and methodologies in high speed CPU
desing.
[17] N. Kojima et al. Clock desing of 300 MHz 128 bit 2-Way superscalar micropro-
cessor.
V
VI BIBLIOGRAF
IA
[18] N. Kojima et al. Repeater insertion method and its application to the 300 MHz
128 bit 2-Way superscalar microprocessor.
[19] Oobles et al. PS2DEV network. http://ps2dev.org/.
[20] T. Kamei et al. 300 Mhz Desing methodology of VU for emotion synthesis.
[21] Sarah Ewen. Coding for the Playstation2. http://playstation2-linux.com/
coding-on-playstation2.php.
[22] Feiner y Hughes Foley, van Dam. Computer Graphics: Principles and Practice.
Addison Wesley, 1997.
[23] Xiph.org Foundation. Pagina ocial de Ogg Vorbis. http://www.vorbis.com/.
[24] MIPS Technologies Inc. MIPS32. Architecture for Programmers. Volume I: Intro-
duction to the MIPS32 Architecture, 2002. Document number: MD00082.
[25] Sony Computer Entertainment Inc. EE Core Instruction Set Manual. 2001.
[26] Sony Computer Entertainment Inc. EE Core Users Manual. 2001.
[27] Sony Computer Entertainment Inc. EE Overview. 2001.
[28] Sony Computer Entertainment Inc. EE Users Manual. 2001.
[29] Sony Computer Entertainment Inc. GS Users Manual. 2001.
[30] Sony Computer Entertainment Inc. VU Users Manual. 2001.
[31] Sony Computer Entertainment Inc. Linux (for Playstation2) VCL Preprocesor.
http://playstation2-linux.com/projects/vcl/, 2002.
[32] Inc. Integrated Device Technology. IDT MIPS Microprocessor Family Software
Reference Manual. http://members.rogers.com/jenova0/MIPS.pdf, 1996.
[33] Tom Davis y Mason Woo Jackie Neider. OpenGL Programming Guide. Addison-
Wesley Publishing Company, http://fly.cc.fer.hr/~unreal/theredbook/,
1993.
[34] Fernado Rodrguez Leon. El estandar MPEG. http://atc.ugr.es/~jesus.
[35] El liceo digital. Introduccion a la M usica. http://www.liceodigital.com/
tercero/musica3/lamusic3.htm.
[36] Rob Louie. Playstation 2 Game Programming Part 1. http://gamedev.net/
reference/programming/features/ps2gp1/.
[37] Francisco J. Fernandez Baldomero y Antonio Francisco Diaz Garcia
Mancia Anguita Lopez. Asignatura de Arquitectura de Computadores
II. http://www-etsi2.ugr.es/planes/ingenieria/quinto/arquitectura_
de_computadores_ii.phtml.
[38] Sony Computer Ent. Masaaki Oka; Masakasu Suzuoki. Designing and program-
ming the Emotion Engine.
BIBLIOGRAF
IA VII
[39] Roberto Francisco Arroyo Moreno. Formato de compresion de audio Ogg Vor-
bis. http://atc.ugr.es/~jesus/asignaturas/ae/descargas/trabajos/
2002-2003/vorbis.pdf.
[40] Napalm. Pagina ocila de Naplink. http://naplink.napalm-x.com/.
[41] University of Texas at Austin. What do we need to know about the phy-
sics of singing? http://www.utexas.edu/cofa/music/voice/texassings/
soundstuff.htm.
[42] Frederic Patin. Beat Detection Algorithms. http://www.gamedev.net/
reference/articles/article1952.asp.
[43] Jes us Gonzalez Pe nalver. Asignatura de Arquitecturas Especializadas. http:
//atc.ugr.es/~jesus/asignaturas/ae/.
[44] Bharata B. Rao. Inline assembly for x86 in Linux. http://www-106.ibm.com/
developerworks/linux/library/l-ia.html?dwzone=linux, 2001.
[45] Paul Smith. VU microcoding tutorials. http://paulsmith.is-a-geek.net/
vututs/index.html.
[46] XMMS Team. Pagina ocial de XMMS. http://www.xmms.org/.
[47] 4Front Technologies. OSS Programmers guide v1.1. http://www.opensound.
com/pguide/oss.pdf.
[48] Kh. Brandenburg y B. Edler Th. Sporer. The use of multirate lter banks for
coding of high quality digital audio. http://www.iocon.com/resource/docs/
ps/eusipco_corrected.ps, 1992.
[49] Je Tranter. Linux Multimedia Guide. OReilly, http://www.oreilly.com/
catalog/multilinux/, 1996.
[50] Brennan Underwood. Brennans Guide to Inline Assembly. http://www.
delorie.com/djgpp/doc/brennan/brennan_att_inline_djgpp.html, 1996.
[51] Christian Vincenot. An introduction to Linux sound systems and APIs. http:
//desktops.linux.com/desktops/04/08/09/1513255.shtml?tid=25.
[52] Teukolsky William T. Vetterling y Brian P. Flannery William H.Press, Saul A.
Numerical Recipes in C. The Art of Scientic Computing. http://www.library.
cornell.edu/nr/bookcpdf.html.
[53] Rafael Garca; Jes us Gonzalez; Julio Ortega; Macia Anguita y Alberto Prieto. Uso
de la consola Sony PlayStation2 como herramienta de Docencia de Aquitectura
de Computadores.
[54] Konstantin Boldyshev y Francois-Rene Rideau. Linux Assembly HOWTO. http:
//www.tldp.org/HOWTO/Assembly-HOWTO/, 2002.
[55] Julio Ortega Lopera y Jes us Gonzalez Pe nalver. Asignatura de Arquitectura de
Computadores I. http://atc.ugr.es/~jesus/asignaturas/aci/.
[56] Matteo Frigo y Steven G. Johnson. Fast Fourier Transform in the West. http:
//www.fftw.org/.

Ps 2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ps 2

Transféré par

Droits d'auteur :

Formats disponibles

Arquitectura PlayStation2

INDICE DE FIGURAS vii

del punto P. . . . . . . . . 138

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

, tal que = N|.

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ITULO 3. DESARROLLO DEL PROYECTO

ON DEL PROGRAMA SOBRE EL HARDWARE

ON DEL PROGRAMA SOBRE EL HARDWARE

ON DEL PROGRAMA SOBRE EL HARDWARE

ON DEL PROGRAMA SOBRE EL HARDWARE

ALISIS DE LA GANANCIA OBTENIDA 97

ON DEL PROGRAMA SOBRE EL HARDWARE

ITULO 5. FORMATO OGG VORBIS

ITULO 5. FORMATO OGG VORBIS

ON DEL CODEC Y DECODIFICACI

ON DEL PAQUETE 103

ITULO 5. FORMATO OGG VORBIS

ON DEL CODEC Y DECODIFICACI

ON DEL PAQUETE 105

ITULO 5. FORMATO OGG VORBIS

ON DEL CODEC Y DECODIFICACI

ON DEL PAQUETE 107

ITULO 5. FORMATO OGG VORBIS

a) [left window start] [n]/4 [blocksize 0]/4

ON DEL CODEC Y DECODIFICACI

ON DEL PAQUETE 109

ITULO 5. FORMATO OGG VORBIS

ON DEL CODEC Y DECODIFICACI

ON DEL PAQUETE 111

ITULO 5. FORMATO OGG VORBIS

ITULO 5. FORMATO OGG VORBIS

ITULO 5. FORMATO OGG VORBIS

ITULO 5. FORMATO OGG VORBIS

ITULO 5. FORMATO OGG VORBIS

ITULO 5. FORMATO OGG VORBIS