You are on page 1of 158

Arquitectura PlayStation2

Nosotros
´
Indice general
1. Definici´on de objetivos y especificaciones 1
1.1. Definici´on de objetivos y especificaciones . . . . . . . . . . . . . . . . . 1
1.1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2. Proyecto a realizar . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3. Especificaci´on de la aplicaci´on . . . . . . . . . . . . . . . . . . 3
1.1.4. Estado actual y antecedentes . . . . . . . . . . . . . . . . . . . 3
1.1.5. Antecedentes bibliogr´aficos disponibles . . . . . . . . . . . . . . 5
1.2. Introducci´on a la arquitectura de la PlayStation2 . . . . . . . . . . . . 6
1.2.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Caracter´ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.2. Expansi´on y accesorios . . . . . . . . . . . . . . . . . . . . . . 20
1.3.3. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.4. Qu´e 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. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 im´agenes (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. Especificaci´on de las tareas . . . . . . . . . . . . . . . . . . . . 49
3.1.2. M´etodo de programaci´on de la consola . . . . . . . . . . . . . . 50
3.1.3. Programaci´on de las unidades . . . . . . . . . . . . . . . . . . 52
3.1.4. Distribuci´on en las unidades . . . . . . . . . . . . . . . . . . . 54
3.2. Implementaci´on del proyecto . . . . . . . . . . . . . . . . . . . . . . . 54
i
ii
´
INDICE GENERAL
3.2.1. Decodificaci´on de sonido . . . . . . . . . . . . . . . . . . . . . 54
3.2.2. Reproducci´on de sonido . . . . . . . . . . . . . . . . . . . . . . 58
3.2.3. Modelo gr´afico. Procesamiento de audio . . . . . . . . . . . . . 58
3.2.4. Detecci´on de la cadencia de la canci´on . . . . . . . . . . . . . . 66
3.2.5. Reimplementaci´on del plugin gr´afico . . . . . . . . . . . . . . . 67
4. Optimizaci´on del programa sobre el hardware 89
4.1. Uso de la VU0 como ayuda del MIPS . . . . . . . . . . . . . . . . . . 89
4.1.1. Programaci´on in line de la VU0 como preprocesador . . . . . . 89
4.2. Secciones de c´odigo 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. An´alisis de la ganancia obtenida . . . . . . . . . . . . . . . . . . . . . 97
5. Formato Ogg Vorbis 99
5.1. Introducci´on al formato . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.2. Funcionamiento general del decodificador . . . . . . . . . . . . . . . . 100
5.2.1. Configuraci´on del decodificador . . . . . . . . . . . . . . . . . . 100
5.2.2. Pasos de la decodificaci´on . . . . . . . . . . . . . . . . . . . . 101
5.3. Configuraci´on del codec y decodificaci´on del paquete . . . . . . . . . . 103
5.3.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.2. Decodificaci´on de la cabecera y configuraci´on del decodificador . 103
5.3.3. Decodificaci´on y s´ıntesis de paquetes de audio . . . . . . . . . . 107
5.4. Floor 0: configuraci´on y decodificaci´on . . . . . . . . . . . . . . . . . . 112
5.4.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.4.2. Formato Floor 0 . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.5. Floor 1: configuraci´on y decodificaci´on . . . . . . . . . . . . . . . . . . 115
5.5.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.5.2. Formato Floor 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.5.3. Decodificacion de la cabecera . . . . . . . . . . . . . . . . . . . 117
5.5.4. Decodificaci´on del paquete . . . . . . . . . . . . . . . . . . . . 119
5.5.5. C´alculo de la curva . . . . . . . . . . . . . . . . . . . . . . . . 120
5.6. Configuracion y decodificacion de los residuos . . . . . . . . . . . . . . 122
5.6.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6.2. Formato de residuos . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6.3. Decodificaci´on de los residuos . . . . . . . . . . . . . . . . . . 124
5.7. Funciones auxiliares de la implementaci´on . . . . . . . . . . . . . . . . 129
5.7.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6. Ap´endices 133
6.1. Principios de la Inform´atica Gr´afica . . . . . . . . . . . . . . . . . . . . 133
6.1.1. Transformaciones en 2D . . . . . . . . . . . . . . . . . . . . . . 133
6.1.2. Transformaciones en 3D . . . . . . . . . . . . . . . . . . . . . . 136
6.1.3. Proyecciones de visualizaci´on . . . . . . . . . . . . . . . . . . . 137
Glosario I
Bibliograf´ıa V
´
Indice de cuadros
1.1. Rendimiento del GS para las distintas primitivas y opciones disponibles . 12
1.2. Principales caracter´ısticas de la consola comparada con las que ofrecen
sus m´as directas competidoras en el mercado. . . . . . . . . . . . . . . 23
2.1. Organizaci´on de la memoria cach´e. . . . . . . . . . . . . . . . . . . . . 34
2.2. Significado de las siglas de las etapas del cauce de la FPU. . . . . . . . 39
2.3. Significado de las siglas de las etapas de los cauces del EECore. . . . . 39
2.4. Interrupciones que es capaz de controlar el m´odulo INTC. . . . . . . . . 40
2.5. Disponemos de diez canales DMA para realizar transferencias. . . . . . 41
3.1. Antes de especificar la lista de informaci´on, se debe definir el tipo de
primitiva y las caracter´ısticas que tendr´a. . . . . . . . . . . . . . . . . . 82
3.2. Registros existentes para especificar informaci´on asociada a un v´ertice. . 83
iii
iv
´
INDICE DE CUADROS
´
Indice de figuras
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 visualizaci´on ((Iris)) para XMMS . . . . . . . . . . . . . . . . 5
1.5. Esquema de la disposici´on de las unidades, junto a las entradas/salidas 10
1.6. Arquitectura del sintetizador gr´afico . . . . . . . . . . . . . . . . . . . 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 fabricaci´on 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 asociaci´on a una unidad funcional de la consola 29
2.2. Reparto de las tareas m´as 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. Organizaci´on de la cach´e de datos y la cach´e de instrucciones. . . . . . 34
2.7. (a) La conexi´on de la SPR con la CPU y con la memoria externa a
trav´es de DMA, (b) la CPU y la memoria accediendo concurrentemente
al SPR para grabar y leer datos respectivamente. . . . . . . . . . . . . 35
2.8. Disposici´on de distintos tipos de transmisi´on 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 regi´on 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 Im´agenes . . . . . . . . . 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 decodificaci´on 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 ejecuci´on de un programa en las unidades vectoriales . 53
3.4. Criterio a seguir para la distribuci´on inicial de las tareas . . . . . . . . . 54
3.5. Tareas de las que se compone la decodificaci´on 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 configuraci´on 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 funci´on original (a) es distinta de cero en un intervalo T de tiem-
po. Su transformada de Fourier (b) no tiene limitaci´on 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)
est´a definida entre ±f
c
. La potencia fuera de ese rango se desplaza a
dicho rango. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.12. Reordenaci´on de un vector (longitud 8 en este caso) por inversi´on de
bits, (a) entre dos vectores, (b) en un vector . . . . . . . . . . . . . . . 64
3.13. Para poder considerar un espectro de frecuencia suficientemente ´amplio
con un n´ umero bastante reducido de barras a representar, necesitamos
definir 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 buffer 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 c´odigo objeto desde el fichero ensam-
blador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.18. Descomposici´on en bloques del sintetizador gr´afico. . . . . . . . . . . . 78
3.19. Flujo de datos del sintetizador gr´afico. . . . . . . . . . . . . . . . . . . 80
3.20. Desplazamiento realizado en la cola de v´ertices como consecuencia de
un vertex kick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1. Flujo de datos que sigue la implementaci´on del clasificador de frecuen-
cias en conjuntos de frecuencias: (a) en el MIPS, (b) el flujo de datos
perteneciente a la implementaci´on en la VU0. . . . . . . . . . . . . . . 95
4.2. Flujo de datos que sigue la implementaci´on del procesamiento de con-
juntos de frecuencias: (a) en el MIPS, (b) el flujo de datos perteneciente
a la implementaci´on en la VU0. . . . . . . . . . . . . . . . . . . . . . . 97
5.1. Componentes del decodificador de Ogg Vorbis . . . . . . . . . . . . . . 99
5.2. Tipo de solapamiento entre ventanas consecutivas. . . . . . . . . . . . 102
5.3. Reconstrucci´on del floor con dos puntos, y c´alculo de la diferencia en
Y con respecto a la estimaci´on inicial. . . . . . . . . . . . . . . . . . . 116
5.4. Realizamos la correcci´on de la Y anterior y calculamos las nuevas para
32 y 96. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
´
INDICE DE FIGURAS vii
5.5. Proseguimos refinando la curva con los valores asociados, corrigiendo
cuando es necesario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.6. Cuando todos los valores se han calculado, tenemos la reconstrucci´on
de la curva original. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.7. Empaquetamiento de los residuos. . . . . . . . . . . . . . . . . . . . . 123
5.8. Codificaci´on y decodificaci´on 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. C´alculo de la proyecci´on en perspectiva P

del punto P. . . . . . . . . 138
6.5. Proyecci´on perspectiva y proyecci´on paralela, y objetos reales que pro-
ducen dicha proyecci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . 139
viii
´
INDICE DE FIGURAS
Cap´ıtulo 1
Definici´on de objetivos y
especificaciones
En este cap´ıtulo 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 informaci´on que a
este efecto se puede obtener por los distintos medios.
1.1. Definici´on de objetivos y especificaciones
1.1.1. Objetivo
El principal objetivo de este proyecto es demostrar la validez de la arquitectura de
la PlayStation2 como plataforma did´actica sobre la que desarrollar los conocimientos
recibidos sobre distintas arquitecturas.
Tras haber recibido una formaci´on variada sobre la arquitectura x86 principalmente
como m´aximo exponente de los procesadores de prop´osito general, se ha recibido un
complemento pr´actico 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 m´as difundida y usada entre los usuarios. La carencia
radica en el resto de arquitecturas dif´ıciles de conseguir, ya que las microarquitecturas
como PIC, o las FPGA s´ı disponen de asignaturas en las que se recibe la pertinente
instrucci´on pr´actica en la que se ponen de manifiesto las ventajas y desventajas de
dichas arquitecturas. Sin embargo, hay un conjunto de arquitecturas sobre las que no
se realiza ninguna taera pr´actica 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 pr´actico sobre los contenidos te´ori-
cos ayudan a reafirmar y aclarar conceptos. La PlayStation est´a compuesta de varias
unidades, con distintas arquitecturas, como se representa en la Figura 1.1. Su proce-
sador principal, un procesador de prop´osito 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, adem´as de ser un procesador RISC puro, reflejando tambi´en dichas
caracter´ısticas en su repertorio. Adem´as, posee un par de unidades vectoriales VLIW,
que aporta un paradigma de programaci´on distinto al habitual cuando se programa un
procesador de prop´osito general, ya sea programando al nivel m´as bajo o bien a un
nivel superior de abstracci´on. Estas tres unidades, junto a un coprocesador matem´ati-
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 c´alculo de la
m´aquina.
Aparte posee un MIPS I como procesador de gesti´on de entrada/salida y un pro-
cesador gr´afico totalmente independiente dedicado exclusivamente a la representaci´on
gr´afica, 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 aplicaci´on en tiempo real, con lo que deber´ıamos usar
tanto el procesador principal de prop´osito general como las unidades VLIW, a˜ nadiendo
la ejecuci´on de todas de forma sincronizada y en paralelo.
La apliaci´on elegida fue un reproductor con una visualizaci´on sincronizada del
formato Ogg Vorbis [23] de compresi´on de audio, por una serie de razones que expon-
dremos a continuaci´on:
la descompresi´on de sonido es algo muy habitual hoy en d´ıa: consideramos que es
un tema de bastante relevancia en el sentido de ser algo pr´actico, interesante y
suficientemente motivante para tener una val´ıa did´actica frente a otras posibles
aplicaciones que llamen menos la atenci´on del alumnado.
posee unos requisitos de tiempo real bastante importantes: es una aplicaci´on
de tiempo real cr´ıtico, ya que un retraso de menos de un segundo provoca una
interrupci´on en el sonido, siendo f´acil su detecci´on durante las pruebas, y una
prioridad ante todo.
se debe generar una salida auditiva: hace uso del dispositivo de sonido, aumen-
tando la visi´on pr´actica del proyecto al aportar una caracter´ıstica esencial del
mundo multimedia.
hace uso de la unidad gr´afica: no solo necesita el procesamiento de c´alculo y
la reproducci´on del sonido, sino que se necesita profundizar m´ınimamente en
el funcionamiento de la unidad gr´afica para poder mostrar la evoluci´on de la
canci´on, tambi´en 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 compresi´on: nos centramos
en el soporte de un formato de compresi´on libre y sin patentes al contrario que
el resto de formatos de compresi´on con p´erdidas de audio, que est´an sujetos a
patentes, como es el caso del popular MP3.
1.1.3. Especificaci´on de la aplicaci´on
Como hemos esbozado, se trata de realizar una aplicaci´on que sincroniza la repro-
ducci´on de audio con la visualizaci´on de dicho audio. Por tanto, podemos distinguir
tres tareas b´asicas:
decodificaci´on del fichero ogg vorbis en muestras de audio: realiza todo el
proceso de decodificaci´on del fichero comprimido, transformando las tramas de
ogg vorbis en formato de codificaci´on por pulsos interpretables por el sistema de
audio.
reproducci´on del sonido decodificado: una vez decodificado, hay que enviarlo
a la salida de audio a la correspondiente frecuencia, canales y tipo de dato.
visualizaci´on del sonido decodificado: con el sonido a reproducir se debe calcu-
lar una serie de propiedades de ese fragmento que sean representables de forma
gr´afica, para crear una imagen que se corresponda con dicho fragmento.
Es inmediato ver la dependencia de las tareas que tenemos a nuestra disposici´on.
Si representamos de forma gr´afica dicha dependencia, obtenemos el ´arbol de la Figura
1.2. Cada tarea se descompondr´a en subtareas m´as detalladas como se mostrar´a pos-
teriormente en secciones siguientes y en ap´endices a final del documento. En este
apartado trabajaremos desde el punto de vista global de la aplicaci´on, 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 elecci´on. En el uso habitual de cualquier ordenador dom´estico entra
como tarea la reproducci´on de audio. Aunque este proyecto no trata de la compresi´on
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 d´ıa, ya que sin los m´etodos
de codificaci´on de audio, ser´ıa inmanejable la cantidad de informaci´on que tendr´ıa que
4 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
circular por los distintos buses del sistema, y la ingente cantidad de espacio necesario
para poder almacenarlo.
Supongamos que queremos oir una canci´on a una calidad l´ımite de la audici´on
humana. Para ello, necesitamos que est´e en un formato ((calidad CD)), que no es m´as
que 44 100 muestras por segundo, que es el l´ımite psicoac´ ustico del o´ıdo humano, con
muestras de 16 bits y en dos canales (el est´ereo b´asico).
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
par´ametros. Eso hacen 44 100 ∗ 2 ∗ 2 · 176 400 bytes por segundo. Una canci´on
normal de 4 minutos, ocupar´ıa 176 400 ∗ 60 ∗ 4 · 40, 38 Mbytes. Es evidente que es
necesario encontrar alg´ un m´etodo de compresi´on de sonido. Recordemos que esto era
para una muestra en est´ereo. Con un Dolby Digital, que tiene seis canales de sonido,
necesitar´ıamos tres veces m´as de espacio, lo que implica que para la canci´on de 4
minutos, necesitar´ıamos aproximadamente 121, 12 Mbytes.
Hemos expuesto ya el codificador que usaremos, y un esbozo de las razones que
nos han llevado a elegirlo. Este formato, ogg vorbis, comparte gran parte de las ca-
racter´ısticas de cualquier codificador alternativo de semejante prop´osito: posee una
codificaci´on costosa en tiempo, en favor de una descodificaci´on muy r´apida, apta para
una aplicaci´on de tiempo real, como es el caso. Se trata por tanto de un m´etodo de los
denominados asim´etricos, debido a la distinta complejidad que supone su codificaci´on y
su descodificaci´on. Hay otro tipo de algoritmos de compresi´on, llamados sim´etricos, en
los que el tiempo de codificaci´on y descodificaci´on son similares, aunque no alcanzan
las caracter´ısticas de calidad de los asim´etricos. La finalidad de los algoritmos sim´etri-
cos est´a orientada a conferencias en tiempo real, donde se necesita estar codificando y
descodificando de forma constante lo m´as r´apido posible.
Con nuestra elecci´on intentamos dar soporte a un formato de codificaci´on asim´etri-
ca de alta calidad, libre de patentes y con un gran soporte por parte de sus creadores,
tanto a nivel de documentaci´on como a nivel de implementaciones disponibles para
distintas plataformas.
La otra parte de la aplicaci´on conforma una demostraci´on multimedia, algo indis-
pensable hoy d´ıa. Relacionado con nuestra aplicaci´on, encontramos diversas muestras
de lo que pretendemos hacer, principalmente como plugins de visualizaci´on 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 figura 1.4 se muestra uno de estos plugins gr´aficos, concretamente el plugin ((Iris)),
disponible en la direcci´on http://cdelfosse.free.fr/xmms-iris/.
Sin embargo, la parte relativa a la programaci´on en el hardware de la PlayStation2
1.1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES 5
Figura 1.4: Plugin de visualizaci´on ((Iris)) para XMMS
est´a pr´acticamente indocumentada y sin soporte de ning´ un tipo. Aunque hay
aplicaciones desarrolladas para la m´aquina a tratar, ninguna est´a destinada al aprendi-
zaje de la programaci´on, y son poco m´as que meros productos finales, 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 m´aquina.
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 m´ınimas creadas por un grupo de gente sin soporte de Sony de ning´ un tipo
cuyo pasatiempo es desenmara˜ nar los secretos de la m´aquina. El principal problema
que se encuentra es el que las propias palabras de uno de sus m´aximos exponentes
de estas bibliotecas: ((es m´as divertido programar que documentar)). Aunque tenemos
un conjunto de bibliotecas para compilar de forma cruzada a la m´aquina, volvemos a
tener una notable carencia de informaci´on sobre qu´e o c´omo se hace algo. El principal
m´etodo de aprendizaje es el ensayo y error, cosa no muy recomendable para nuestro
objetivo ´ ultimo, que es mostrarle al alumno la programaci´on de una arquitectura
distinta de forma did´actica.
Si disponemos de fondos suficientes, 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 inclu´ıdos. Esto supone una ventaja y una desventaja con respecto al
m´etodo anterior: tenemos m´as soporte e informaci´on para la programaci´on, si bien al-
gunas unidades quedan ocultas por el sistema operativo y las aplicaciones desarrolladas
solo funcionar´an en una PlayStation2 que tenga el kit de Linux instalado.
Un tercer m´etodo descartado desde el inicio es el que recibe un soporte completo
de Sony, tanto a nivel de herramientas de desarrollo como de informaci´on, incluyendo
una m´aquina PlayStation2 especial para desarrollo. El principal inconveniente de este
sistema es la necesidad de estar reconocido como un desarrollador oficial por Sony, cosa
dif´ıcil de conseguir, y m´as para nuestro prop´osito.
1.1.5. Antecedentes bibliogr´aficos disponibles
A pesar de su aparici´on en el mercado hace varios a˜ nos, su enfoque principalmente
orientado a ser un producto final de ocio y consumo destinado al entretenimiento
interactivo de los usuarios hace que la documentaci´on otorgada de forma p´ ublica sea
m´as bien inexistente. Es m´as, Sony ha hecho una especie de campa˜ na en cierta forma
elitista en lo que a su programaci´on se refiere. No otorga soporte de ning´ un tipo
a la programaci´on de la consola si no hay un contrato por medio. En cierta forma
6 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
es comprensible, ya que la clase de programadores que quiere Sony para su consola
son parte de estudios de desarrolladores de videojuegos con suficiente calidad como
para poder crear un producto de deleite que atraiga m´as usuarios a su consola. El
programador ((free-lance)) o el usuario curioso con el suficiente conocimiento como
para querer probar a hacer cosas en la m´aquina por mero placer no son el perfil de
programador que le interesa.
Como un esfuerzo de desarrollo sobre la m´aquina, constru´ıdo 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 b´asicas para la programaci´on de la consola,
as´ı como una peque˜ na serie de tutoriales, c´odigos de ejemplo, demos y algunas he-
rramientas y proyectos que pueden facilitar el inicio de la gente a la programaci´on 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 est´an registrados
como un desarrollador ((serio)) de productos para la PlayStation2, sin compa˜ n´ıas 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, b´asicamente 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 c´odigo fuente ligeramente comentado como principal
fuente de informaci´on, parte de los ejemplos de la biblioteca ps2dev [13].
Para ´este m´etodo, 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. Tambi´en encontramos una breve
introducci´on [36] por Rob Louie al uso del kit de linux en la WEB de GameDev [5],
donde se muestra un programa m´ınimo para proporcionar un cambio de modo gr´afico 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 participaci´on en el VU
Demo Coding Contest [15], una competici´on que realiza Sony cuyo objetivo princi-
pal es confeccionar una demo lo m´as impresionante gr´aficamente usando ´ unicamente
la VU1.
1.2. Introducci´on a la arquitectura de la PlayStation2
1.2.1. Introducci´on
Esta seccci´on pretende ser una introducci´on did´actica a la arquitectura de la con-
sola PlayStation 2. Se tratar´a la arquitectura de forma general para no perder el fin
did´actico y no aburrir al lector y se profundizar´a en cada secci´on que lo requiera me-
diante los ap´endices.
1.2.2. La consola de juegos PlayStation 2
Aunque en esta secci´on nos centraremos en la arquitectura de la PlayStation 2
y en especial en el microprocesador que hace las veces de coraz´on de la misma no
conviene olvidar que ´esta es una plataforma de ocio e interesa ralizar una introducci´on
a sus caracter´ısticas para que el lector nunca pierda la perspectiva. Haremos aqu´ı una
muy breve descripci´on. En el ap´edice ((La consola de juegos PlayStation 2)) se puede
1.2. INTRODUCCI
´
ON A LA ARQUITECTURA DE LA PLAYSTATION2 7
encontrar informaci´on completa y descriptiva acerca de la consola.
La PlayStation 2 sali´o al mercado en el a˜ no 2001
1
al despu´es de la gran espectaci´on
causada en el mercado internacional. Es una plataforma de ocio m´as que una consola,
pues no s´olo est´a orientada a poder jugar con ella, sino que ofrece unas reconociadas
capacidades multimedia. En lo que respecta a los juegos, claramente est´a orientada
juegos 3D. Pero esta plataforma tambi´en permite al usuario reproducir video DVD y
reproducir CDs de audio, lo que la convierte en un centro integral de entretenimiento
dom´estico.
Debajo de la elegante cubierta exterior oscura
2
de la consola PlayStation 2 hay
una completa central electr´onica. Es uno de los equipos de juegos m´as potentes jam´as
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 continuaci´on:
El coraz´on de la PlayStation 2 es el chip Emotion Engine. Este chip, con la ayuda
de la memoria principal y el sintetizador de gr´aficos, permite a PlayStation 2 mover
una cantidad impresionante de pol´ıgonos en la pantalla del televisor (que en conjunto
forman los gr´aficos en pantalla). Estas son sus caracter´ısticas principales:
Chip Emotion Engine multimedia personalizado de 128 bits para CPU
Frecuencia de reloj del Sistema: 294 912MHz
Memoria Cach´e: 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
Actuaci´on del Punto Fluctuante: 6,2 GFLOPS
Transformaci´on Geom´etrica 3D CG: 66 millones de pol´ıgonos por segundo
Descodificador de compresi´on de imagen: MPEG2
El rendimiento del procesador gr´afico de la PlayStation 2 es excelente. Con el
exclusivo chip del sintetizador de gr´aficos que incorpora, sus gr´aficos cobran vida.
Sintetizador gr´afico
Frecuencia de reloj del Sistema: 147MHz
Memoria interna 4MB DRAM
Velocidad del frame buffer: 38,4 Gbytes/seg.
Velocidad de dibujado: 2,4 Gp´ıxeles/s
Con un significado tan simple como ’Entrada/Salida’, los sistemas E/S de PlayS-
tation 2 aseguran un funcionamiento sin problemas de la consola. Adem´as 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 selecci´on de sonido: 2MB
Frecuencia de Salida: Hasta 48 KHz (calidad DAT)
1
Esto fue al mercado internacional, en realidad se llevaba comercializando en Jap´on desde su
presentaci´on el 4 de Mayo del 2000
2
Aunque este mismo a˜ no est´an saliendo al mercado versiones de distintos colores
8 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
En lo que respecta a la capacidad de almacenamiento, la PlayStation 2 incorpora
un DVD con estas caracter´ısticas:
Tama˜ no m´aximo: Doble capa 9GB
Velocidad del Dispositivo DVD-ROM: velocidad aproximada de 4X. CD-ROM:
velocidad aproximada de 24X.
La PlayStation 2 tambi´en 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 p´agina oficial de Sony [7] podemos encontrar adem´as de ´estas caracter´ısticas
un completo cat´alogo de complementos de la consola
1.2.3. La arquitectura de la PlayStation 2
La PlayStation 2 est´a dise˜ nada para conseguir unas altas prestaciones, sobre todo
en lo referente a juegos 3D. Es esta car´acter´ıstica la que va a condicionar toda la
arquitectura. Las caracter´ısticas del cauce general de renderizaci´on 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
cach´e m´as o menos pequea˜ n, el EE se compone de vaios procesadores con peque˜ nas
cach´e e interconectados por r´apidos buses.
Por su diferente arquitectura, la filosof´ıa de programaci´on de una m´aquita y otra
deben ser radicalmetne distintas. Haciendo una a analog´ıa, programar un PC ser´ıa tener
((unos grandes cubos de agua conectados con unos tubitos peque˜ nos)) y programar la
PS2 ser´ıa 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 estableci´o el equipo de desarrollo de Sony y que
debemos tener en cuenta a la hora de comprender correctamente la arquitecura [27].
Est´a orinetada al entretenimiento dom´estico. Esto siginifica que las especificacio-
nes de la m´aquina 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 pr´acticas esto
nos asegura que cualquier aplicaci´on que hagamos basada en el Emotion Engine
va a funcionar all´a donde haya un EE. Esto nos ofrece un ´angulo de visi´on muy
interesante desde el putno de vista comercial y de la investigaci´on.
Potencia para sintetizar emociones. Los gr´aficos 3D de alta calidad requieren ua
gran potencia de c´alculo. Adem´as, los juegos de calidad no solamente tienen unos
buenos gr´aficos, sino que tambi´en manejan una pesada l´ogica y una simulaci´on
de fen´omenos f´ısicos considerable en aras de conseguir realismo. La consola tiene
que dise˜ narse para soortar estos c´alculos.
R´apido renderizado. Para conseguir un buen frame rate en juegos 3D se necesita,
entre otras cosas, poder realizar un renderizado r´apido. La PS2 usa un sintetizador
gr´afico (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 p´ıxeles en la
1.2. INTRODUCCI
´
ON A LA ARQUITECTURA DE LA PLAYSTATION2 9
renderizaci´on
3
Simultaneidad de c´alculos geom´etricos. La consola proveer´a al desarrollador de
la posibilidad de simultanear c´alculos geom´etricos.
Descompresi´on de datos bajo demanda. Una buena soluci´on 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 resoluci´on.
Control de stall y memoria FIFO. Una enorme cantidad de datos intermedos
(display lists) se transfieren constantemente desde el motor geom´etrico hasta
el motor de renderizado. Para controlar este flujo 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 geom´etrico hasta
la memooria y desde la memoria hasta el motor de renderizado usando la memoria
como un buffer.
Procesadores espec´ıficos. Los video juegos usan cadena de procesamiento comu-
nes comom el procesamiento de im´agenes. Adem´as, 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 raz´on se usar´an 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 distribu´ıdo incrementando
el n´ umero de subprocesadores requiere mecanismos de sincronizaci´on y arbitraje.
Para no sobrecargar la CPU con estas, tareas todas las intrucciones (programas)
se transfieren junto con los datos usando un controlador de DMA
4
.
Buffer de camino de datos. En un sistema UMA (Unified 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 buffers de peque˜ na
capacidad (cach´es) 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 eficiencia de las transmisiones se puede mejorar.
Si se quiere sintetizar emociones es necesario realizar una cantidad enorme de
c´alculos.
´
Estas altas prestaciones se cosiguen con un esmerado dise˜ no que busca la
m´axima paralelizaci´on 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
m´as adelante veremos que ´este es la piedra angular para sacarle partido al EE
5
arquitectura de memoria unificada
6
Direct Memoy Access Controler
10 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
Figura 1.5: Esquema de la disposici´on de las unidades, junto a las entradas/salidas
Emotion Engine (EE)
Este es el verdadero coraz´on 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 secci´on.
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 m´as atractiva al usuario final
poseedor de una PS la PS2; ya que el usuario podr´a seguir usando los t´ıtuos que
pose´ıa y puede comprar nuevos t´ıtulos a bajo precio debido al salto de tecnolog´ıa.
Sony no se qued´o ah´ı y mejor´o 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 perif´ericos 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 conexi´on de la
consola a m´ ultiples perif´ericos presentes y futuros tales como teclados, ratones, c´amaras
digitales, impresoras, joysticks, etc. Con respecto al procesador original de la PS esta
versi´on mejorada incorpora el IEEE 1394, una cach´e 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 ejecuci´on, PS o PS2, el IOP funciona a 33 o 36 MHz respectivamente,
7
La llamaremos PS y no como err´oneamente se hace en otros art´ıculos PSOne pues PSOne es una
versi´on de la PS original con un nuevo aspecto externo y una nueva organizaci´on del PCB que dificulta
la instalaci´on de chips. La consola sigue siendo la misma
1.2. INTRODUCCI
´
ON A LA ARQUITECTURA DE LA PLAYSTATION2 11
como se analiza en el art´ıculo publicado sobre la posible aplicaci´on de la consola a fines
did´acticos [53].
El Sintetizador Gr´afico (Graphics Synthesizer, GS)
El GS es el procesador gr´afico de la PS2 y se encarga de dibujar el mundo 3D por
pantala. Para ello traduce las display lists (listas de datos) que le env´ıa el EE.
Es un procesador gr´afico 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 p´ıxeles 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 gr´afico
Los motores de p´ıxeles 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 trav´es
de un bus de sistema, el GS tiene la memoria embebida conectada directamente a los
motores de p´ıxeles con un bus de 2560 bits con lo que se consiguen unas transferencas
12 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
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 buffer se consigue un ancho de banda de 38.4 GB/s
(1024 bits x 150 MHz x 2) y cuando se transmite al texture buffer se alcanza una veloci-
dad de 9.6 GB/s (512 bits x 150MHz). Como vemos en la figura hay una configuraci´on
de doble puerto para acceder simult´aneamente a las dos zonas de memoria. Sin entrar,
por ahora, en m´as detalles y despu´es de haber destacado los elementos distintivos de
la arquitectura del GS vamos a comentar a t´ıtulo descriptivo las capacidades del GS.
M´as a delante, si procede, trataremos el GS en m´as profundidad.
El GS procesa 16 p´ıxeles (32 bit por p´ıxel) por ciclo sin texturas y 8 p´ıxeles
por ciclo con texturas. La tasa de escritura de p´ıxeles m´axima es de 2.4 Gp´ıxeles/s
sin texturas y de 1.2 Gp´ıxeles/s con texturas. La Tabla 1.1 muestra una tabla donde
podemos ver cuantos pol´ıgonos 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 tambi´en un m´odulo encargado de su salida que es el PCRTC.
Este m´odulo puede generar la salida seg´ un el est´andar VESA (hasta 135 MHz como
1.2. INTRODUCCI
´
ON A LA ARQUITECTURA DE LA PLAYSTATION2 13
m´aximo), NTSC o PAL.
Por ´ ultimo a˜ nadir que no todos los monitores pueden conectarse con la PS2. S´olo
aquello que tenga la sincronizaci´on en verde. De todas formas Sony proporciona una
WEB [6] donde podemos encontrar un listado actualizado de monitores probados.
Una puntualizaci´on. En su dise˜ no, la PS2 no est´a hecha para conectarse a un
monitor de alta definici´on; de ah´ı que no se requiera excesivo espacio de almacenamiento
para texturas de alta definici´on, ya que Sony considera que no tiene mucho sentido ver
texturas de alta definici´on televisor con las limitaciones que ´este tiene.
El Procesador de Sonido (SP) [53]
El procesador de sonido est´a formado por 2 DSPs conectados a 2 MB de memoria
integrada y es capaz de manejar hasta 48 canales simult´aneamente a una frecuencia
de reloj de hasta 48 KHz, adem´as de decodificar Dolby, AC3 y DTS.
1.2.4. El Emotion Engine (EE)
Introducci´on
El Emotion Engine es el coraz´on de la Playstation2, se trata de una CPU RISC de
128-bits desarrollada por Sony y por Toshiba
8
. Est´a 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
informaci´on multimedia a altas velocidades, tanto el bus de datos, como la memoria
cach´e y los registros son de 128-bits. El Emotion Engine ha sido la primera CPU
desarrollada completamente de 128-bits. La capacidad de c´alculo en punto flotante
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 flotante (VU0, VU1), un circuito decodificador de MPEG-2 y controladores
DMA de alto rendimiento. Son tres los componentes que pueden realizar operaciones
en punto flotante 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 f´ısicos com-
plicados, y todo tipo de transformaciones geom´etricas 3D. Adem´as 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 sali´o al mercado la PS2. Con la incorporaci´on del decodifcador
MPEG-2 en un chip, es posible procesar en paralelo datos gr´aficos 3D de alta resoluci´on
y im´agenes DVD de alta calidad. Con una capacidad de c´alculo en punto flotante 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 geom´etricas,
que son las que se usan normalmente para el c´alculo de gr´aficos en 3D, el rendimiento
8
En el desarrollo de CELL, el procesador para la PlayStation3 participa tambi´en IBM
14 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
llega a 66 millones de pol´ıgonos por segundo, lo que es con el rendimiento de las es-
taciones gr´aficas usadas en la producci´on de pel´ıculas de animaci´on contempor´aneas a
la consola.
Sobre la implementaci´on [10]
El EE est´a implementado con tecnolog´ıa 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
descripci´on detallada de la metodolog´ıa 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 flotante al
que est´a 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 f´ısicos
de ´este, en tanto que el VU1 se use para simular el mundo 3D. De ah´ı la estructura de
interconexi´on 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 est´a formado por el MIPS r5900 y por la FPU. Su misi´on 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, adem´as de un repertorio
9
Es el que ejecuta el n´ ucleo de Linux
1.2. INTRODUCCI
´
ON A LA ARQUITECTURA DE LA PLAYSTATION2 15
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 predicci´on de saltos.
El r5900 puede usar como coprocesadores a la FPU (cop1) y a la VU0 (cop2) y
para ello existen instrucciones espec´ıficas. As´ı, en los programas que se ejecuratar´an 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 (multiplicaci´on
y acumulaci´on) para realizar operaciones de 32 bits en coma flotante.
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
simulaci´on 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. Adem´as, la VU1 tiene un
m´odulo adicional para realizar operaciones elementales usadas comunmente en opera-
ciones con geometr´ıa 3D. Este m´odulo 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 m´odulo 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. M´as adelante veremos que operaciones que en otros procesadores causar´ıan
einterrupciones en las unidades vectoriales s´olo causan cambios de bits en los registros
de estados; sinedo responsabilidad del programador comprobar dihcos registros.
El m´odulo TIMER contiene 4 contadores de 16 bits que se usan con prop´osito
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 caracter´ıstica se de-
be principalmente a que la labor principal de EE es la produci´on de display lists que
ser´an interpretadas por el GS y ´estas no tienen por qu´e estar siempre en posiciones
de memoria consecutivas. Para realizar estas transferencias el DMAC una una lista de
punteros enlazada.
El m´odulo IPU (Image Data Processor) implementa la descompresi´on por hardware
de im´agenes 2D seg´ une l est´andar MPEG2 o un subconjunto de ´el. Tambi´en realiza
VQ (Vector Quantization). El IPU decodifica los macrobloques, pero la compensaci´on
d e movimiento la tinee que realizar el EE por software con ayuda de las instrucciones
mltimedia. Para una completa informaci´on a cerca del funcionamiento del est´andar
MPEG se puede consultar [34].
El m´odulo 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
´
ON DE OBJETIVOS Y ESPECIFICACIONES
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. Adem´as,
el GIF da el formato adecuado a los datos para que el GS los pueda interpretar ade-
cuadamente (GIFTag) y se los env´ıa.
En el ap´endice ((El EE a fondo)) podemos encontrar informaci´on en profundidad
sobre el EE; as´ı mismo, en el ap´endice ((Las VUs a fondo)) podemos hacer lo mismo
sobre las unidades vectoriales.
Arquitectura de memoria
Para conseguir una mayor eficiencia 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 est´a formada por 2 m´odulos de 16 MBs de memoria
RDRAM a 400 MHz que alcanza una velocidad de transferencia pico de 3.2 GB/s.
Todos los m´odulos del EE pueden acceder a esta memoria a rtav´es de una arquitectura
UMA (Unified Memory Architecture). Te´oricamente, el procesamiento multimedia de
se˜ nales de audio y video de alta resoluci´on 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 buffers 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
r´apida y con unas propiedades especiales denominada Scratchpad RAM (SPR) de 16
KB en el r5900 y dos memorias cach´es de dos v´ıas 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 cach´e de datos cuenta con un
mecanismo de escreitura write back.
Figura 1.9: Arquitectura de las memorias de la PlayStation2
La VU0 puede acceder tambi´en a la SPR para compartir datos y cuenta adem´as
con una cach´e 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 tambi´en 2
MB de memoria independiente.
Los accesos a memoria se hacen a trav´es del DMAC. Existen tres modos de acesos
diferente. En los juegos, el proceso principal es la generaci´on de display lists y ´estas
se calculan con los datos que se acaban de leer de memoria, se env´ıan al GS y no se
vuelven a utilizar. En este tipoo de aplicaciones multimedia donde el flujo de datos es
claramente unidireccional, el uso de cach´es disminue el rendimiento del sistema. Por
eso existe un modo de transferencia de memoria que salta la cach´e (UnCached Mode).
Est´a tambi´en el modo de transferencia est´andar usando la cach´e, 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 buffer de prop´osito especial denominado UCAB (UnCached
Accelerated Buffer).
1.3. La consola de videojuegos PlayStation2
El 13 de Septiembre de 1999, Sony Computer Entertaiment anunci´on el lanza-
miento de la nueva generaci´on de consolas sucesoras de la PlayStation, de la que por
aquellos entonces se hab´ıan vendido m´as de 50 millones
10
. Se anunciaba que la consola
iba a mejorar infinitamente a su predecesora.
Ken Kuratagi fue el principal desarrollador del motor de la consola y podemos
encontrar varios art´ıculos suyos en la bibliograf´ıa.
Fueron muchos los rumores que salieron sobre la consola y su comercializaci´on. Se
lleg´o incluso a decir que la importaci´on estaba congelada en China porque el porderoso
hardware de la consola pod´ıa tener aplicaciones b´elicas y comenz´o a especularse con
posibles adquisiciones masivas de los gobiernos de consolas. Hubo tambi´en 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 peri´odicos. Todos estos rumores
10
Actualmente se han vendido m´as de 73 millones de unidades
18 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
Figura 1.10: Imagen de una PlayStation2
claramente beneficiaban a Sony pues la consola fue ganando cada vez m´as en especta-
ci´on. Por fin, el 4 de Mayo de 2000 la consola PlayStation2, que se puede en la Figura
1.10, sali´o a la venta en Jap´on. S´olo la primera semana se vendieron m´as de 1 mill´ on
de unidades. Hab´ıa 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 caracter´ısticas t´ecnicas 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 est´a orientado a que se puedan ejecutar
este tipo de juegos con las m´aximas prestaciones posibles. La PS2 es la evoluci´on de la
primera consola desarrollada por Sony, la Playstation (PSX). La PSX fu´e 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 pol´ıgonos. Los juegos de la PS2 se
distribuyen en DVD aunque tambi´en es capaz de reproducir los juegos de la PSX en
CDROM. Gracias a la gran capacidad de los DVDs, los juegos de la PS2 est´an repletos
de videos, m´ usica y sonido en 3D. Adem´as de juegos, la PS2 puede reproducir CDs de
audio y pel´ıculas en DVD por tanto es una completa plataforma de entretenimiento.
El panel frontal contiene, adem´as 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 pol´ıtica de compatibi-
lidad tambi´en 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 televisi´on, para televisi´on
de alta defnici´on y salidas de sonido surround, DTS y Dolby Digital 5.1.
1.3. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 19
Los mandos est´andar, Dual Shock 2, tienen 15 botones; todos son anal´ogicos,
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 acci´on de distintos colores (arriba derecha)
11
4 botones de accion, L1 , L2 (frente-izquierda) y R1, R2 (frente-derecha)
2 joysticks anal´ogicos con force-feedback
12
(arriba-izquierda y arriba-derecha)
1.3.1. Caracter´ısticas
En la siguiente lista vamos a morstrar las caracter´ısticas 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
Gr´aficos: Graphics Synthesizer (Sintetizador gr´afico) Frecuencia de reloj: 147,456
MHz VRAM cach´e 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 gr´aficos: 147,456 MHz 75 millones de pol´ıgonos/s max.
Interfaces:
11
Con formas, muy importantes pues son el distintivo comercial de la consola
12
Tecnolog´ıa de retroalimentaci´on de joystck
20 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
• 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
Perif´ericos incluidos: Mando anal´ogico DUALSHOCK2
1.3.2. Expansi´on y accesorios
Las posibilidades de expansi´on en s´ı de la consola son limitadas pues esto ir´ıa en
contra de la pol´ıtica de dise˜ no de mantener la compatibilidad. Las posibles mejoras
del reproductor de DVD que es lo que es m´as susceptible de mejorar con el tiempo
se resuelven a base de nuevas versiones de la consola que actualizan el firmware o
bien cambian la disposici´on de la PCB o introducen m´ınimos cambios que para nada
cambian ning´ un requerimiento. La salida de nuevas versiones de la consola dificultan
tambi´en el uso de modchips para las mismas.
Los modchip son unos chips que modifican 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 ampliaci´on que se le puede hacer a la consola es el kit de Linux. El
kit de Linux para PS2 [14] permite ejecutar una distribuci´on 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
1.3. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 21
un rat´on usb
una tarjeta de red 10/100 Base-T
dos discos DVD
El primero contiene el entorno de ejecuci´on (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 distribuci´on que se puede instalar en el disco duro. La distrubuci´on es una modifici´on
de la RedHat
13
. El kernel de Linux contiene drivers que ocultan el hardware e impiden
el acceso directo a la IOP. Sony proporciona s´olo 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 podr´an 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 est´andar por sus especiales caracter´ısticas es la tarjeta de red.
Respecto al teclado y al rat´on 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 s´olo se puede colocar un disco duro. Estos conocimiento son
interesantes de cara a la construcci´on 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 C´omputo cient´ıfico basado en PS2. Con ´el exploran el uso de PS2 en C´omputo
Cient´ıfico y Visualizaci´on de Alta Resoluci´on. El cluster lo constituyen 70 PS2
14
.
Lo dem´as son accesorios que la consola tiene y que tienen su utilidad para los
juegos [7]. Sony, adem´as de los juegos, tambi´en ha hehco compatibles los perif´ericos de
la PlayStation con la PlayStation2. Pero tambi´en ha desarrollado perif´ericos exclusivos
para la nueva consola:
MANDO ANAL
´
OGICO DUALSHOCK2:
Sony Computer Entertainment ha desarrollado un nuevo
mando anal´ogico DUALSHOCK, de aspecto exactamente
igual al del mando anal´ogico DUALSHOCK original, pero
dotado con controles anal´ogicos sensibles a la presi´on (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 m´as 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 m´as r´apida 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 autenticaci´on y cifrado ((MagicGate)).
13
Hay otra distribuci´on llamada BlackRhino que est´a basada en Debian
14
Sony Linux Kit + MPI, PBS, Maui Scheduler
22 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
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 m´as
art´ıstico, el partido perfecto, o, simplemente, buscando el pu-
ro disfrute de una experiencia compartida.
FANATEC SPEEDSTER 2:
El Speedster2 presenta una combinaci´on de volante y peda-
les compatible con la lista siempre creciente de t´ıtulos para
PlayStation y PlayStation2 de juegos de conducci´on, 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 vibraci´on que le pro-
porcionan dos motores duales integrados en el mismo volante.
BOLSA PLAYSTATION2:
La bolsa oficial de PlayStation2, facilita la movilidad y pro-
tecci´on de esta consola. Adem´as de un amplio espacio para
la PlayStation2 y accesorios, cuenta con un compartimento
con capacidad para guardar 5 DVDs. Este accesorio puede
parecer una tonter´ıa pero es una muestra clara de la implica-
ci´on de Sony en sacar adelante su producto y de dar soporte
original hasta en el m´as m´ınimo detalle.
PORTA CD‘S 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 oficial de Sony
resulta un accesorio casi indispensable para cualquier usuario
de PlayStation2. Podemos hacer el mismo comentario que
antes.
Pese a la dificultad para su programaci´on la PS2 sali´o al mercado con m´as de 30
t´ıtulos disponibles. Los principales desarrolladores de juegos han desarrollado y est´an
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
presentaci´on de la PS2 y las consolas m´as recientes. Los datos proporcionados por Sony
y Microsoft no son realistas, son los datos m´aximos, mientras que los de Nintendo y
Sega est´an medidos en un juego real.
1.3.4. Qu´e le falta a la consola
La verdad es que nos encontramos ante una m´aquina impresionante que nos ofrece
unas capacidades asombrosas. Sin embargo, no todo es tan maravilloso. Este monstruo
es un coloso muy dif´ıcil de gobernar. Sony no provee de unas herramientas adecuadas
1.3. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 23
DC PS2 GAMECUBE XBOX
compa˜ n´ıa 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 gr´afico Power VR
100 Mhz.
Sony GS 150
Mhz.
ATI 200
Mhz.
V-25 300
Mhz.
pol´ıgonos por se-
gundo
3 millones 20 millones 20 millones 100 millones
resoluci´on m´axi-
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
m´odem incorpora-
do
S
´
I / 33.6
Kbps
NO / 56
Kbps
NO / 56
Kbps cable-
modem
NO / 56
Kbps Ether-
net 100Mb
conexi´on 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 caracter´ısticas de la consola comparada con las que ofrecen sus
m´as directas competidoras en el mercado.
24 CAP
´
ITULO 1. DEFINICI
´
ON DE OBJETIVOS Y ESPECIFICACIONES
de desarrollo y aventurarse en la empresa de programar un juego para PlayStation2,
adem´as de ser una empresa intelectualmente muy costosa tambi´en lo es econ´omica-
mente. Primero hay que inscribirse como desarrollardor oficial de Sony y firmar por los
t´ıtulos que se vayan a publicar. Despu´es 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
d´olares americanos, lo que es un coste muy significativo que lo hace prohibitivo para
usuarios particulares y peque˜ nas e intr´epidas empresas que quieran aventurarse en este
mundo, adem´as, un s´olo kit de desarrollo se hace insuficiente 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 m´as 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 m´aquina de tal forma que compilan su
c´odigo y se ejecuta sobre el hardware de esta PS2. Sony s´olo proporciona el hardware y
las librerias,as´ı como asesor´ıa y ejemplos. La escasa documentaci´on de la consola hace
que sea muy dificil programar ´esta. El paradigma de programaci´onde 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 an´alisis de rendimiento oficiales de Sony a fecha de 2003,
entre todos los juegos analizados todos anteriores a esa fecha, s´olo se hac´ıa un uso
del 2 % de la VU0 y s´olo el 56 % de la VU1.
Existen una serie de entornos de desarrollo comerciales pero ´estos suponen un
desembolso econ´omico adicional y no necesariamente una mejora significativa. Entre
ellos los dos m´as conocidos:
1.3. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 25
1. ProDG de Snsys. Tienen diferentes m´odulos, incluido uno muy interesante llama-
do proview que permite mediante el uso del interfaz firewire 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
comunicaci´on 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. Tambi´en 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
c´odigo C y promete paralelizar el solo el c´odigo 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 ofical 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 f´abrica en Salzburg, Austria. Prometen que no existen las
listas de espera para grabar las copias.
La Figura 1.13 muestra el interior de la f´abrica situada Nagasaki, en la que se
puede ver la fabricaci´on del Emotion Engine y del Sintetizador Gr´afico.
Figura 1.13: Planta de fabricaci´on de Sony en Nagasaki.
1.3.5. Algunos comentarios sobre la PlayStation2
((PlayStation 2 est´a 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
´
ON DE OBJETIVOS Y ESPECIFICACIONES
de un mercado de masas sin precedentes, la combinaci´on de impresionantes
gr´aficos digitales, magn´ıfico sonido y v´ıdeo DVD de PlayStation 2, abrir´a las
puertas a una nueva forma de entretenimiento en el hogar)).
— Ken Kutaragi,
presidente y director ejecutivo de SCE Inc.
((Yo me qued´e tan impresionado como vosotros. En cuanto la vi (la con-
sola PlayStation 2), pens´e: ¡esto va rapid´ısimo! No puedo seguir este ritmo,
es alucinante. Lo que han logrado con PlayStation 2 se sit´ ua sencillamente
m´as all´a de toda posibilidad de comprensi´on)).
((Acababa de terminar esta pel´ıcula (La guerra de las galaxias Episo-
dio I: La amenaza fantasma) que es, bueno, tecnol´ogicamente de lo m´as
avanzado Y en eso est´abamos, sinti´endonos extremadamente satisfechos de
nosotros mismos, cuando pusieron este juguetito en la mesa, y result´o ser
todav´ıa m´as potente que lo que hab´ıamos hecho. Lo que a nosotros nos
cost´o a˜ nos alcanzar, estar´a dentro de un a˜ no a disposici´on 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 imaginaci´on y de la narraci´on, el resultado final ser´a fant´astico, y
superar´a nuestras m´as descabelladas fantas´ıas)).
— Phil Harrison,
vicepresidente de SCE America
((Los gr´aficos en tiempo real de PlayStation 2 no tienen limitaciones.
Por eso eleg´ı el color negro, porque representa la infinidad del universo. El
azul representa inteligencia y vida)).
— Teeiyu Goto,
legendario dise˜ nador de PlayStation 2
((La herramienta necesaria para descubrir las nuevas, infinitas y emoti-
vas experiencias que PlayStation 2 nos reserva es la imaginaci´on. No hay
m´etodo correcto ni err´oneo. No hay resultado predecible. Cada viaje es
activo y ´ unico, y depende s´olo de la imaginaci´on del usuario)).
— David Patton,
director de marketing europeo de SCE Europe
((PlayStation 2 est´a lista para revolucionar el sector del entretenimiento
de la misma manera que PlayStation revolucion´o el sector de los juegos.
Namco considera que PlayStation 2 es la plataforma m´as viable para la
explotaci´on de sus capacidades de desarrollo de software; Ridge Racer V y
Tekken Tag Tournament estar´an disponibles en el d´ıa del lanzamiento, y
hay otros apasionantes proyectos en curso)).
— Yashuhiko Asada,
director general de Namco
1.3.6. Curiosidades
Una prueba m´as de que la consola PS2 est´a en auge pese a sus ya 4 a˜ nos de
mercado es que ha entrado tambi´en en ella la fiebre del modding. Esto significa que
existe toda una comunidad interesada en realizarle mejoras. Podemos encontrar m´as
1.3. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 27
informaci´on sobre esto en [9]. La Figura 1.14 muestra los l´ımites de la imaginaci´on 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
´
ON DE OBJETIVOS Y ESPECIFICACIONES
Cap´ıtulo 2
Estudio del hardware: el
Emotion Engine
En este cap´ıtulo realizaremos un estudio a fondo del centro de procesamiento
principal de la consola: el Emotion Engine, centro neur´algico de la potencia de com-
putaci´on de la que se ha dotado. Veremos los aspectos m´as relevantes de las unidades
que conforman este n´ ucleo computacional.
2.1. Apendice. El EE a fondo
2.1.1. Introducci´on
El Emotion Engine est´a dise˜ nado para hacer funcionar a la perfecci´on juegos 3D.
Para ello, en vez de empe˜ narse los ingenieros en mejorar estructuras de procesadores
de prop´osito general decidieron hacer un procesador espec´ıfico para lograr mejor ren-
dimiento. La principal carga de procesamiento de un juego 3D es el renderizado de
las im´agenes. 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 asociaci´on a una unidad funcional de la consola
Este cauce marca la arquitectura de la consola y explica la topolog´ıa de los buses.
El cauce de renderizado es un cauce de datos multimedia en una ´ unica direcci´on 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
descompresi´on de video o el Audigy 2 de Creative lo es para el tratamiento del audio.
Como hemos visto en la figura 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 flotante al que est´a 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 f´ısicos de ´este, en tanto que el VU1 se use para simular el mundo 3D.
De ah´ı la estructura de interconexi´on que tienen los 3 procesadores. Podemos ver en
la Figura 2.2 esta interconexi´on y distribuci´on.
Figura 2.2: Reparto de las tareas m´as habituales entre el hardware de la consola.
Estas son las partes principales de las que se compone el EE. Las describiremos
en detalle a continuaci´on. Antes veamos la Figura 2.3 que representa un esquema que
trata m´as en profundidad el procesador Emotion Engine, sobre el que explicaremos sus
particularidades.
2.1.2. Mapa de memoria
Adem´as 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 Secci´on 2.2 del manual de usuario del Emotion Engine[28] podemos encontrar
cual es la direcci´on espec´ıfica de los registros.
2.1.3. El EE Core
El EE Core es la denominaci´on 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
espec´ıficas 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
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
de funcionamiento de las unidades vectoriales en el apartado dedicado a ellas. Por las
especiales caracter´ısticas de las VUs nosotros denominaremos EECore s´olo al conjunto
formado por el MIPS (junto con sus memor´ıas locales y cach´es) 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 precaptaci´on y de movimiento condicional), adem´as se le han a˜ nadido 107 instru-
ciones SIMD de 128 bits para el procesamiento multimedia paralelo[26]. El EECore
cuenta tambi´en con una bater´ıa 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 multiplicaci´on de tres operandos.
Dentro del esquema que hemos visto anteriormente el EECore se compone del
MIPS r5900 junto con sus cach´es, los 16 KBs de memoria Scratchpad RAM (SPR) y
la FPU. Tiene 16 KB de cach´e de instrucciones (I$) y 8 KB de cach´e de datos (D$),
adem´as cuenta con 32 registros de prop´osito general de 128 bits. Tiene 32 bits para
su espacio de direcciones, tanto f´ısicas como l´ogicas. En su unidad de gesti´on de me-
moria (MMU) implementa una TLB (Translation Look-Aside Buffer) completamente
asociativa de 48 entradas (96 p´aginas). El micro soporta instrucciones de carga no
bloqueantes. En general, podemos aplicar al r5900 cualquier documentaci´on sobre la
arquitectura MIPS-III salvo por las instrucciones espec´ıficas para acceder a los copro-
cesadores, la multiplicaci´on de tres operandos que soporta, la extensi´on 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 direcci´on de la instrucci´on que se est´e ejecutando. Esta unidad tambi´en
contiene una cach´e de 64 entradas denominada Branch Target Address Cache (BTAC,
Cach´e de direcciones destino de saltos ) que se usa para la predicci´on de saltos.
MMU, Memory Management Unit (Unidad de Control de Memoria)
Como ya dijimos antes implementa una TLB (Translation Look-Aside Buffer) com-
pletamente asociativa de 48 entradas (96 p´aginas). Implementa tablas separadas para
datos y para instrucciones. Usa 32 bits para direccionar direcciones f´ısicas, lo que co-
rresponde a un espacio de direcciones de 4 GB y 32 bits para direccionar direcciones
l´ogicas o virtuales. Las direcciones virtuales est´an formadas por un n´ umero de p´agina
(VPN, Virtual Page Number) y un desplazamiento (offset). Los tres bits m´as signifi-
cativos del VPN identifican el modo de operaci´on, esto es, el taama˜ no de la p´agina,
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 operaci´on est´andar 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.
Cach´es y Scratchpad RAM (SPR)
Implementa una cach´e de datos de 8 KB y una cach´e de instrucciones de 16 KB.
Adem´as de los 16 KB de SPR para manipular muy r´apidamente grnades estructuras
de datos y de un buffer para las transmisiones de datos contiguos r´apidamente sin usar
cach´e: UCAB (UnCached Accelerated Buffer).
2.1. APENDICE. EL EE A FONDO 33
Figura 2.5: Estructura interna del EECore
34 CAP
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
Las cach´es son de dos v´ıas completamente asociativas y tienen una longitud de
l´ınea de 64 bytes, implentan una pol´ıtica Write-back y permiten el bloqueo de l´ıneas
de cach´e y lecturas no bloqueantes. Se tienen que usar las instrucciones de cach´e para
mantener la coherencia. Las cach´es se organizan seg´ un la Tabla 2.1.
Cach´e Tama˜ no Organizaci´on
Datos 8 KB 64 bytes 64 entradas 2 v´ıas
Instrucciones 16 KB 64 bytes 128 entradas 2 v´ıas
Cuadro 2.1: Organizaci´on de la memoria cach´e.
En la Figura 2.6 vemos la organizaci´on de la cach´e de datos y la organizaci´on
de la cach´e de instrucciones, respectivamente. Podemos consultar exhaustivamente la
disposici´on de las cach´es en [26]:
Figura 2.6: Organizaci´on de la cach´e de datos y la cach´e de instrucciones.
Todas las lecturas que se hacen de memoria se hacen de cach´e. S´olo se lee de
memoria principal cuando se usan isntrucciones para transparas la cach´e, cuando no
est´a la l´ınea de cach´e que se necesita o cuando ´esta es inv´alida.
Algunas aplicaciones requieren una memoria embebida de alta velocidad que se
pueda acceder con lecturas/escrituras convencionales para manejar eficientemente 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 cach´e de datos sin etiquetas. Est´a configurada como 1024
x 128 bits. Usa el mismo camino de datos que la cach´e de datos, lo que significa que
2.1. APENDICE. EL EE A FONDO 35
en ciclo determinado de CPU la CPU puede acceder bien a la SPR, bien a la cach´e de
datos, no a las dos simultaneamente. La SPR est´a mapeada en el espacio de direcciones
virtuales. Lo vimos en la secci´on de Mapa de Memoria un poco m´as 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 (adem´as de las instrucciones de lectura/carga). El espacio
de pagina de ls SPR es de 16 KB. Los 14 bits menos significativos de la direcci´on virtual
se usan para indicar la direcci´on en la SPR, en tanto que los 18 bits m´as significativos
se usan para acceder a la TLB y determinar si un bloque de 16 KB est´a mapeado en la
SPR o no. Para direrenciar entre los espacios de memoria (puede estar en la cach´e 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 env´ıa una se˜ nal especial a la CPU
de escritura en la SPR con una direcci´on de SPR de 10 bits. Los datos se colocan el
el CPU BUS. Despu´es la CPU muestrea los datos del bus y los escribe en la direcci´on
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 est´a 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 planificaci´on por parte
de la CPU.
Figura 2.7: (a) La conexi´on de la SPR con la CPU y con la memoria externa a trav´es
de DMA, (b) la CPU y la memoria accediendo concurrentemente al SPR para grabar
y leer datos respectivamente.
El UCAB (UnCached Accelerated Buffer) es una peque˜ na cach´e de s´olo lectura
que se usa en las transacciones de datos que se saltan la cach´e y que sirve para
optimizar las transmisiones y reducir el tr´afico del bus. Acelera las transmisiones de
datos desde direcciones contiguas de memoria. Su disposici´on se muestra en la Figura
2.8, comparada con otros tipos de transferencia.
Issue logic
Esta unidad se encarga de colocar un m´aximo de dos intruciones por ciclo en cada
cauce f´ısico que le corresponda.
36 CAP
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
Figura 2.8: Disposici´on de distintos tipos de transmisi´on a memoria.
Registros de la CPU
Los registros del EECore amplian el conjunto general de registros que define la
arquitectura MIPS [24]. Cuenta con los siguientes registros:
32 registros de 128 bits registros de prop´osito 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 especificar la
cantidad de desplazamietno en las instrucciones de desplazamiento. Es de 32 bits
y para acceder a ´el se han tenido que definir nuevas instrucciones.
El Contador de Programa (PC).
Notar que los 64 bits m´as significativos de los GRPs s´olo se usan con las instruc-
ciones espec´ıficas del EECore (lectura/carga de qword e instrucciones multimedia). Los
registros LO y HI tambi´en se han ampliado a 128 bits. Los 64 bits menos significativos
de estos registros (HI0/LO0) se corresponden exactamente con sus hom´ologos de 64
bits HI y LO. Los 64 bits m´as significativos (HI1/LO1) s´olo se usan para las nuevas
instrucciones de multiplicaci´on y divisi´on. Estas instrucciones son MULT1, MULTU1,
DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1, MTLO1.
Los registros de prop´osito general r0 y r31 son especiales.
El r0 est´a siempre puesto por hardware a valor cero. Cuando se necesita un cero
en una operaci´on se puede usar este registro. Tambi´en se puede usar se realiza
una operaci´on 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 multiplicaci´on entera, de la multiplicaci´on y acumulaci´on entera y de
la divisi´on 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
2.1. APENDICE. EL EE A FONDO 37
El registro SA especifica la cantidad de desplazamiento cuando se usa la instrucci´on
QFSRV. El registro es espec´ıfico del EECore y se necesita salvar como parte del contexto
del procesador si procediera. Existe una instrucci´on espec´ıfica que se ha creado para
cargar intercambiar datos entre el SA y los GPRs.
El contador de programa (PC) mantiene la direcci´on de la instrucci´on que se
est´a ejecutando. El PC se incrementa autom´aticamente en pasos de 4 cuando ins
instrucci´on se ejecuta. Cuadno se produce un salto el PC se actualiza a la nueva
direcci´on destino. Cuando ocurre una excepci´on se cambia el valor del PC a la direcci´on
del vector que maneje las excepciones.
Cauces f´ısicos
Los cauces f´ısicos ejecutan las operaciones de las intrucciones. El EECore tiene 6
cauces f´ısicos que describiremos a continuaci´on:
1. Cauces I0 y I1. Son los cauces que contienen la l´ogica para soportar la aritm´etica
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 configuran
ambos cauces din´amicamente 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 l´ogica para soportar las
instrucciones Load y Store.
3. Cauce BR. El cauce BR (Branch Pipe) contiene la l´ogica para ejecutar instruc-
ciones de salto.
4. Cauce C1. El cauce C1 contiene la l´ogica para soportar el coprocesador de punto
flotante FPU (COP1).
5. Cauce C2. l cauce C1 contiene la l´ogica para soportar el coprocesador vectorial
VU0.
L´ogica de bypass
La l´ogica de bypass es una unidad que toma los datos de los GPRs y del Bus de
Resultados y los env´ıa a los cauces y a la SPR.
Buffer de WriteBack (WBB)
El buffer 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
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
La Unidad de punto flotante (FPU, Floating-Point Unit)
La unidad de punto flotante es un coprocesador fuertememte acoplado al MIPS
del EECore. Soperta el formato de precisi´on simple definido en el est´andar IEEE 754.
No soporta NaNs ni infinitos. 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 prop´osito general (FPRs) de 32 bits a los que puede acceder
la CPU meidante instrucciones espec´ıficas. Hay 32 registros de control de punto flotante
de los cuales s´olo dos est´an implenetados. Adem´as hay un registro adicional de 32 bits
que se usa en las operaciones de multiplicaci´on-acumulaci´on. Est´an estructurados como
muestra la Figura 2.9.
Figura 2.9: Registros que conforman la Unidad de Punto Flotante
La FPU s´olo soporta redondeos a cero. No sopora ning´ un otro tipo de redondeo
definidos en el est´andar IEEE 754.
El cauce de la FPU consta de 8 etapas, como antes, cada una con dos fases.
Las instrucciones del COP1 se ejecutan simult´aneamente 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
2.1. APENDICE. EL EE A FONDO 39
S´ımbolo Etapa Fase
1I Captaci´on de instrucci´on Fase 1
2I Captaci´on de instrucci´on Fase 2
1Q Decodificaci´on de instruccion Fase 1
2Q Decodificaci´on de instruccion Fase 2
1R Captaci´on de los registros Fase 1
2R Captaci´on de los registros Fase 2
1T Captaci´on de los registros en COP1 Fase 1
2T Captaci´on de los registros en COP1 Fase 2
X Ejecuci´on 1
Y Aritm´etica/ALU1
Z Aritm´etica/ALU2
1S Escritura de resultados Fase 1
2S Escritura de resultados Fase 2
Cuadro 2.2: Significado 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,
decodificar y ejecutar un m´aximo 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.
S´ımbolo Etapa Fase
1I Captaci´on de instruccion Fase 1
2I Captaci´on de instruccion Fase 2
1Q Decodificaci´on de instruccion Fase 1
2Q Decodificaci´on de instruccion Fase 2
1R Captaci´on de los registros Fase 1
2R Captaci´on de los registros Fase 2
1A Ejecuci´on Fase 1
2A Ejecuci´on Fase 2
1D Captaci´on de los datos Fase 1
2D Captaci´on de los datos Fase 2
1W Escritura Fase 1
2W Escritura Fase 2
Cuadro 2.3: Significado 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
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
en el manual del Emotion Engine [26]. Este procesador es muy did´actico 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 m´odulo 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 interrupci´on, el INTC la gestiona y
env´ıa al EECore la se˜ nal de interrupci´on INT0. Si es el DMAC el que la produce, ´el
mismo env´ıa 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 Detecci´on deuna interrupci´on en el GS
1 INT SBUS Detecci´on de una interrupci´on en un perif´erico del
SBUS
2 INT VB ON Comienzo del V-Blank
3 INT VB OFF Final del V-Blank
4 INT VIF0 Detecci´on de un VIFCode en el VIF0 con el bit de
interrupci´on activado o una excepci´on en el VIF0
que activa una interrupci´on (stall)
5 INT VIF1 Detecci´on de un VIFCode en el VIF1 con el bit de
interrupci´on activado o una excepci´on en el VIF1
que activa una interrupci´on (stall)
6 INT VU0 Ejecuci´on de una micro instrucci´on en la VU0 con
el bit de interrupci´on activado o la ocurrencia de
una interrupci´on en la VU0 (stall)
7 INT VU1 Ejecuci´on de una micro instrucci´on en la VU1 con
el bit de interrupci´on activado o la ocurrencia de
una interrupci´on en la VU1 (stall)
8 INT IPU Detecci´on en el IPU del final de los datos o una
excepci´on
9 INT TIMER0 Condicio´on de interrupci´on del contador 0
10 INT TIMER1 Condicio´on de interrupci´on del contador 1
11 INT TIMER2 Condicio´on de interrupci´on del contador 2
12 INT TIMER3 Condicio´on de interrupci´on del contador 3
13 INT SFIFO Detecci´on de error durante una transferencia SFIFO
14 INT VU0WD Interrucpci´on que se produce cuando la VU0 lleva
en el estado RUN mucho tiempo (ForceBreak)
Cuadro 2.4: Interrupciones que es capaz de controlar el m´odulo INTC.
Para m´as informaci´on, consultar el Manual de Usuario [28] proporcionado por Sony
junto al kit de linux.
2.1.5. TIMER
El m´odulo TIMER es un m´odulo 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 overflow. Hay un flag en el registro de estado
que indica cual ha sido la causa que ha producido la interrupci´on. 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 interrupci´on SBUS.
2.1. APENDICE. EL EE A FONDO 41
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 m´ınima que se transfiere es la cuaddruplepalabra (qword, 128
bits). Las transferencia con el DMAC se especifican en base a sus direcciones f´ısicas y
no se hace traducci´on alguna con la TLB.
Las transferencias desde y hacia un perif´erico se realizan en paquetes de 8-qwords
denominadas slices. Hasta que la transferencia de un slice no se completa el canal que
est´a usando la transferencia permanece ocupado y monopoliza los derechos del bus.
Como hay m´as de un bus se permiten transferencias concurrentes por los distintos
buses, adem´as, es to no impide que la CPU acceda a memoria principal. Existe la
funci´on 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 transfieren tiene que estar alineados a fronteras de 128 bits. Hay dos
modos de transferencia por los canales del DMA:
1. Modo de transferencia f´ısico (Physical Transfer Mode) que es fijo para cada canal.
2. Modo de transferencia l´ogico (Logical Transfer Mode) que es seleccionable en
cada canal.
Dentro de cada modo hay distintas categor´ıas. Las vamos a enumerar y a describir
brevemente.
Modo de transferencia f´ısico (Physical Transfer Mode). Se divide en dos tipos:
1. Modo r´afaga (Burst Mode). Es este modo los datos se tranfieren en grupos.
2. Modo Slice (Slice Mode). En este modo los datos se transfieren en paquetes
de 8 qwords en conjunci´on con otros canales de DMA.
42 CAP
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
Modo de transferencia l´ogico (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 transfiere a un perif´erico o viceversa. Es
una transferenca DMA normal. Transfiere desde una direcci´on de origen a
una destino tantos bytes consecutivos como se indiquen. Las transferencias
se dividen en slices (8 qwords) si est´a seleccionado el Slide Mode o de una
sola vez si est´a seleccionado el Burst Mode.
2. Modo Cadena (Chain Mode). En este modo se transfiere desde posiciones de
memoria no contiguas. Cada bloque que se transfiere contiene informaci´on
a cerca de la direcci´on del siguiente bloque a transferir en una estructura
denominada DMATag. El DMAC realiza los cambios de direcci´on 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 transfienren datos
entre la SPR y la memoria principal. Es un modo especial de transferencia
en el que se puede transferir un rect´angulo dentro de una regi´on 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 regi´on 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 buffer circular que hay implementado en me-
moria principal en conjunci´on con los DMATag correspondientes. Este buffer circular
se llama MFIFO (MemoryFIFO).
Cuando hay m´as de una petici´on simult´anea de DMA, las peticiones se ordenan
seg´ un la prioridad siguiente de los canales:
2.1. APENDICE. EL EE A FONDO 43
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) Interrupci´on del canal, (ii) interrupci´on de DMA debida a un stall, (iii)
interrupci´on debida a que la Memoria FIFO se queda vac´ıa y (iv) interrupci´on 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 env´ıa con su formato adecuado al GS. Normalmente los datos que se env´ıan al
GS los genera la VU1 (simple stream) o el EECore en conjunci´on con la VU0 (complex
stream). Aunque estos datos se generan y se env´ıan 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 instrucci´on de la VU1 que
realiza este envio es XGKICK. Si se produjera esta instrucci´on antes de que se
terminara otra transferencia por el mismo camin, se produccir´ıa un stall. Si la
transferencia se produjera mientras ocurren otras por cualquiera de los otros dos
caminos, se encolar´ıa. S´olo 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 transfieren 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
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
Estos tres canales tienen un esquema de prioridad, su prioridad es PATH1 >
PATH2 > PATH3, lo que es l´ogico 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 b´asica de transferencia con el GIF es una primitiva del GS que consiste
en una GIFtag y a continuaci´on datos. Las transferencias se hacen en paquetes que
consisten en dos o m´as primitivas. El GIFtag tiene 128 bits y especifica el tama˜ no y la
estructura de los datos que vienen a continuaci´on. Su estructura es:
NLOOP: Bits 0 - 14, tama˜ no de la primitiva, tambi´en indica si es empaquetada,
o imagen.
EOP: Bit 15(End Of Packet) Informaci´on de si vienen m´as 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. Despu´es del GIFTag los datos pueden estar en tres modos distintos que especifican
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 direcci´on especificada 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 funci´on 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 especificar dos modos de
transmisi´on, continuo e intermiente. Si se especifica el intermitente, tras cada slice
que se transmita se sondean los otros caminos y se les da la preferencia si necesitan
transmitir (son de m´as prioridad).
Las transferencias por el PATH 3 pueden ser tambi´en enmascaradas. Hay dos
formas de hacer esto, bien a trav´es de la instrucci´on MSKPATH3 o bien a trav´es del
campo M3R en el registro GIF MODE.
2.1. APENDICE. EL EE A FONDO 45
El registro de privilegios del GS est´a directamente mapeado en el espacio de di-
recciones del EECore.
Cuando se hace una transferencai al GS el GIF especifica en cual de los dos
contextos posibles del GS se almacena.
2.1.8. Unidad de procesamiento de im´agenes (IPU, Image Data
Processor
El IPU es una unidad de procesamiento de imagenes con capacidad para realizar
la decodificaci´on de los macrobloques del est´andar MPEG2 [34], la conversi´on RGB,
la cuantizaci´on de vectores y la descompresi´on de chorros o cadenas de bits (bits
streams). No posee ning´ un buffer especial y comparte la memoria principal con los
otros procesadores a tiempo compartido. Esto significa que los datos se leen, se colocan
en memoria principal, se decodifican y se vuelven a colocar decodificados en memoria
principal. La imagen decodificada se transfiere al GS que la usa como textura o como
datos de animaci´on.
Figura 2.14: Estructura de la Unidad de Procesamiento de Im´agenes
El IPU implementa las siguientes capacidades:
Decodificaci´on est´andar de bit streams. El IPU interpreta y decodifica por hard-
ware el bit stream est´andar de MPEG2. La compensaci´on de movimiento no la
realiza el IPU. La tiene que realizar el EECore ayudado por las instrucciones
multimedia.
Decodificaci´on de macrobloques. El IPU decodifica los macrobloques que van en
el bit stream y los convierte a RGB. Esta es una de las capas de MPEG2.
Cuantizaci´on de vectores. El IPU puede convertir una imagen a color deodificada
directamente a una paleta de colores indizada de 4 bits haciendo la cuantizaci´on
de vectores dada por CLUT (Color LookUp Table). Esta tecnica se usa para
proveer el patr´on de texturas que la t´ecnica CLUT requiere. Tambi´en se usa
cuando la capacidad del area de texturas est´a 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 decodificado y de un coeficiente.
Las funciones b´asicas del IPU son:
46 CAP
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
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 decodificaci´on de MPEG2 empleando el IPU.
2.1. APENDICE. EL EE A FONDO 47
1. Decodificar los macrobloques MPEG2.
2. Extraer el bit stream MPEG2.
3. Decodificar el bit stream MPEG2.
Esquem´aticamente, el proceso de descompresi´on de video MPEG2 usando el IPU se
muestra en la Figura 2.16.
2.1.9. SIF, Sub-CPU Infertace
El SIF el un m´odulo 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 dem´as perif´ericos de entrada/salida de
la consola. Para realizar las transferencias con los dispositivos, el DMAC trabaja en
cooperaci´on 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 metainformaci´on a cerca de la direcci´on de los datos en el espacio
de memoria del IOP, de la direcci´on 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 direcci´on de su espacio de memoria y carga los datos con el tama˜ no
especificado desde la direci´on le´ıda hasta la SFIFO. Despu´es, el DMAC del EE vuelve
a leer el DMATag para obtener la direcci´on 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
´
ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE
Figura 2.18: Flujo en una transferencia de datos entre el IOP y la memoria del Emotion
Engine.
Cap´ıtulo 3
Desarrollo del proyecto
Explicaremos con detalle las alternativas de las que disponemos para realizar el
proyecto, as´ı como una gu´ıa paso a paso de la soluci´on que hemos adoptado definitiva-
mente, a fin de servir como manual did´actico. Iremos comentando al par las decisiones
de dise˜ no y de implementaci´on, as´ı como los posibles problemas encontrados, y la
soluci´on adoptada.
3.1. Desarrollo del proyecto
3.1.1. Especificaci´on de las tareas
Como vimos en la Figura 1.2, inicialmente hemos organizado el proyecto en tres
tareas bien definidas. Ahora comenzaremos el desarrollo de cada parte, y comentaremos
los problemas encontrados as´ı como las soluciones propuestas y la soluci´on adoptada.
Primero debemos observar el hardware disponible, y la funcionalidad de cada parte,
para poder determinar una distribuci´on lo m´as l´ogica 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 c´alculos
computacionalmente pesados que se aplican constantemente y de forma invariante a
la geometr´ıa.
Figura 3.1: Uso normal de los procesadores que conforman el Emotion Engine
49
50 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
3.1.2. M´etodo de programaci´on 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 oficiales 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 c´omoda para facilitar la realizaci´on de
pr´acticas 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 continuaci´on.
Programaci´on 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
configuraci´on adicional de software ni hardware en la consola. Se realiza mediante la
creaci´on de los ejecutables usando compilaci´on cruzada desde el PC.
Los ficheros necesarios pueden encontrarse en el proyecto ((ps2stuff)) [8] del portal
de linux para la Playstation2 [14]. B´asicamente se necesitan los siguientes elementos:
Compilador para el procesador central MIPS (el Emotion Engine)
Ensamblador para las unidades vectoriales (las VU)
Con ´estos elementos configurados de forma adecuada podremos generar ejecu-
tables tanto para el procesador MIPS como para las unidades vectoriales VLIW. El
principal inconveniente que presenta este m´etodo es la forma de hacer que el ejecuta-
ble generado sea cargado por la consola. Debido a la protecci´on 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 implantaci´on de un ((mod-chip))
para paliar esta limitaci´on. De nuevo surge un inconveniente con esta v´ıa de trabajo.
Grabar un CD-ROM cada vez que vayamos a probar el programa supone un gasto
considerable en material, adem´as 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 v´ıa para enviar el ejecutable a la m´aquina pasa a trav´es de la aplicaci´on
conocida como ((Naplink [40])), un programa de transmisi´on de ficheros entre la consola
y un ordenador, mediante una arquitectura cliente-servidor, a trav´es 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 comunicaci´on mediante el puerto USB entre
el PC y la consola, de forma que la consola ejecuta el ejecutable que se le transfiere desde
el PC, y permite mostrar mensajes de depuraci´on 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 opci´on requiere tener modificada cada consola, con la p´erdida de garant´ıa
que ello supone. Adem´as necesita tener al menos un PC para programar las consolas, y
supone programar a un nivel demasiado cercano a la m´aquina, pues no disponemos de
ning´ un tipo de facilidad a la hora de la depuraci´on, requisito principal en un ambiente
educativo. No hay que olvidar que queremos iniciar la programaci´on al alumnado, y
para ello debemos permitirle una cierta sencillez de depuraci´on para evitar la apat´ıa
que produce la frustraci´on de la impotencia.
Tambi´en 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
Programaci´on mediante el kit de linux
Con esta opci´on,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
oficial de Sony. Tambi´en recibimos una distribuci´on especial de linux para la arqui-
tectura MIPS de la PlayStation2, basada en Red Hat, y lo suficientemente 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 programaci´on, adem´as de propor-
cionar un entorno familiar de desarrollo. Al estar trabajando bajo un linux, toda la
funcionalidad de este sistema operativo est´a disponible, as´ı como sus herramientas m´as
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 reducci´on de la complejidad que supone enfrentarse a un nuevo tipo de hardware,
pues al menos el entorno de desarrollo se mantiene m´as 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 est´a ejecut´andose ´ 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 ver´a afectado por el
sistema operativo. Tan solo lo que ejecute el procesador principal competir´a 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 espec´ıfico para dichos
fines, mientras que para el MIPS tendremos el compilador nativo, que a efectos pr´acticos
resultar´a ser semejante al cruzado, ya que ambos estar´an generando c´odigo objeto
de un MIPS III modificado. En esta ocasi´on, 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))), etc´etera. Supone una capa mayor de abstracci´on entre el
hardware y el usuario, pero no limita por ello la capacidad de utilizaci´on en cuanto a
formaci´on did´actica se refiere.
52 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
La ´ unica limitaci´on que encontramos a nivel de programaci´on es la unidad de con-
trol de entrada salida de perif´ericos, tambi´en conocido como IOP, ya que los drivers
del n´ ucleo de la distribuci´on 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
limitaci´on para nuestros fines, ya que no existe un gran inter´es did´actico en acceder
al lector de DVD o a los mandos de control de forma cercana al hardware, y la abs-
tracci´on 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 fichero 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 distribuci´on, por contra, quiz´as sea un punto m´as delicado a tratar, aunque no
repercute en la funcionalidad did´actica del material. Al haber sido desarrollado bajo
el kit de linux, la aplicaci´on necesita de bibliotecas y soporte del sistema operativo
que solo se encuentran disponibles en un kit de linux. Por tanto, cualquier aplicaci´on
desarrollada bajo un kit de linux solamente funcionar´a en otra consola en la que se
disponga de un kit de linux, siendo imposible compilar la aplicaci´on para que funcione
de forma ((stand-alone)).
No podemos olvidar el descargo monetario que supone esta opci´on que, si bien
no es comparable a la opci´on que hemos descartado directamente, supone un gasto
adicional que no posee la opci´on anteriormente descrita. Tambi´en hay que recordar que
recibe soporte de Sony, algo que se pierde casi con total seguridad al intentar usar el
m´etodo ((stand-alone)) debido a la necesidad de implantar un ((mod-chip)).
Elecci´on del sistema de programaci´on
Teniendo en cuenta las ventajas y desventajas proporcionadas por cada m´etodo,
conclu´ımos que la mejor opci´on ser´ıa disponer de una facilidad de depuraci´on y de-
sarrollo por encima del rendimiento, ya que se trataba de comenzar desarrollos en la
m´aquina, y no de realizar una producci´on de alta calidad. Por tanto, pensando en el
prop´osito 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. Programaci´on 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 prop´osito general. Consideramos
que el c´odigo objeto generado es suficiente ´optimo como para descartar la idea de
programar en ensamblador para el MIPS. Si se desea obtener m´as informaci´on sobre la
programaci´on de ´esta arquitectura, puede remitirse al Manual de Referencia sobre los
MIPS [32], o concretamente al manual de instrucciones [25] del MIPS espec´ıfico de la
PlayStation.
Por tanto, lo que aprovecharemos de este procesador es su arquitectura de prop´osi-
to general, para aprovechar el uso de bibliotecas ya disponibles y la programaci´on con
los componentes de entrada/salida del resto de consola, siendo el procesador ((central))
de la aplicaci´on, que repartir´a tareas y se encargar´a 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-
cut´andose en la m´aquina se ejecuta en ´este procesador, por lo que nuestra aplicaci´on
competir´a 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 aplicaci´on. Este hecho conlleva tambi´en a que la ejecuci´on de un progra-
ma en dicho procesador sea inmediato, ya que basta crear un programa y ejecutarlo
tal y como se llevar´ıa a cabo en cualquier otro linux ejecut´andose en una arquitectura
soportada cualquiera.
Unidades Vectoriales (VU0 y VU1)
Este tipo de unidades conforman, junto al sintetizador gr´afico, los elementos m´as
espec´ıficos de la arquitectura de la consola. Aunque sus caracter´ısticas difieren, b´asi-
camente se trata del mismo dise˜ no, por lo que las consideraremos de momento como
una ´ unica unidad en cuanto a programaci´on.
La informaci´on detallada sobre su repertorio de instrucciones viene en el manual
de las unidades vectoriales proporcionado por el DVD de documentaci´on que acompa˜ na
al kit de linux. El manual se refiere 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 difiere bastante de la
forma explicada para el procesador central. Al contrario que ´este, no es un procesador
de prop´osito 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 c´odigo objeto para luego cargarlo en la unidad vectorial, como ya veremos
posteriormente.
Figura 3.3: Esquema para la ejecuci´on de un programa en las unidades vectoriales
El Sintetizador Gr´afico (GS)
La programaci´on del sintetizador gr´afico siempre se muestra de forma relativa-
mente indirecta, ya que no se programa como tal, simplemente se le env´ıan ´ordenes
desde la VU1 o desde el EE, y ´esta realiza su funci´on de forma autom´atica. No hay una
programaci´on ((real)) tal y como sucede con el MIPS o las VU, en las que cargamos un
54 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
programa y vamos interactuando con los datos que recibimos. El sintetizador se limita
a recibir una serie de paquetes gr´aficos llamados ((GIF tags)), y realiza su salida en
pantalla. Estos ((GIF tags)) est´an compuestos de una geometr´ıa y unos atributos a nivel
de v´ertice, que usa el hardware inherente a dicha unidad y los transforma en pol´ıgonos
2D proyectados en la pantalla, con los atributos determinados.
3.1.4. Distribuci´on 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 decodificaci´on
de ogg vorbis usaremos el procesador principal. Si no tuviera suficiente potencia para
dicha tarea, distribuir´ıamos la carga entre las unidades vectoriales, aunque el hecho
de que el algoritmo de decodificaci´on no sea computacionalmente muy pesado y el
procesador principal del que hablamos es un procesador a 300MHz hace que pensemos
que ser´a m´as que suficiente para dicha tarea.
Tras todo este proceso, obtenemos un buffer 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 moment´aneo
y que sean representables de forma gr´afica, para poder obtener la imagen a dibujar. Al
final 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 distribuci´on inicial de las tareas
En el ap´endice correspondiente a ogg vorbis se detalla todo lo referente a dicho
formato. Aqu´ı simplemente mostraremos el esquema de las tareas que necesita realizar
la decodificaci´on, representado en la Figura 3.5. Si desea m´as detalles sobre su fun-
cionamiento o m´as informaci´on sobre los t´erminos usados, debe referirse al ap´endice
mencionado.
3.2. Implementaci´on del proyecto
3.2.1. Decodificaci´on de sonido
En la p´agina WEB de Xiph [23] podemos encontrar una implementaci´on realizada
para sistemas unix/linux. Disponemos de dos bibliotecas, ya que ogg vorbis corresponde
a dos conceptos distintos: mientras que vorbis hace menci´on al codec de audio en s´ı,
que contiene el sonido codificado, ogg hace referencia a la encapsulaci´on de las tramas
de vorbis en el fichero, para su almacenamiento f´ısico y su transmisi´on. En lugar de ogg
3.2. IMPLEMENTACI
´
ON DEL PROYECTO 55
Figura 3.5: Tareas de las que se compone la decodificaci´on de Ogg Vorbis
56 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
se podr´ıa usar uno distinto para realizar una transmisi´on streaming de vorbis mediante
red, por ejemplo. Por tanto, Xiph ha desarrollado una biblioteca para cada uno de
ellos, ambas disponibles en la direcci´on http://www.vorbis.com/download_unix_
1.0.1.psp:
libogg: es una biblioteca que se encarga de la decodificaci´ 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 decodificar el audio contenido en las
tramas vorbis encapsuladas en un flujo ogg de datos. Contiene tambi´en otra
biblioteca a m´as alto nivel denominada vorbisfile, que presenta una capa de abs-
tracci´on mayor sobre el fichero ogg vorbis, ofreciendo un interface al programador
m´as sencillo en cuanto a manipulaci´on del mismo.
Al estar implementado para un linux en un lenguaje portable como C, y ser por
tanto independiente de la arquitectura, nuestra primera opci´on 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 m´aquina o si por el contrario necesitamos reprogramar
ciertas partes del c´odigo 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 demostraci´on del uso de la biblioteca para cargar y decodificar los
ficheros ogg vorbis. Nos centraremos principalmente en el fichero de ejemplo de la biblio-
teca libvorbisfile. En el fichero vorbisfile example.c podemos ver las siguien-
tes llamadas principales a la biblioteca mencionada, acompa˜ nadas de una breve sinopsis
de su funcionamiento, extra´ıdas de la documentaci´on online de la biblioteca, disponible
en la direcci´on http://www.xiph.org/ogg/vorbis/doc/vorbisfile/reference.
html:
ov comment: devuelve un puntero a la estructura vorbis comment para el fichero
especificado. Esta estructura contiene la informaci´on contenida en los comenta-
rios del fichero. Datos como el t´ıtulo de la canci´on, el nombre del autor, el a˜ no,
estilo de canci´on, album de la canci´on y dem´as informaci´on de semejante tipo va
almacenada como comentario del fichero. Para m´as informaci´on sobre la forma de
almacenar estos comentarios y el formato usado, se puede consultar el ap´endice
destinado al formato ogg vorbis.
ov info: devuelve la estructura vorbis info del fichero especificado. Esta es-
tructura contiene informaci´on relativa a la versi´on de ogg vorbis, el n´ umero de
canales y la frecuencia de muestreo, entre otras. Estos dos ´ ultimos par´ametros
son los que nos interesar´an a nosotros.
ov read: esta funci´on es la funci´on principal de la decodificaci´on en s´ı. Devuelve
el n´ umero de bytes de audio PCM decodificado, seg´ un el tama˜ no de muestra
para cada valor, y el n´ umero de canales. La decodificaci´on en el buffer genera
un entrelazado en los canales como se muestra en la Figura 3.6. Realmente este
entrelazado no hace m´as que facilitarnos la tarea a la hora de reproducir, ya que
como veremos m´as 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 funci´on cerramos el fichero y limpiamos los buffers auxiliares
de la decodificaci´on.
Una vez probado el ejemplo y viendo que compila, tan solo queda cerciorarse
de que el procesador MIPS ser´a lo suficientemente potente como para decodificar el
fichero. 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 decodificaci´on. Como ya hemos comentado varias veces, el procesador central es
´ unico encargado de ejecutar el sitema operativo. Por tanto, toda la informaci´on que el
sistema operativo sea capaz de proporcionar sobre los procesadores que usa se referir´an
´ unicamente a dicho procesador. Esto nos supone una ventaja para lo que pretendemos
realizar a continuaci´on, ya que podemos emplear una utilidad cualquiera que muestre el
uso de CPU por proceso para saber de forma aproximada qu´e porcentaje del procesador
est´a 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 ocupaci´on de CPU. Se puede encontar en http:
//www.groupsys.com/top/, y la Figura 3.7 muestra un ejemplo de su salida. Nuestra
aplicaci´on de ejemplo ocupa aproximadamente el 23 % de los recursos computacionales
del procesador, lo que supone una carga suficientemente baja para no tener que realizar
a priori ninguna optimizaci´on del c´odigo proporcionado por Xiph.
Figura 3.7: Un ejemplo de la salida mostrada por top
58 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
3.2.2. Reproducci´on de sonido
Una vez solventado el tema inicial de decodificaci´on de audio, nuestro siguiente
objetivo es la reproducci´on del sonido decodificado. Por tanto, debemos ahora progra-
mar el dispositivo de salida, y enviar el flujo de datos obtenido tras la decodificaci´on.
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 interacci´on con este procesador se realiza a trav´es 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 programaci´on del procesador de sonido lo realiza un m´odulo del n´ ucleo de
linux, proporcionando una total abstracci´on de su hardware al programador.
Esta circunstancia supone una ventaja, pues aunque no tenemos experiencia pro-
gramando sonido desde linux, la informaci´on que se puede encontrar sobre este punto
en INTERNET es bastante amplia, y todo est´a muy documentado. Al ser programa-
ci´on general de linux podemos acelerar el desarrollo del prototipo realiz´andolo para
PC, ya que disponemos de nuestro entorno de programaci´on completo, con todas las
facilidades que ello conlleva.
En el portal linux.com [4] podemos ver un art´ıculo [51] comentando las distintas
alternativas de programaci´on de sonido que hay en el mercado en cuanto a programa-
ci´on de sonido en linux se refiere. Nosotros no necesitamos un sistema muy elaborado
de sonido, necesitamos uno lo m´as simple y r´apido posible, con el menor retardo aso-
ciado. Normalmente esto implica una programaci´on a un nivel m´as bajo de lo que
supondr´ıa emplear una API de mayores caracter´ısticas y abstracci´on. Otra raz´on es
la dependencia de bibliotecas externas. Estamos intentando minimizar la cantidad de
aplicaciones necesarias para la ejecuci´on de nuestro programa. Por tanto, decidimos
programar directamente el sonido usando con el driver que proporciona el n´ ucleo del
sistema. Con la informaci´on obtenida del libro Linux Multimedia Guide [49] en su
versi´on WEB, y de la informaci´on proporcionada por 4Front Technologies [1] sobre
la programaci´on [47] de OSS (Open Sound System), creamos una aplicaci´on 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 configuraci´on de un par´ametro hace que otro par´ametro vuelva a tomar
su valor por defecto, por lo que se requiere un orden espec´ıfico para poder configurar
todos los par´ametros a valores personalizados.
Como podemos leer en las anotaciones que se realizan para la reproducci´on 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 fich, lo pasamos
a la PlayStation2 para cerciorarnos de que funciona como hab´ıamos previsto, y no
tenemos que cambiar nada. El programa funciona perfectamente en la consola tal y
como esper´abamos, por lo que podemos dar por finalizada la primera parte del desarrollo
inicial sobre el procesador central MIPS.
3.2.3. Modelo gr´afico. Procesamiento de audio
Ahora es momento de implementar el sistema gr´afico. Antes de representar gr´afi-
camente el sonido debemos procesar los datos PCM que obtenemos de la decodificaci´on
de ogg vorbis y transformarlos en una serie de valores ´ utiles para su representaci´on 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 configuraci´on del dispositivo
Con espectrograma nos referimos al an´alisis espectral de la se˜ nal, dividiendo frag-
mentos del sonido en trozos en los que analizaremos las frecuencias presentes, para
realizar un estudio estad´ıstico de las frecuencias principales que est´an 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 canci´on
es un cambio de dominio. La onda que obtenemos al decodificar est´a en el dominio
60 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
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 m´as ((frecuente)) con el que se trabaja en sonido para la reproducci´on
es el del tiempo. Es la forma m´as natural de pensar en el sonido, ya que representar´ıa
el estado de excitaci´on de la se˜ nal en un tiempo determinado, que ser´a reflejado en la
vibraci´on que recibir´a el altavoz, reproduciendo dicho sonido. Sin embargo, el domi-
nio en frecuencia es mucho m´as ´ util para determinados campos, ya que permite una
manipulaci´on mucho m´as c´omoda 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 introducci´on sobre los elementos que conforman un sonido, puede visitar la p´agi-
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 representaci´on 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 informaci´on ´ util para nuestro prop´osito: caracterizar el fragmento de
sonido que decodificamos. 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
explicaci´on sencilla sobre la transformada de Fourier. Si quiere profundizar m´as, le
recomendamos que lea la bibliograf´ıa anteriormente citada.
Figura 3.10: Se˜ nal en el dominio en tiempo y en el dominio en frecuencia
Transformada de Fourier
Un proceso f´ısico puede describirse tanto en el dominio del tiempo como en el
dominio de la frecuencia, por una serie de valores, denominados par´ametros. Pode-
mos tener h(t) o bien H(f) si estamos refiri´endonos a la expresi´on gobernada por
un par´ametro que depende del tiempo (dominio en tiempo) o de un par´ametro que
depende de la frecuencia (dominio en frecuencia). Normalmente se entienden ambas
formas como dos representaciones distintas de una misma funci´on. Podemos definir la
relaci´on entre ellas como aparece en la ecuaci´on (3.1). En dicha ecuaci´on vemos que
la transformada de Fourier es una operaci´on lineal. La transformaci´on 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
2πift
dt
h(t) =
_
+∞
−∞
H(f)e
−2πift
dt
(3.1)
Transformada de Fourier sobre un conjunto de datos discretos
En la mayor´ıa de las ocasiones, la funci´on h(t) est´a 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 ecuaci´on (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 cr´ıtica de Nyquist, dada por la expresi´on
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 m´ınima a la que hay que muestrear una
se˜ nal para poder ser reconstru´ıda sin error. La otra raz´on 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 err´onea
a ese rango. Cualquier componente en frecuencia fuera de dicho rango es transladado
a ese rango al muestrear. La ´ unica opci´on contra este efecto es conocer el rango de la
funci´on a muestrear y muestrear a la suficiente velocidad para proporcionar al menos
dos puntos por ciclo de la frecuencia m´as alta presente.
Transformada Discreta de Fourier
Podemos estimar la transformada de Fourier desde un n´ umero finito 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 relaci´on (3.6),
llamada transformada discreta de Fourier, a la que denotaremos como H
n
. Como puede
apreciarse, no depende de ning´ un par´ametro dimensional, como era la escala temporal
∆.
H
n

N−1

k=0
h
k
e
2πikn/N
(3.6)
62 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
Figura 3.11: La funci´on original (a) es distinta de cero en un intervalo T de tiempo.
Su transformada de Fourier (b) no tiene limitaci´on 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) est´a definida entre ±f
c
. La potencia fuera de
ese rango se desplaza a dicho rango.
La relaci´on entre la transformada discreta y la transformada cont´ınua cuando las
vemos como muestras de una funci´on cont´ınua 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 simetr´ıa que la transformada continua de fourier.
Transformada R´apida de Fourier (FFT)
Si analizamos la carga computacional que supone calcular la transformada discreta
de Fourier para N puntos, podr´ıamos llegar a la conclusi´on de que, definiendo W como
W ≡ e
2πi/N
(3.8)
podemos expresar (3.6) como
H
n
=
N−1

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 multiplicaci´on produce un vector
3.2. IMPLEMENTACI
´
ON DEL PROYECTO 63
cuyas componentes son las H
n
. Esta multiplicaci´on 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 r´apida 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 demostraci´on es la siguiente:
F
k
=
N−1

j=0
e
2πijk/N
f
j
=
N/2−1

j=0
e
2πi(2j)k/N
f
2j
+
N/2−1

j=0
e
2πi(2j+1)k/N
f
2j+1
=
N/2−1

j=0
e
2πijk/(N/2)
f
2j
+W
k
N/2−1

j=0
e
2πijk/(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 reducci´on
para F
e
k
, transform´andolo en su N/4 entrada impar y N/4 entrada par. As´ı, podemos
definir 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
subdivisi´on hasta que tengamos transformaciones de logitud 1. La transformada en ese
caso es simplemente la operaci´on identidad que copia una entrada en una salida. Para
cada patr´on 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
eoeeoeo···oee
k
= f
n
para alg´ un n (3.11)
El siguiente paso es determinar qu´e valor de n corresponde a qu´e patr´on de e y o en
la ecuaci´on 3.11. La soluci´on es invertir la secuencia de e y o, y sustituir e = 0 y o = 1,
y el n´ umero formado ser´a 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 aplicaci´on 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 final. Cada combinaci´on conlleva un orden de N
operaciones, y son log
2
N combinaciones, lo que hace un total de Nlog
2
N.
64 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
Figura 3.12: Reordenaci´on de un vector (longitud 8 en este caso) por inversi´on de bits,
(a) entre dos vectores, (b) en un vector
Implementaci´on e integraci´on de la FFT
Dada la importancia de una implementaci´on optimizada y la gran difusi´on de este
proceso por doquier, pensamos buscar una implementaci´on fiable y suficientemente op-
timizada para evitar sorpresas futuras al encontrar errores durante la depuraci´on dadas
por un fallo en la implementaci´on del algoritmo, as´ı como la creaci´on de un innecesa-
rio cuello de botella, pues la velocidad de la FFT es cr´ıtica en nuestro procesamiento
visual. Podemos encontrar gran cantidad de implementaciones en la WEB, bibliotecas
[56] completas incluso. Sin embargo, recurrimos a una implementaci´on usada para algo
similar a nuestro prop´osito, entendiendo que es una implementaci´on suficientemente
v´alida para nuestra aplicaci´on al ser usada para prop´ositos similares. Una vez m´as re-
currimos al programa XMMS [46], que contiene en su c´odigo [11] unas funciones que
transforman los datos de sonidos decodificados a su espectro de frecuencias mediante
una transformada r´apida de Fourier.
Llegado este momento, decidimos realizar una implementaci´on de prueba aparte
de la consola, con una representaci´on en calidad de prototipo bajo el estandard gr´afico
OpenGL [33], para definir el algoritmo de espectrograma, con el prop´osito de aislar
los errores posibles encontrados. Esto es posible dadas las circunstancias actuales: (i)
la parte de decodificaci´on, reproducci´on y transformaci´on al dominio en frecuencia se
realizar´an en el procesador central MIPS de la consola, (ii) el c´odigo referente a cada
uno de los pasos anteriores es c´odigo C portable entre plataformas, (iii) la indepen-
dencia del c´odigo de visualizaci´on, que ser´a necesario reimplementar en ensamblador
para la unidad vectorial VU1. Esta decisi´on 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 c´odigo en el mismo. Por contra, la
consola no est´a 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 programaci´on gr´afico OpenGL, lo que repercute en una gran sencillez a la
hora de desarrollar un prototipo gr´afico en el que mostrar un avance del efecto
producido por el algoritmo de caracterizaci´on de sonido.
Independencia del hardware y la programaci´on nativa de la consola: este punto
quiz´as sea el m´as importante. Nos referimos a la posibilidad de desarrollar el
algoritmo que generar´a a su salida una serie de propiedades que usaremos para
representar gr´aficamente un patr´on que identifique las caracter´ısticas del sonido
sin tener que lidiar de momento con el hardware de dibujo de la consola, esto
es, el sintetizador gr´afico. Con esto conseguimos comprobar qu´e resultado se
obtiene en el algoritmo, y desligar completamente los errores de programaci´on
del mismo a los errores de programaci´on relativos al apartado gr´afico. Dado
nuestra inexperiencia con este hardware espec´ıfico, hemos sido realistas al pensar
que el n´ umero de errores de programaci´on en este apartado ser´an numerosos y
su desarrollo ser´a lento, pues supone la etapa de aprendizaje m´as 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 itroducci´on a la FFT, tener un n´ umero de muestras
N potencia de dos facilita mucho la aplicaci´on de las propiedades de recursividad,
lo que hace que sea m´as eficiente de implementar. La implementaci´on usada en el
XMMS hace uso de esta propiedad, como era l´ogico suponer. El tama˜ no concreto para
dicha implementaci´on es de 512. Los valores de salida deben ser tratados para poder
clasificarlos 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 c´alculo.
La intenci´on inicial es obtener un gr´afico 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 suficientemente 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 medici´on en bruto que nos es ´ util a la hora de
definir un espectro de bandas. Teniendo una medida sobre la aparici´on de cada banda
de frecuencias considerada, podemos representar proporcionalmente a dicha medida
cada una de las bandas. As´ı, como muestra la Figura 3.13, podr´ıamos dibujar una
altura diferente a una primitiva (en este caso un tri´angulo), 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 clasificarlo directamente en ((bandas de frecuencia)). Tengamos en mente que
aproximadamente el 80 % de los valores pertenecen al primer 15 % del rango de abscisas.
Si hici´eramos una divisi´on lineal, en las primeras barras concentrar´ıamos casi todos los
valores, provocando una saturaci´on en ellas y una carencia de valores en las restantes.
66 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
Figura 3.13: Para poder considerar un espectro de frecuencia suficientemente ´amplio
con un n´ umero bastante reducido de barras a representar, necesitamos definir 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 m´as lineal antes de distribuirlos
en bandas haremos exactamente lo mismo que hace el programa XMMS [46]. Primero
realiza una ra´ız cuadrada para eliminar parte de su condici´on de no linealidad, y luego
divide por 256 para mover el dominio de valores a un rango m´as 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 m´as que un par´ametro
obtenido de forma emp´ırica. La finalidad del par´ametro τ es fijar la cota superior de
frecuencia que ser´a procesada en la representaci´on gr´afica. Un valor de salida de la FFT
superior a τ ser´a ignorado, ya que siendo N el n´ umero de barras disponibles, caer´ıa en
un ((conjunto de frecuencia)) Ψ
δ
, siendo δ > N.
Por tanto, para todo α ∈ [0, 1], α una salida cualquiera de la FFT tras la norma-
lizaci´on, le corresponde un ((conjunto de frecuencia)) Ψ
β
, tal que β = ¸α N|.
3.2.4. Detecci´on de la cadencia de la canci´on
Antes de implementar el apartado gr´afico en la consola, vamos a dotar a nuestro
prototipo con otro elemento que le dotar´a de un complemento visual. Queremos que
nuestra aplicaci´on reaccione tambi´en al ritmo de la canci´on. Una definici´on de ritmo la
encontramos en El liceo digital [35], donde queda definido como la relaci´on que existe
entre el transcurso del tiempo medido en sus propias unidades (por ejemplo, segundos o
sus fracciones), y la duraci´on 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 canci´on. Esta
subida se detetar´a en relaci´on a un hist´orico de la energ´ıa calculada anteriormente.
Es decir, tendremos una detecci´on din´amica de la cadencia, que se ajustar´a a medida
que avanza la canci´on. La ventaja de tener una detecci´on din´amica es la posibilidad de
poder distinguir las variaciones en la intensidad de la se˜ nal a´ un cuando la energ´ıa de
toda la canci´on ha aumentado o disminu´ıdo.
3.2. IMPLEMENTACI
´
ON DEL PROYECTO 67
Gracias a la utilizaci´on de un hist´orico adaptativo con el que ir comparando la evo-
luci´ on de la canci´on evitamos la necesidad de definir emp´ıricamente una cota superior
de energ´ıa para la que determinar´ıamos que se produce un golpe de intensidad, con el
consiguiente problema producido por la saturaci´on posible en los pasajes muy en´ergi-
cos. Al ser din´amico, evitamos la posible saturaci´on, ya que aislamos la componente
media de energ´ıa.
Nosotros emplearemos un algoritmo de detecci´on de cadencia descrito por Fr´ed´eric
Patin, en concreto el algoritmo m´as simple de los que describe en su art´ıculo [42],
aplicando las optimizaciones pertinentes. B´asicamente se trata de calcular la energ´ıa
del buffer que consideramos como sonido en cada momento, un buffer de longitud 1024
muestras. Sean α y β los buffers de los canales derecho e izquierdo, podemos calcular
la energ´ıa como
=
stereo
=
α
+
β
=
i
0

k=i
0
(α[k]
2
+β[k]
2
) (3.13)
Calculamos la energ´ıa local media ξ con el buffer del hist´orico de energ´ıa E.
Deseamos registrar un hist´orico de energ´ıa de aproximadamente un segundo de du-
raci´on. Supondremos que la m´ usica est´a muestreada en calidad CD, lo que conlleva
unas 44100 muestras por segundo. Como hemos dicho, cada buffer que decodificamos
de audio contiene 1024 muestras, lo que implica que necesitamos 44100/1024 ≈ 43
valores. Por tanto, calculamos la energ´ıa local media haciendo
ξ =
1
43

43

i=0
(E[i])
2
(3.14)
Tras calcular ξ, desplazamos el buffer E un lugar a la derecha para dejar espacio
a la nueva muestra, desechando el valor antiguo. Apilamos pues la nueva energ´ıa
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 detecci´on de golpe de ritmo.
Cuanto mayor sea η, m´as variaci´on de la energ´ıa se requiere para detectar el cambio
como ritmo. Emp´ıricamente se demuestra que un valor η = 1, 3 es acertado en la
mayor´ıa 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 canci´on
en su representaci´on de onda, y las cadencias detectadas.
3.2.5. Reimplementaci´on del plugin gr´afico
Antes de comenzar la programaci´on de las unidades vectoriales vamos a migrar el
prototipo a la consola. Para ello no tenemos m´as que eliminar toda la parte a˜ nadida
para la representaci´on. Teniendo una versi´on de prototipo minimizada en la consola,
comenzamos a construir la base sobre la que implementaremos la aplicaci´on final. Todo
el desarrollo independiente del hardware de la m´aquina se ha acabado, y solo resta la
parte que implica una programaci´on 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 qu´e programa de ejemplo conten´ıa una estructura y
unos requisitos m´as parecidos para nuestro prop´osito, descartamos las demos de la VU
Demo Coding Contest [15], ya que supon´ıan demasiadas limitaciones en cuanto a lo
68 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
Figura 3.14: De una onda (rojo) se puede estimar los golpes de ritmo (verde). Aqu´ı he-
mos representado todo el buffer 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 intercomunicaci´on MIPS ⇔VU se refiere. Su dise˜ no inicial consist´ıa en disponer de
un programa en el MIPS, cuya ´ unica misi´on 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
aplicaci´on.
Por el contrario, las demos pertenecientes a la biblioteca libps2dev [13] s´ı poseen
una estructura m´as similar a la que nosotros pretendemos desarrollar. La aplicaci´on de
demostraci´on demo3d proporciona un grado de interacci´on entre las unidades vectoria-
les y el procesador principal que podremos emplear como base para nuestro programa.
Esta aplicaci´on de ejemplo dibuja un cubo con texturas en sus caras e iluminaci´on, 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
configuraci´on de lo que es la consola. Se prescindir´an de las partes correspondientes al
prototipo que desarrollamos anteriormente, es decir, a cualquier parte correspondiente
a nuestra aplicaci´on. Aqu´ı solo vamos a explicar lo que necesitamos para formar lo que
se conoce como ((plantilla)) o ((esqueleto)), y se refiere al conjunto de sentencias m´ınimas
que hay que escribir en cada uno de los programas para su correcto funcionamiento.
Analizaremos a continuaci´on las partes m´as importantes del programa plantilla por
3.2. IMPLEMENTACI
´
ON DEL PROYECTO 69
fragmentos, indicando la finalidad de dichas l´ıneas. Se omiten las partes de declaraci´on
de variables y semejante tipo de c´odigo, que pueden encontrarse en los ficheros fuente
asociados y no requieren de ninguna explicaci´on.
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 gr´afico (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 grafico
ps2 gs vc graphicsmode();
Tras ´esto, lo que hacemos es cargar en memoria el c´odigo objeto del programa a
ejecutar en la unidad vectorial. En nuestro caso, dicho fichero 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 gr´afico. Primero confi-
guramos el sintetizador gr´afico con una serie de par´ametros que determinan el modo
de v´ıdeo a generar. Como sabemos, la consola es apaz de generar distintos modos
de v´ıdeo, tanto a resoluci´on (640x480,800x600. . .) como a formato (PAL, NTSC,
VGA. . .). Despu´es configuraremos el doublebuffer, y crearemos cada uno de los buffers
de pantalla a utilizar.
// reseteamos el GS
ps2 gs reset(0, g inter, g out mode, g ff mode, g resolution,
g refresh rate);
next2k = ps2 gs set dbuff(&g db, g psm, gp−>width, gp−>height,
(g zbits == 0) ? 0 : PS2 GS ZGREATER,
g zpsm, 1);
// definimos los dos buffers
*( 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 definido lo anterior, limpiamos el buffer y esperamos la sincronizaci´on con
el procesador principal, para continuar cuando la entidad gr´afica est´e lista. Tras ´esto,
comenzamos la visualizaci´on gr´afica.
// clear back buffer
ps2 gs put drawenv(&g db.giftag1);
70 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
// wait clear done
ps2 gs set finish(&g finish);
ps2 gs wait finish(&g finish);
odev = !ps2 gs sync v(0);
ps2 gs start display(1);
ps2 gs vc enablevcswitch(acquire, release);
Ahora entramos en lo que ser´a el bucle infinito de acci´on. Es decir, cada fotograma
dibujado pasar´a por este bucle, as´ı que es en su interior donde debemos procesar la
informaci´on que queramos mostrar. Su estructura es muy sencilla. Se limita a detener
el sintetizador gr´afico, cambiar el buffer sobre el que se dibuja (debido al uso de double
buffer que hacemos). Luego ir´ıa todo el procesamiento de datos que se desea realizar en
el MIPS, y una vez finalizados definimos el inicio del programa de la VU1 que vamos a
ejecutar mandando mediante DMA la informaci´on necesaria. La variable My dma start
est´a definida en el fichero ensamblador de la VU1, y en el c´odigo del MIPS la hemos
importado gracias a la macro IMPORT VPU SYMBOL, tal y como se puede apreciar en el
c´odigo fuente completo. Solo resta incrementar el fotograma en el que nos encontramos
(para que el programa sepa decidir qu´e buffer mostrar), y reanudamos el funcionamiento
del sintetizador gr´afico.
// bucle infinito
for (; ;) {
// detenemos el GS
ps2 gs vc lock();
ps2 gs swap dbuff(&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 continuaci´on corresponde a la secci´ on posterior al bucle
infinito. Depende de la forma de programaci´on del bucle, puede que se ejecute o no,
seg´ un la forma de salir del bucle. Aqu´ı usaremos siempre que se permite la instrucci´on
break para salir del bucle infinito, por lo que supondremos que dichas instrucciones
s´ı son ejecutadas salvo comportamiento an´omalo del programa, y terminaci´on err´onea.
Solo resta liberar los recursos tomados al inicio, para lo que cerraremos primero el c´odigo
objeto del programa de la VU1, y el sintetizador gr´afico, 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
Introducci´on a las unidades vectoriales
Llega por fin 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 simult´anea. Sin embargo, ambos cauces no son sim´etricos, 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 caracter´ıstica 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 est´a unida directamente al EE, siendo lo que
se denomina su COP2 (su segundo coprocesador de c´alculo). Por contra, la memoria
de la unidad VU1 est´a conectada al GIF (el interface hacia el sintetizador gr´afico), y
los registros de la VU1 est´an ((mapeados)) a la memoria de la unidad VU0. Una visi´on
m´as detallada de una unidad vectorial puede contemplarse en la Figura 3.16.
FMAC: realiza suma, resta, multiplicaci´on y suma-producto sobre n´ umeros flo-
tantes. Hay cuatro unidades para realizar eficientemente la operaci´on sobre vec-
tores de puntos en el plano (x, y, z, w).
FDIV: realiza divisi´on y ra´ız cuadrada en aritm´etica flotante. 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 c´omputos sobre los n´ umeros enteros de 16 bits.
72 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
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, logar´ıtmicas y
trigonom´etricas. Como se aprecia, solo est´a 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 operaci´on. 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 c´odigo C mediante
la primitiva asm. No hace falta enviar un programa aparte a la unidad vectorial como
mostr´abamos en el esqueleto del MIPS. A esta forma de funcionamiento de la VU0
se la conoce como macro modo. A continuaci´on mostraremos una tabla resumen con
las caracter´ısticas de cada unidad vectorial, para que sirva como gu´ıa 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
Operaci´on Opera como un procesador indepen-
diente
Opera como coprocesador del MIPS
C´odigo de ope-
raci´on
Instrucciones LIW de 64 bits Instrucciones MIPS COP2 de 32 bits
Conjunto de ins-
trucciones
Instrucciones superiores + inferio-
res (pueden especificarse simult´anea-
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 opci´on (solo
VU1)
No hay soporte
Registros 32 registros flotantes de 128 bits, 16
registros enteros, registros especia-
les: ACC, I, Q, R {,P}
32 registros flotantes de 128 bits, 16
registros enteros, registros especia-
les: ACC, I, Q, R y 16 registros de
control
Generaci´on de c´odigo objeto para la VU
Hemos mencionado que las unidades vectoriales disponen de dos unidades de ejecu-
ci´on, tal y como mostraba la Figura 3.16. Esto implica la emisi´on de dos instrucciones
por ciclo, por lo que a la hora de programar se deben especificar concurrentemente
ambas instrucciones.
A continuaci´on mostraremos un ejemplo de la forma de programaci´on de estas
unidades, extra´ıda 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 ejecuci´on. Como
vemos, se especifican en parejas. Cuando se debe esperar a la finalizaci´on de un cauce
para poder seguir computando, se emplea la instrucci´on NOP para rellenar el cauce que
ha de permanecer ocioso.
Como se puede intuir, este m´etodo de programaci´on dista mucho de ser c´omodo,
y es bastante propenso a errores y supone una gran dificultad a la hora de generar
mantenible y legible, ya que hay que tener en cuenta dos cauces distintos de c´odigo al
mismo tiempo. Tambi´en es dif´ıcil de editar debido a la naturaleza de los editores, ya
que la inserci´on de una instrucci´on en una columna supondr´ıa tener que modificar la
otra columna por completo de forma manual para dejarla intacta si no se desea rellenar
con una instrucci´on de NOP el hueco nuevo formado.
Como Sony es consciente de todo esto, y sabe adem´as que una de las propiedades
necesarias para la difusi´on de su consola es la acogida de los programadores, se en-
carg´o de programar un preprocesador para la unidad vectorial, que es lo que nosotros
usaremos. Se trata de VCL [31], cuya finalidad es la de procesar un fichero ensambla-
dor secuencial con ciertas directivas especiales, y convertirlo en un fichero ensamblador
con dos cauces de instrucciones en paralelo, optimizando fuertemente el c´odigo, a´ un
cuando es de cierta complejidad. A continuaci´on presentamos un extracto de un c´odi-
go ensamblador correspondiente a VCL, para apreciar la diferencia en complejidad de
74 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
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, OffsetVecs[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 m´as sencillo seguir el flujo del programa
con un ´ unico cauce de ejecuci´on que con un cauce dual. Tambi´en se simplifica de
forma considerable la programaci´on al disponer de definiciones de macros, a˜ nadido a
la colecci´on de funciones definidas como macros para las operaciones entre vectores y
matrices m´as usuales en el c´alculo 3D. VCL simplifica la programaci´on ensamblador
en otro sentido tambi´en. Agrupa las instrucciones en instrucciones m´as gen´ericas, y
detecta autom´aticamente qu´e uso de la instrucci´on se est´a usando para a˜ nadir los
sufijos pertinentes.
El c´odigo ensamblador escrito para VCL se procesa y origina como salida un fichero
ensamblador de las VU con un programa equivalente al especificado en VCL, con
su cauce dual y desenrollado de macros y dem´as conversiones pertinentes. Una vez
obtenido, se operar´a de semejante forma para convertirlo a c´odigo objeto, tal y como
si hubiera sido programado directamente en lugar de empleando VCL.
Para generar c´odigo objeto en formato legible por la funci´ on de la biblioteca
libps2dev necesitamos enlazarlo usando unas opciones especiales proporcionadas en
el fichero vpu.cmd. Su finalidad no es m´as que la de definir un objeto para el MIPS
5900, definiendo d´onde est´a la memoria de programa y d´onde la memoria de datos.
Este fichero lo proporciona Sony, y se puede encontrar en cualquier ejemplo. Al fichero
ensamblador generado para VCL lo mentaremos basic.vcl, que producir´a un fichero
basic.vsm al procesarlo. La extensi´on vsm se refiere a Vectorial Assembler, un juego
de palabras de la tradicional extensi´on para ficheros en ensamblador asm.
Necesitamos un fichero donde definiremos informaci´on necesaria para que la VU
sea capaz de trabajar con ´el. La informaci´on relativa al paquete DMA, variables globales
que se exportar´an hacia el MIPS, y valores determinados en posiciones de memoria de
datos de la VU se rellenan en este fichero, que denominaremos cube.dsm, donde
incluiremos el fichero generado mediante VCL basic.vsm en la secci´on del c´odigo
relativo al programa. Analizaremos las secciones m´as importantes de ´este fichero, de
manera similar a lo que hicimos con el fichero ((plantilla)) del MIPS.
Comenzamos definiendo el tipo de informaci´on a contener, y posteriormente in-
clu´ımos el fichero de macros que proporciona Sony para facilitar la definici´on de cons-
tantes para rellenar la memoria de datos de forma manual. Esto viene en el fichero
vumacros.h. A continuaci´on, definimos una lista de s´ımbolos 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 us´abamos en el ((esqueleto)) del MIPS, ya que todo programa debe contener
una etiqueta que lo identifique. El nombre no es relevante, pero decidimos dejar
el original para que sea m´as f´acil relacionarlo si se ojea el c´odigo de ejemplo que
proporciona Sony.
3.2. IMPLEMENTACI
´
ON DEL PROYECTO 75
Mis valores, Mis valores1: representan un conjunto de valores que se usar´an
posteriormente para los c´alculos. La anchura de las barras y la detecci´on 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 representaci´on gr´afica de la consola.
El trozo de c´odigo que refleja 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 definimos el inicio del c´odigo a ejecutar, My dma start. Como se
puede observar, b´asicamente es la inclusi´on del c´odigo 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 secci´on comienza precedida del s´ımbolo global definido anteriormente
como My dma next, que no hemos tenido a bien de definir con anterioridad. El nombre
en realidad es simplemente herencia del original, aparecido en el c´odigo de ejemplo.
Como puede observarse, es una mera definici´on adicional para My cube start. Se-
guidamente se define lo que s´ı es importante en esta secci´on de c´odigo: el s´ımbolo
My matrix. Este s´ımbolo global tampoco ha sido explicado con anterioridad. Repre-
senta la matriz de transformaci´on de vista entre el mundo 3D y su proyecci´on asociada
2D. M´as informaci´on sobre las transformaciones de vista se explican en el ap´endice
de visionado gr´afico. Como podemos observar atentamente en la sentencia unpack, el
cuarto argumento es un 0. Este argumento determina la posici´on que ocupa el valor
inmediatamente asignado dentro de la memoria de datos de la VU. En este caso, la
primera fila de la matriz (recordemos que una direcci´on de memoria corresponde a un
cuarteto (x, y, z, w) de valores) estar´a en la posici´on de memoria 0. La macro fwzyx
sirve para especificar un cuarteto de valores en coma flotante en el orden (w, z, y, x).
Hay que tener esto en cuenta cuando se intenta observar la matriz usada.
76 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
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 deber´ıamos estar familiarizados con la definici´on de valores
en zonas de memoria concretas. Como podemos observar, estamos definiendo nuestro
cuarteto de valores auxiliares en la posici´on de memoria 8. Seguir´an al c´odigo una
serie de definiciones semejantes que obviaremos dada su similitud con este c´odigo
aqu´ı presentado.
unpack 4, 4, V4 32, 8, * ; mios
Mis valores:
fxyzw 4, 0, 0, 0
.EndUnpack
Llegamos al final del fichero, donde radica la parte m´as interesante. Podemos ver
el s´ımbolo global My cube start, cuyo nombre lo dejamos inalterado del original. Co-
mo vemos, definimos 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 (prefijo i en lugar de f). Sin embargo, lo realmente importante es lo que se
est´a definiendo aqu´ı. Esa secuencia de cuatro cifras enteras representa el paquete GIF
que se mandar´a al sintetizador gr´afico en la VU1. No es que se mande de forma direc-
ta, pero nuestro programa de la unidad vectorial cargar´a estos valores para fabricar en
tiempo de ejecuci´on un paquete GIF y mand´arselo al GS, como veremos m´as adelante.
Solo diremos que definiremos como primitiva gr´afica un par de tri´angulos que confor-
mar´an una cara rectangular. El resultado ser´ıa equivalente a un rect´angulo al que se le
traza la diagonal, dividi´endolo en dos tri´angulos. Tras ´esto, definimos una posici´on 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 ficheros necesaria para la generaci´on del
c´odigo objeto, podremos comprender los pasos que se muestran en la Figura 3.17, que
ilustra la generaci´on de un fichero objeto para ser cargado en la unidad vectorial.
Figura 3.17: Proceso necesario para obtener el c´odigo objeto desde el fichero ensam-
blador.
Introducci´on al sintetizador gr´afico
Antes de explicar la programaci´on del sintetizador gr´afico que necesitamos para
mostrar nuestro gr´afico de barras por pantalla, haremos una breve introducci´on al
sintetizador gr´afico con la finalidad de entender un poco qu´e conforma y c´omo funciona
dicha unidad. Si se desea una informaci´on m´as detallada y exahustiva, remitimos como
siempre al manual [29]. La Figura 3.18 muestra un esquema de su estructura interna.
Ahora comentaremos brevemente qu´e es cada bloque denotado en dicho esquema,
para poder identificarlos.
Host I/F: es el interface encargado de transferir datos con el procesador. La
transferencia del buffer y de la informaci´on de dibujado pasan por este interface.
Setup/Rasterizing (preprocesamiento): se encarga de generar las formas que se
dibujar´an como puntos bas´andose en la informaci´on recibida sobre los v´ertices,
calculando a su vez su valor RGBA, valor Z y niebla para cada pixel.
Pixel Pipeline: realiza procesos como texturizaci´on, niebla, transparencias, y
determina el color final con el que se debe dibujar bas´andose en la informaci´on
calculada en el Rasterizing. Puede procesar hasta diecis´eis pixels concurrente-
mente.
Memory I/F: es el m´odulo encargado de leer y escribir en la memoria local
del sintetizador gr´afico. Escribe los valores RGBA+Z del pixel a dibujar al final
78 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
Figura 3.18: Descomposici´on en bloques del sintetizador gr´afico.
3.2. IMPLEMENTACI
´
ON DEL PROYECTO 79
de la operaci´on de dibujado, lee de memoria los valores de los pixels del frame
buffer 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 gr´afico, compuesta
por 320Mbit, que contiene el frame buffer, Z buffer, 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 buffer
y al Z buffer, y un puerto de 512 bits para leer la textura.
PCRTC: muestra el contenido del frame buffer en el formato especificado.
Un detalle muy a tener en cuenta con el sintetizador gr´afico para evitar problemas
m´as adelante es el sistema de coordenadas que emplea. Es distinto al ((standard)) en
bibliotecas y sistemas de representaci´on habituales, lo que puede llegar a crear una
confusi´on si no se ha tenido en cuenta.
Sistema de Coordenadas de Mundo: usa una representaci´on de 16 bits de coma
fija, 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 quedar´a plasmada
en la pantalla es la que corresponde a la ventana definida por este rango, tanto
horizontal como vertical. Por ejemplo, el punto central de la pantalla ser´a 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 rect´angulo de visualizaci´on.
La Figura 3.19 representa el flujo de dibujado necesario para convertir la infor-
maci´on que recibe del procesador (((host))) en datos representables gr´aficamente 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
bas´andose en la informaci´on de v´ertices que recibe desde el ((host)). Si la primi-
tiva gr´afica es un tri´angulo, 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 funci´on de textura al valor RGBA de la textura le´ıdo 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 refiere a la proporci´on de pixel ocupada por el
lado de la primitiva te´orica). 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 aplicaci´on de
textura se mezclan en concordancia con el valor de niebla del punto calculado
por el DDA.
80 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
Figura 3.19: Flujo de datos del sintetizador gr´afico.
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 comprobaci´on 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 buffer. 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 operaci´on de pixel, leer valores de pixels al frame buffer desde memoria,
y leer valores RGBA de memoria para representarlos.
Environment Register: conforman una serie de registros que contienen infor-
maci´on necesaria para el dibujado.
El hardware de la consola permite dibujar primitivas gr´aficas directamente. Tiene
un hardware suficientemente complejo como para permitir que trabajemos en un nivel
de abstracci´on superior a puntos en la pantalla. Mostraremos las distintas opciones que
soporta el sintetizador gr´afico, con una breve descripci´on aclarativa.
Punto (point):
Un punto suelto, dibujado con la informaci´on de
un v´ertice.
L´ınea (line):
Una l´ınea independiente que une dos puntos,
dibujado con la informaci´on de dos puntos.
L´ıneas encadenadas (linestrip):
Sucesi´on de l´ıneas que comparten el punto final
como inicial de la siguiente, de forma encade-
nada. La primera necesita informaci´on de dos
puntos, y el resto solo de uno m´as.
Tri´angulo (triangle):
Un tri´angulo independiente, formado con la in-
formaci´on de tres v´ertices.
Tri´angulos encadenados (trianglestrip):
Una sucesi´on de tri´angulos que comparten un la-
do con el tri´angulo siguiente. El primer tri´angulo
necesita informaci´on de tres v´ertices, y el resto
solo necesita un v´ertice por tri´angulo.
82 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
Tri´angulos en abanico (trianglefan):
Sucesi´on de tri´angulos que comparten un v´erti-
ce. El primer tri´angulo necesita informaci´on de
tres v´ertices, y el resto de tri´angulos solo nece-
sitan la informaci´on de un v´ertice m´as.
Sprite:
Rect´angulo dibujado con solo dos v´ertices, que
marcan la diagonal del mismo.
Programaci´on del sintetizador gr´afico
Una vez examinadas por encima las capacidades del sintetizador gr´afico, 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 gr´afico qu´e 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 especificar solamente la posici´on de los v´ertices, o si queremos especificar
posici´on y color, o cualquier combinaci´on de los posibles atributos, entre los que se
encuentran tambi´en las coordenadas UV de aplicaci´on de textura. Adem´as, tambi´en
debemos especificar el n´ umero de v´ertices que vamos a definir, ya que es parte de la
primitiva la cantidad de aristas que estamos dibujando. Despu´es solo resta dar toda la
informaci´on que le hemos dicho que ´ıbamos a usar, y enviar la orden al sintetizador
gr´afico. Daremos una informaci´on m´as detallada sobre las opciones de cada paso, para
comprender las posibilidades.
1. Configurando el tipo de primitiva y los atributos de representaci´on: primero se
elige el tipo de primitiva y las opciones que tendr´a. Las opciones aparecen en la
Tabla 3.1
Atributo Descripci´on Opciones
IIP M´etodo de sombreado Flat/Gouraud
TME Aplicaci´on 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 Interpolaci´on FIX S´ı/No
Cuadro 3.1: Antes de especificar la lista de informaci´on, se debe definir el tipo de
primitiva y las caracter´ısticas que tendr´a.
2. Informaci´on de los v´ertices: en este apartado veremos los tipos de registros dis-
ponibles para especificar informaci´on variada sobre el v´ertice definido. 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 coeficientes de niebla XYZF2 S´ı S´ı
Coordenadas XYZ3 S´ı No
Coordenadas y coeficientes de niebla XYZF3 S´ı No
Color y par´ametro Q de las coordenadas
de textura
RGBAQ No No
Par´ametros ST de las coordenadas de
textura
ST No No
Coordenadas UV del texel UV No No
Coeficiente de niebla FOG No No
Cuadro 3.2: Registros existentes para especificar informaci´on asociada a un v´ertice.
Figura 3.20: Desplazamiento realizado en la cola de v´ertices como consecuencia de un
vertex kick.
3. Vertex Kick: si los registros usados ten´ıan la funci´on vertex kick la informaci´on
concerniente al v´ertice especificada hasta ese momento se sit´ ua en la cola de
v´ertices, y la cola avanza una posici´on. A este proceso se le conoce como vertex
kick. La Figura 3.20 muestra una ilustraci´on de lo que supone este proceso.
4. Comenzar el dibujado (drawing kick): cuando toda la informaci´on necesaria
est´a en la cola de v´ertices, el dibujado comienza.
Programa de la VU1: basic.vcl
En esta secci´on detallaremos el c´odigo que compone el programa de la VU1, para
entender qu´e hacemos en dicha unidad. Como hemos venido haciendo, explicaremos
fragmentos de c´odigo, relevando detalles significativos del mismo.
Lo primero que haremos ser´a definir las constantes que referenciar´an a las zonas
de memoria de datos que usamos en la VU1. Como ya vimos, escrib´ıamos algunos datos
tales como matrices o las barras en la memoria de datos de la VU1. Aqu´ı definimos
84 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
un nombre para referirnos a dichas posiciones de memoria, haciendo m´as legible el
programa que proseguir´a a continuaci´on.
; direcciones de memoria donde se encuentran los datos a usar
kScreenMat0 .assign 0
kScreenMat1 .assign 1
kScreenMat2 .assign 2
kScreenMat3 .assign 3
kMisValores0 .assign 8
kMisValores1 .assign 9
kBarras1 .assign 512
kBarras2 .assign 819
Ahora especificamos 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 fines), y le especificamos tambi´en que
queremos usar la sint´axis ((nueva)) del VCL. Y tras ´esto, comenzamos la secci´on de
c´odigo.
.init vf all ; deja que el vcl use todos los registros flotantes
.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 definidas al inicio de todo, cargamos la matriz de
transformaci´on geom´etrica de la zona de memoria kScreenMat al vector Transform.
Tambi´en cargamos las ((constantes)) varias que definimos, donde pasaremos ciertos
par´ametros entre el EE y la VU1.
; cargamos la matriz de tranformacion geometrica
lq Transform[0], kScreenMat0(vi00)
lq Transform[1], kScreenMat1(vi00)
lq Transform[2], kScreenMat2(vi00)
lq Transform[3], kScreenMat3(vi00)
; cargamos las constantes
lq MiValor, kMisValores0(vi00)
lq MiValor2, kMisValores1(vi00)
−−cont
Comenzamos la secci´on de c´odigo que se ejecuta al inicio una ´ unica vez. Recorda-
remos de apartados anteriores, cuando comentamos la definici´on del fichero cube.dsm,
que defin´ıamos un cuarteto de valores enteros que eran el GIF o especificaci´on de la
primitiva gr´afica que ´ıbamos a emplear. Lo que realizamos en la primera secci´on de
c´odigo es cargar aquellos valores que definimos (primitiva, v´ertice de referencia y los
colores). Destacaremos la instrucci´on xtop, que obtiene la direcci´on 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 direcci´on de memoria posterior al GIF libre. Es decir, tras los cuatro colores
que defini´eramos en su momento. En esa posici´on guardamos el GIF mediante la ins-
trucci´on de almacenamiento (sq en este caso). Tal y como rezan los comentarios del
c´odigo, nos limitamos posteriormente a cargar la informaci´on que rellenamos en otro
fichero 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 c´alculos 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 transformaci´on 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, multiplicar´a por el inverso.
Recordemos que el registro flotante vf00, al igual que el entero vi00 contiene valores
constantes en ´el, que no se pueden modificar. 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 floatScreenVec
vec x mat trans vert, vert in, Transform
div q, vf00[w], trans vert[w]
mulq floatScreenVec, trans vert, q
Como el v´ertice de referencia que usamos es el centro de la pantalla, y queremos
pintar barras ordenadas en frecuencia, lo m´as sencillo para simplificar el bucle futuro
es movernos ´ unicamente en una direcci´on, en lugar de tener que hacerlo en ambas.
Por tanto, lo que hacemos es desplazar la posici´on 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. Definimos el n´ umero de iteraciones que har´a 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
´
ITULO 3. DESARROLLO DEL PROYECTO
; 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 floatScreenVec, floatScreenVec, 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 especificando tri´angulos, lo que
implica tres v´ertices 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 c´odigo trata la iniciaci´on de las variables necesarias para calcular
temas relativos al dibujado de las barras. Situamos los punteros donde grabaremos
la informaci´on de los v´ertices (color y posici´on). 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 separaci´on 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 dibujar´a 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 floatScreenVec, floatScreenVec, 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 posici´on de cada v´ertice relativa a la
posici´on de referencia debidamente desplazada seg´ un la ca-
dencia anterior. As´ı, definimos los seis v´ertices que conforman
nuestra primitiva, cada uno de ellos con la correspondiente
informaci´on relativa al color. La distribuci´on de los seis v´erti-
ces se muestra en la figura de la derecha. Como se aprecia,
tras grabar el valor del v´ertice o color, incrementamos los
respectivos punteros. Disponemos de dos colores por canal,
que generaran un gradiente. Los v´ertices 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 floatX1Y1, floatScreenVec
ftoi4 ScreenVec, floatX1Y1
sq ScreenVec, 0(iXYZF2 out) ; graba XYZF2
iaddiu iXYZF2 out, iXYZF2 out, 2
; — color —
ftoi0 screenCol, color
sq screenCol, 0(iRGBAQ out)
iaddiu iRGBAQ out, iRGBAQ out, 2
Proporcionada la informaci´on relativa a los seis v´ertices que forman nuestra pri-
mitiva, podemos enviarla a la cola de v´ertices 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 canci´on. La instrucci´on xgkick
manda la informaci´on de los v´ertices al sintetizador gr´afico. Adelantamos el puntero a
una zona libre, y escribimos el nuevo GIF para definir el canal que resta.
; deshace la subida para el beat detection
add.y floatScreenVec, floatScreenVec, 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
posici´on, 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 definir los seis v´ertices que conformar´an el rect´angulo.
iaddiu iRGBAQ out, iKick, 1 ; puntero para grabar los RGBAQ
iaddiu iXYZF2 out, iKick, 2 ; puntero para grabar los XYZF2
add.y floatScreenVec, floatScreenVec, MiValor2
add.y MiValor, vf00, barrasOrig2[x]
; — crear primitivas —
; vertice 1
move floatX1Y1, floatScreenVec
ftoi4 ScreenVec, floatX1Y1
sq ScreenVec, 0(iXYZF2 out) ; graba XYZF2
88 CAP
´
ITULO 3. DESARROLLO DEL PROYECTO
iaddiu iXYZF2 out, iXYZF2 out, 2
; — color —
ftoi0 screenCol, color3
sq screenCol, 0(iRGBAQ out)
iaddiu iRGBAQ out, iRGBAQ out, 2
De manera similar a lo que ocurr´ıa en el otro canal, una vez conclu´ıda la especi-
ficaci´on de los v´ertices que forman la barra, se env´ıa al sintetizador gr´afico. Movemos
el puntero al inicio, para escribir la informaci´on 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 conclu´ıdo, nos desplazamos horizontalmen-
te por la pantalla, para pintar la siguiente barra con una separaci´on hasta la anterior,
como hemos hecho entre cada par de barras.
; deshace la subida para el beat detection
sub.y floatScreenVec, floatScreenVec, 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 floatScreenVec, floatScreenVec, MiValor ; MiValor.x = ancho
add.x floatScreenVec, floatScreenVec, 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
m´as vueltas que realizar. Si es afirmativo, volvemos a LOOP para comenzar a dibujar
las siguientes cuatro barras. En caso contrario, reiniciamos el programa desde START0.
; fin de la vuelta, queda una menos
iaddi cuenta, cuenta, −1
ibne cuenta, vi00, LOOP
−−cont
b START0
.END
Cap´ıtulo 4
Optimizaci´ on del programa
sobre el hardware
En este cap´ıtulo nos centraremos sobre la distribuci´on de la carga inicial del pro-
cesador central hacia la unidad vectorial VU0, funcionando como coprocesador para ´el,
logrando una integraci´on de c´omputo entre el MIPS y la VU0 dentro del mismo c´odigo
gracias a la posibilidad de insertar c´odigo 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 suficiente para procesar toda la carga que le hab´ıamos propuesto. Sin
embargo, conocedores de que era f´acil distribuir gran parte de la carga pesada del
procesador central a c´alculos en la VU0 ejecut´andose como coprocesador (en lo que
definimos como macro modo), proseguimos con la programaci´on del apartado gr´afico
sin prestarle mayor atenci´on 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 c´odigo que supon´ıan un uso muy considerable
de CPU, y que pod´ıan ser f´acilmente transladadas en su totalidad.
Primero haremos una breve introducci´on a la forma empleada para programar el
c´odigo para usar la VU0 como unidad de coprocesamiento, y los detalles a tener en
cuenta cuando usemos esta modalidad de programaci´on. Posteriormente, analizaremos
en mayor profundidad las secciones de c´odigo a transladar, y expondremos el c´odigo
equivalente una vez programado para la VU0.
4.1.1. Programaci´on 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 matem´atico, 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 autom´atica, se ejecutar´an
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 categor´ıas:
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 flotantes 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 c´alculo de coprocesador: conforman el repertorio de operaciones
que se pueden realizar con los datos. Valor absoluto, sumas, productos, restas,
divisiones, producto-suma, m´aximos, m´ınimos, ra´ıces cuadradas, operaciones l´ogi-
cas y generaci´on 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 ejecuci´on de un
programa hecho en micro c´odigo desde la forma de ejecuci´on como coprocesador,
realizando una llamada a dicha subrutina. As´ı, se puede mezclar macro c´odigo
con micro c´odigo.
Una forma de empotrar c´odigo ensamblador en el c´odigo C es usar el m´etodo
((in line)). Este m´etodo consiste en emplear la sentencia asm para escribir una por-
ci´on de c´odigo 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 programaci´on 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, est´abamos suficientemente
familiarizados con el proceso de integraci´on comentado, y optamos directamente por
este m´etodo de programaci´on. Para aquellos que no hayan tenido contacto anterior con
la programaci´on de ASM y C al mismo tiempo, existe una p´agina [12] donde re´ unen in-
formaci´on sobre la programaci´on de ensamblador bajo linux. En dicha p´agina podemos
encontrar un enlace a un ´art´ıculo [44] que hace una descripci´on sobre la forma de de
programaci´on ((in line)). Aqu´ı resumiremos lo esencial para entender el c´odigo que usa-
remos nosotros. Si se desea profundizar m´as, se remite a las referencias proporcionadas
en este p´arrafo, as´ı como a las asignaturas mentadas.
La estructura general de la sentencia asm la mostramos a continuaci´on:
asm ( c´odigo 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 confusi´on adicional puede tratarse de hacer una asignaci´on
equivalente a una del tipo a = b en C, solo que realizada en ensamblador dentro de
un programa en C. Quedar´ıa:
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 c´odigo asm */
);
Con lo descrito hasta aqu´ı, consideramos que se entender´a la mec´anica b´asica de
esta forma de inserci´on de c´odigo ensamblador dentro de programas C. Quien desee
profundizar m´as 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 extensi´on el potencial
de este tipo de incrustaci´on de c´odigo, y m´axime teniendo en mente que el repertorio
de instrucciones que emplearemos ser´a totalmente distinto, ya que no se trata de una
arquitectura mentada en ninguno de los documentos que hemos propuesto, cuya finali-
dad principal es la de mostrar c´omo se puede interactuar en una mezcla de alto y bajo
nivel con el sistema operativo.
Haciendo las primeras pruebas para probar a insertar c´odigo 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 documentaci´on, el problema es simplemente la alineaci´on de las variables: ((si la
direcci´on efectiva (GPR[base]+offset) no est´a situada en una frontera de 128 bits, es
decir, los 4 bits menos significativos no son cero, el EE generar´a una excepci´on de error
en la direcci´on)). Por tanto, debemos alinear las variables que vayamos a usar para la
VU0.
Para ello generaremos una funci´on encargada de tal tarea. El funcionamiento b´asi-
co es reservar el n´ umero suficiente de bits para poder desplazar el inicio del puntero, de
forma que est´e alineado con una frontera de 128 bits. Necesitamos que los ´ ultimos cua-
tro bits de la direcci´on de memoria sean cero. Si hacemos un algoritmo ((siempre hacia
delante)), es decir, siempre desplazando el puntero hacia delante para alinear, aunque el
m´ınimo cambio para alinear el puntero se consiguiera desplaz´andolo hacia atr´as, pode-
mos determinar que la cantidad m´axima de bits a desplazar siempre ser´a inferior a 128
bits. Por tanto, reservarmos 128 bits adicionales de memoria. Como el direccionamiento
a memoria, y en general cualquier operaci´on con la memoria, se realiza a nivel de byte
como m´ınima unidad, calculamos la direcci´on de memoria m´as cercana hacia delante
que es frontera de 128 bits, y desplazamos el puntero a ella. La funci´on resultante la
escribiremos a continuaci´on por si se quiere analizar.
/*
* Funcion que alinea un vector de tam componentes flotantes a una
* frontera de 128 para evitar un ’bus error’ al enviarlo del EE a la VU
*/
float * alineaF128 (int tam)
{
float * tmp;
int d;
tmp = (float *) malloc(sizeof (float)*(tam+4));
fprintf (stderr, "reservado de %p a %p -->", tmp, tmp+(tam+3));
d = (0x10 − ((int)tmp & 0x0F))/sizeof (float);
if (d < 4)
tmp += d;
fprintf(stderr, " %p\n", tmp);
92 CAP
´
ITULO 4. OPTIMIZACI
´
ON DEL PROGRAMA SOBRE EL HARDWARE
return tmp;
}
4.2. Secciones de c´odigo a optimizar
Haciendo uso de las herramientas de las que disponemos para hacer an´alisis de
recursos y uso de procesamiento de nuestro programa, operaci´on tambi´en conocida
como ((profiling)). El programa principal en el MIPS est´a formado por una serie de
tareas secuenciales, que son:
1. Decodificaci´on 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 hist´orico.
Realizando un estudio del ((peso)) de cada tarea en la ocupaci´on final del procesador
mediante la utilidad top, determinamos que las tareas m´as pesadas computacionalmen-
te conforman la decodificaci´on a PCM, el c´alculo de la FFT, el proceso de frecuencias
en conjuntos de frecuencias y la conversi´on de conjuntos de frecuencias a altura.
Ahora debemos seleccionar tareas para migrarlas a la unidad vectorial VU0, de
manera que su implementaci´on se adapte a las propiedades de c´omputo que provee
dicha unidad. Recordemos que, en general, toda la arquitectura de c´omputo espec´ıfica
de la PlayStation2 est´a dise˜ nada para operar con vectores de cuatro elementos, repre-
sentaci´on 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 decodificaci´on 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 pr´acticamente similares en cuanto ocupaci´on, rondando en torno al 20 %
cada una. Sin embargo, esta tarea de decodificaci´on de ogg vorbis s´ı representa una
caracter´ıstica 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 cu´adrupla en el espacio 3D, la decodificaci´on no cumple siquiera un flujo
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 flujo
f´acilmente trasportable a la unidad vectorial, lo que implica una integridad en la VU0
bastante limitada, lo que supone una optimizaci´on muy baja, en caso de producirse.
El c´alculo de la FFT por contra, s´ı sigue una estructura de operaci´on amoldable
al c´alculo de las unidades vectoriales. Mantiene para una serie de datos las mismas
operaciones, y va almacenando el resultado. Podr´ıa visualizarse como un procedimiento
4.2. SECCIONES DE C
´
ODIGO A OPTIMIZAR 93
SIMD (una instrucci´on, m´ ultiples datos) sobre un conjunto de valores de entrada, la
PCM en este caso concreto. Es un proceso con una proyecci´on hacia la VU0 v´alida.
El c´alculo 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. Tambi´en presenta una clara estructura SIMD, y su proyecci´on en la VU0
es bastante inmediata. El procesamiento de los conjuntos de frecuencias realiza una
serie de operaciones ponderadas con un hist´orico 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, est´a extra´ıdo de una aplicaci´on real, y
se requiere una velocidad de c´omputo aceptable para no generar cuellos de botella en
el funcionamiento de dicha aplicaci´on. Por contra, nuestros algoritmos de clasificaci´on
en conjuntos de frecuencias y procesamiento de los conjuntos de frecuencias no han
sido optimizados ni si quiera para una arquitectura gen´erica, y presentan al menos la
misma complejidad computacional que el c´alculo de la FFT optimizado, convirti´endose
ambos procesos en una de las principales ocupaciones de la CPU. Por tanto, aunque
optimizar la FFT supondr´ıa una mejora notable, optimizar uno cualquiera de los otros
dos procesos supondr´a la misma mejora como m´ınimo, ya que la complejidad computa-
cional es semejante, y hay que tener en cuenta que el c´odigo de los mismos ni siquiera
est´a optimizado, por lo que se har´ıa una doble mejora. Tambi´en repercute el hecho
de que la implementaci´on de la FFT es m´as compleja y posee un cauce menos lineal
que paralelizar, ya que requiere de inversi´on de bits y distintas conversiones internas
para funcionar. Sin embargo, el otro par de procesos no requieren procesamientos in-
ternos aparte del computacional, simplificando el flujo de operaci´on a un simple flujo
de c´omputo, sin ramificaciones condicionales o incondicionales siquiera.
4.2.1. Procesamiento de frecuencias a conjuntos de frecuencias
El c´odigo original de procesamiento posterior a la FFT es uno de los cuellos de
botella que presenta nuestra aplicaci´on en el procesador MIPS. El c´alculo 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 m´as 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 SIZE−1; 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, simplificamos todos los c´omputos de escalado en una
constante para evitar operaciones innecesarias. Nos queda para cada canal un producto
94 CAP
´
ITULO 4. OPTIMIZACI
´
ON DEL PROGRAMA SOBRE EL HARDWARE
y una ra´ız cuadrada. El problema reside principalmente en la ra´ız cuadrada. El procesa-
dor MIPS no dispone de ra´ız cuadrada como instrucci´on, ya que su unidad aritm´etica
se limita a operaciones con n´ umeros enteros. Para ello se a˜ nadi´o la FPU, encargada de
realizar todos los c´omputos con aritm´eticas flotantes. Por tanto, aunque nos refiramos
constantemente al MIPS, debemos tener en cuenta que la carga est´a repartida entre el
procesador MIPS y la FPU a la hora de realizar las operaciones de c´omputo que, como
sabemos, son pr´acticamente en su totalidad con n´ umeros flotantes.
La ra´ız cuadrada como instrucci´on la proporciona el coprocesador matem´atico
COP1, o bien la unidad vectorial VU0. Hemos comprobado que la velocidad del COP1
(la FPU del MIPS) no es suficiente para realizar todo el n´ umero de operaciones que
debe completar en un tiempo determinado. Debido a la mayor velocidad y capacidad de
c´omputo 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 implementaci´on ´ıntegra en la VU0 del procedimiento. La
instrucci´on VSQRT calcula la ra´ız cuadrada de un n´ umero flotante en 7 ciclos, en
contraposici´on 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 divisi´on ni
de la ra´ız cuadrada), calcularemos el post procesamiento de cuatro valores por iteraci´on,
lo que supone reducir en una cuarta parte el n´ umero de iteraciones, con la ganancia
de ciclos inherentes a los posibles fallos de predicci´on de saltos. Calcularemos los
dos canales tambi´en, para evitar tener que cargar la constante dos veces, minimizando
la latencia asociada a la transferencia. La mec´anica que seguiremos ser´a calcular las
cuatro ra´ıces 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 simult´anea. Tras obtener el resultado de las cuatro ra´ıces
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 flujo 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 instrucci´on de
la ra´ız cuadrada en la VU0 es mucho m´as r´apida que la del MIPS, adem´as de que, como
se indica, la multiplicaci´on opera cuatro n´ umeros al mismo tiempo. Es una l´astima que
la instrucci´on de c´alculo de la ra´ız cuadrada solo pueda operar con un valor de
entrada a la vez, lo que hace necesaria la secuencializaci´on del c´alculo de las ra´ıces,
como se comprueba en el diagrama del flujo.
Figura 4.1: Flujo de datos que sigue la implementaci´on del clasificador de frecuencias
en conjuntos de frecuencias: (a) en el MIPS, (b) el flujo de datos perteneciente a la
implementaci´on en la VU0.
96 CAP
´
ITULO 4. OPTIMIZACI
´
ON DEL PROGRAMA SOBRE EL HARDWARE
4.2.2. Procesamiento de los conjuntos de frecuencias
Otra parte del c´odigo que requiere gran procesamiento de c´alculo 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 m´as
que la interpolaci´on 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 l´ımite
m´aximo, que situaremos seg´ un la altura m´axima posible que queramos darle a la barra.
La saturaci´on es necesaria para asegurarnos unos l´ımites en cuanto a valores que recibe
el procedimiento de dibujar la barra, ya que al situar los v´ertices fuera del ´area de
dibujo puede provocar errores en la visualizaci´on. Esta operaci´on la calcularemos una
vez por canal, para cada una de las barras a mostrar. El c´odigo en C que conforman
estas operaciones se muestra a continuaci´on:
// sin usar la VU0
Mis barras1[j−1]=ytamH[0][j]= ytamH[0][j]*0.9
+ barras[0][j]*alfa;
if (Mis barras1[j−1] < −LIMITE)
Mis barras1[j−1] = −LIMITE;
Mis barras2[j−1]=ytamH[1][j]= ytamH[1][j]*0.9
+ barras[1][j]*alfa2;
if (Mis barras2[j−1] > LIMITE)
Mis barras2[j−1] = LIMITE;
Como hemos comentado, realizamos una interpolaci´on entre el valor anterior y
el presente, cada uno de ellos ponderados por una constante. Las unidades vectoriales
disponen de una instrucci´on de producto y suma a la vez, que emplearemos para realizar
el segundo producto y la interpolaci´on en un paso. La saturaci´on con el l´ımite la haremos
empleando las instrucciones de m´aximo y m´ınimo que ofrecen, que permiten rellenar
un registro con el valor m´aximo de dos registros, campo a campo. A continuaci´on
pondremos el procedimiento para el canal derecho. El canal izquierdo es id´entico salvo
el uso de la instrucci´on vmin en lugar de vmax para la cota de l´ımite.
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 flujo m´as paralelo de ejecu-
ci´on, ya que operamos de cuatro en cuatro valores, y conseguimos adem´as reducir
una operaci´on gracias a la ya mencionada operaci´on de producto-suma que ofrece la
unidad vectorial. Esto nos permite trabajar de cuatro en cuatro valores, y hacer un
n´ umero menor operaciones adem´as. Gracias a la compatibilidad para cuatro operandos
simult´aneos de las instrucciones de m´aximo y m´ınimo, podemos realizar la saturaci´on
para los cuatro valores calculados simult´aneamente, evitando la comprobaci´on valor
por valor. Al contrario de lo que ocurr´ıa en el procedimiento analizado en la secci´on
4.2.1 debido a la operaci´on de ra´ız cuadrada, en esta ocasi´on todas las operaciones
que necesitamos realizar soportan cuatro operandos simult´aneos sobre los que operar,
no teniendo necesidad de detener el paralelismo de cuatro en cuatro datos en todo el
flujo.
Figura 4.2: Flujo de datos que sigue la implementaci´on del procesamiento de conjuntos
de frecuencias: (a) en el MIPS, (b) el flujo de datos perteneciente a la implementaci´on
en la VU0.
4.3. An´alisis de la ganancia obtenida
Vamos a intentar calcular la ganancia que hemos obtenido con la optimizaci´on
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
inform´atico al utilizar alg´ un m´odulo o componente de ejecuci´on m´as r´apido
esta limitada por la fracci´on de tiempo que se puede utilizar ese m´odulo o
componente.
Si expresamos la Ley 1 como una formulaci´on matem´atica, obtenemos la expresi´on
(4.1), donde f es la fracci´on de c´odigo que se puede mejorar, y a la aceleraci´on de la
98 CAP
´
ITULO 4. OPTIMIZACI
´
ON DEL PROGRAMA SOBRE EL HARDWARE
mejora.
Ganancia =
rendimiento con mejora
rendimiento sin mejora
=
T sin mejora
T con mejora
=
1
(1 −f) +
f
a
(4.1)
Intentaremos aplicar dicha formulaci´on para obtener la fracci´on de c´odigo que
hemos paralelizado, y la ganancia m´axima te´orica. Para ello debemos calcular primero
la aceleraci´on que produce el uso de la unidad vectorial VU0 en lugar de la FPU.
Dada la ausencia de herramientas de monitorizaci´on para las unidades vectoriales,
procederemos a realizar una estimaci´on basada en el tiempo de c´alculo empleado para
realizar las secciones optimizadas. Dicha estimaci´on la realizamos en base a la siguiente
suposici´on: el tiempo necesario para realizar los c´alculos sujetos de optimizaci´on ya
mentados es el mismo est´en formando parte del todo de la aplicaci´on o bien se ejecuten
como procedimientos independientes aislados del mismo.
Para calcular la aceleraci´on, haremos un programa de diagn´ostico, que realizar´a un
n´ umero considerable de veces los procedimientos sujetos de optimizaci´on, tanto con
la implementaci´on para el MIPS+FPU como para la VU0. El n´ umero de veces que
se repite la operaci´on de c´alculo ha de ser suficientemente grande como para poder
considerar que tiende al l´ımite te´orico de su capacidad de procesamiento, intentando
minimizar la sobrecarga de las transiciones de DMA, memorias y fallos en la posible
predicci´on de saltos. Se calcular´a el tiempo de ejecuci´on de ambas, y se obtendr´a la
mejora que supone el uso de la VU0 frente al MIPS+FPU.
Cap´ıtulo 5
Formato Ogg Vorbis
En este cap´ıtulo detallamos de forma exhaustiva el formato de codificaci´on vorbis,
as´ı como los pasos necesarios para su decodificaci´on, y las partes de las que se compone
el formato de fichero en el que va encapsulado.
5.1. Introducci´on al formato
El formato ogg vorbis puede codificar desde 8kHz a 192kHz, y desde 1 hasta
255 canales digitales, considerando stereo, cuadraf´onico y similares, con tasa variable
de bits en la compresi´on (VBR).
Aqu´ı nos centraremos ´ unicamente en la decodificaci´on del formato. Para una breve
introducci´on a la codificaci´on de Ogg Vorbis, puede consultarse un resumen [39] sobre
la compresi´on.
El n´ ucleo principal de funcionamiento en la reproducci´on es la Transformada Dis-
creta Modificada del Coseno (MDCT).
El formato vorbis es tan flexible que no provee protecci´on de ninguna clase frente
a errores. Los paquetes de datos que conforman el fichero no tienen tama˜ no m´ınimo,
ni m´aximo ni un tama˜ no esperado. Est´an dise˜ nados para poder ser truncados y que su
decodificaci´on sea posible. La capa de transporte que se encarga de detectar los fallos
es en nuestro caso ogg.
Vorbis puede iniciar la decodificaci´on de cualquier paquete en cuanto el deco-
dificador haya sido iniciado con las cabeceras de configuraci´on que especifica las pro-
piedades de la onda a producir. Los componentes del decodificador se muestran en la
Figura 5.1.
Figura 5.1: Componentes del decodificador de Ogg Vorbis
99
100 CAP
´
ITULO 5. FORMATO OGG VORBIS
donde:
mode: consiste en la configuraci´on 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 especifica la configuraci´on a usar para
la decodificaci´on y s´ıntesis de los paquetes de bajo nivel
mapping: contiene una descripci´on de los canales y una lista de ’submapas’ sobre
canales para la codificaci´on decodificaci´on en grupo. Los submapas indican el
floor y el residue apropiado para la decodificaci´on. Por ejemplo, si es un audio en
formato 5.1, el sexto canal ser´a solo el bajo, por lo que para este canal se usar´a un
floor que solo codifica bajos, en lugar de emplear uno de rango completo, lo que
ser´ıa un gasto innecesario.
floor: uno de los pilares de la decodificaci´on. Es la representaci´on a baja reso-
luci´on del espectro de audio para el canal dado en el frame actual. Puede ser de
dos tipos:
• Floor 0 usa una representaci´on 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 cr´ıticas del o´ıdo humano.
La escala se define en t´erminos de frecuencia en Hz entre el n´ umero de
Bark)
• Floor 1 representa la curva como una representaci´on lineal a trozos inter-
polada de la amplitud en decibelios en una escala de frecuencia lineal.
Ambos tipos son sem´anticamente equivalentes, pero se prefiere siempre el tipo
1, debido a que es m´as estable entre frames y es considerado tambi´en computa-
cionalmente m´as sencillo que el tipo 0.
Los valores codificados/decodificados por un floor se compactan mediante una
codificaci´on entr´opica para ahorrar espacio. Una configuraci´on normalmente se
refiere a m´ ultiples codebooks de la lista. La codificaci´on entr´opica es una abs-
tracci´on, y cada floor puede elegir un codebook cualquiera cuando est´a codifi-
cando/decodificando.
residue: es el detalle de la onda de audio una vez que se le ha restado el floor.
Se codifica usando vectores cuantizados conforme uno de los tres algoritmos
espec´ıficos de codificaci´on/decodificaci´on, numerados de 0 a 2. Los detalles del
algoritmo de empaquetamiento los especifica el residue en concreto. Al igual que
en los floor, la codificaci´on entr´opica final se provee en codebooks externos y
cada residuo se puede elegir de entre todos los codebooks disponibles
codebooks: son abstracciones que realizan la decodificaci´on entr´opica y opcional-
mente, se usa el valor entero decodificado como´ındice en una tabla de vectores de
salida, devolviendo dicho conjunto de valores. El codificador entr´opico empleado
en el Vorbis I es un ´arbol binario representado en c´odigo Huffman est´andar.
5.2. Funcionamiento general del decodificador
5.2.1. Configuraci´on del decodificador
Lo primero que debemos hacer, es configurar el decodificador, 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 configuraci´on. 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 identificaci´on de que es una trama vorbis,
la frecuencia de muestreo, y el n´ umero de canales
Comment Header: contiene la informaci´on de texto sobre la trama, como es la
informaci´on sobre el codificador, y los campos asociados a la trama en s´ı, como
puede ser el autor, t´ıtulo, album...
Setup Header: contiene informaci´on extensiva sobre la configuraci´on del CO-
DEC, as´ı como los codebooks VQ y Huffman necesarios para decodificar
5.2.2. Pasos de la decodificaci´on
Los pasos a seguir en general son:
Decodificaci´on 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 est´a reservado, y un paquete con otro tipo deber´a 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, ser´a ignorado ese paquete.
Decodificaci´on del modo: especifica el modo a usar, ya que como hemos dicho
antes, se pueden definir varios modos de decodificaci´on. Es un entero que se usa
como ´ındice en la tabla de modos directamente.
Decodificaci´on de la forma de la ventana (solo ventanlas grandes): el frame
puede ser de uno de los dos tama˜ nos especificados durante la configuraci´on 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
define por canal.
Vorbis usa la MDCT, que solapa ventanas, para mezclar un frame con el sie-
guiente, evitando la mayor´ıa de las anomal´ıas 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 sim´etricas 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
ser´a preferible hacer uso de la informaci´on redundante que utiliza vorbis, ya que
en las ventanas grandes guarda dos bits que especifican la forma de la ventana
anterior y siguiente. Esto permite poder decodificar la ventana en ese mismo
punto, sin necesidad de leer el siguiente. Esto permite tambi´en alcanzar un mayor
grado de paralelismo.
La informaci´on relativa a la MDCT se puede encontrar en un documento [48] de
la European Signal Processing Conference.
Decodificaci´on 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 decodificaci´on no se correspondan
directamente a los canales especificados. Cuando se emplea emparejamiento de
canales, algunos vectores corresponder´an a magnitud o a ´angulo. La relaci´on se
102 CAP
´
ITULO 5. FORMATO OGG VORBIS
Figura 5.2: Tipo de solapamiento entre ventanas consecutivas.
especifica en la cabecera de configuraci´on, y puede cambiar de frame a frame
debido a la posibilidad de elecci´on de uno de los modos en cada frame.
La codificaci´on de los vectores de residues se hace en el orden de los submapas,
desde el 0 hasta el n − 1. En los floors en cambio se codifica 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 especificados en la configuraci´on del mapping actual. Es la misma para
todas las parejas, convertir la representaci´on polar en cartesiana. Tras deshacerlo,
el vector resultante contiene el detalle espectral de cada uno de los canales de
salida.
Generando la curva de floor: se puede generar esta curva en el momento que
el decodificador desee. Puede ser cuando el floor se decodifica del paquete, o se
puede generar tras el paso anterior y aplicado directamente al residuo espectral
obtenido, combinando la generaci´on y el producto escalar en un ´ unico paso.
Tanto el floor 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 floor/residue: este paso es bastante abierto.
Para cada canal de salida, el decodificador multiplica ambos vectores elemento
a elemento, produciendo el espectro de audio final de cada canal.
Un error com´ un es considerar que una representaci´on de punto fijo de 32 bits es
suficiente para el floor y el residue, y que el producto directo ser´a suficiente para
una resoluci´on aceptable de espectro porque funciona casi siempre con ficheros
generados por el codificador de Xiph.
Los floors pueden ser de ∼ 140dB (∼ 24 bits), y el espectro de audio debe re-
presentar un m´ınimo 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 floor vale
−140dB para alcanzar la escala completa, y entre −140 y 0dB si el floor 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 floor y
el residue ser´a un producto de 24 48 bits, por lo que se usar´a un tipo de dato
de al menos 64 bits o una representaci´on de coma flotante.
Transformada inversa del espectro: debemos aplicar una conversi´on 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 codificaci´on
de pulsos). Para ello se emplea la inversa de la transformada discreta modificada
del coseno presentada en el documento [48] mencionado con anterioridad.
Hay que tener en cuenta que la PCM resultante no es la se˜ nal final 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.
Superposici´on/adici´on 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 est´e 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 definitiva que ha de ser devuelta. En la Figura ??
se puede apreciar la parte que se solapa.
Cach´e del frame actual: el decodificador 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 final: como hemos dicho, la parte de audio decodificada
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 decodificador.
Despu´es del frame inicial, el offset del PCM es 0, ya que a´ un no se ha enviado
ning´ un dato.
5.3. Configuraci´on del codec y decodificaci´on del pa-
quete
5.3.1. Introducci´on
Este documento es una gu´ıa para la decodificacion bit a bit del formato Vorbis I.
Se asume un conocimiento general del funcionamiento del formato Ogg Vorbis I.
5.3.2. Decodificaci´on de la cabecera y configuraci´on del decodi-
ficador
Una trama Vorbis comienza con tres paquetes de cabecera: cabecera de identi-
ficaci´on, cabecera de comentarios y cabecera de configuraci´on. Se necesitan las tres
104 CAP
´
ITULO 5. FORMATO OGG VORBIS
para decodificar seg´ un lo acordado. Una condici´on de fin-de-paquete durante la deco-
dificaci´ on del primer o tercer paquete de cabecera hace la trama indecodificable. En la
decodificaci´on de la cabecera de comentarios produce un error no fatal.
Decodificaci´on 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 decodificaci´on contin´ ua seg´ un el tipo de paquete. La cabecera de identificaci´on
es el tipo 1, la de comentarios es la tipo 3 y la de configuraci´on 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: identificaci´on, comentario y configuraci´ on.
Cabecera de identificaci´on
La cabecera de identificaci´on es una cabecera corta de pocos campos empleados
para determinar que la trama es definitivamente un Vorbis, y proporcionar informaci´on
externa relevante sobre la trama de audio. Esta cabecera se decodifica:
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 finales 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
indecodificable.
Los campos de bitrate se usan solo como gu´ıas. El campo [nominal bitrate]
especialmente se puede considerar in´ util en flujos VBR (variable bit rate). Los campos
son de inter´es cuando son mayores de de cero.
Si los tres campos est´an al mismo valor, indica que o bien es una tasa constante
de bits por segundo, o bien los l´ımites est´an muy pr´oximos a una de tasa fija,
teniendo poco margen de detalle
5.3. CONFIGURACI
´
ON DEL CODEC Y DECODIFICACI
´
ON DEL PAQUETE 105
Valores superiores o inferiores implican una trama VBR que obedece la limitaci´on
establecida
Si no se ha asignado ning´ un valor indica que el codificador no se molest´o en
especular
Cabecera de comentarios
Es la encargada de proporcionar la informaci´on sobre la trama codificada en Vorbis.
Campos como el autor, compositor, estilo de m´ usica, t´ıtulo de la canci´on van en esta
cabecera. Los detalles de decodificaci´on de esta cabecera van reflejados en otra secci´on,
separada de ´esta, pues no es relevante para decodificar el sonido de la trama.
Cabecera de configuraci´on
EL codec de Vorbis es configurable en extremo: La cabecera de configuraci´on
contiene la informaci´on crucial de la configuraci´on del codec, necesaria para la de-
codificaci´on. Contiene, en orden, las listas de las configuraci´ones de codebook, las
configuraciones de la transformada tiempo-dominio, las configuraciones de los floor,
configuraciones de los residuos, configuraci´on del mapeado de canales y de la confi-
guraci´on de los modos. Finaliza con un bit de frame a ’1’. La Decodificaci´on de la
cabecera procede de la siguiente forma:
Codebooks El proceso de configuraci´on relativa a los codebooks es el mostrado a
continuaci´on:
1. [vorbis codebook count] ← uint8 +1
2. Decodificar [vorbis codebook count] codebooks en orden tal y como se des-
cribe en la secci´on de codebooks. Grabar la configuraci´on de cada uno en orden,
en un vector de configuraciones [vorbis codebook configurations].
Transformaci´on tiempo-dominio Est´an 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 condici´on de error y la trama es indecodificable.
Floors Vorbis usa dos tipos de floors; la decodificaci´on de la cabecera est´a constitu´ıda
de forma que es capaz de decodificar seg´ un el tipo apropiado.
1. [vorbis floor count] ← uint6 +1
2. para cada uno de los [vorbis floor count] floor:
a) lee el tipo del floor
b) [vorbis floor types]
[i]
← uint16
c) si (tipo = 0) ⇒decodifica la configuraci´on del floor seg´ un el tipo 0 y graba
la configuraci´on en [vorbis floor configurations]
[i]
si no, si (tipo = 1) ⇒ decodifica la configuraci´on del floor seg´ un el tipo 1
y graba la configuraci´on en [vorbis floor configurations]
[i]
si no, (tipo > 1) ⇒ la trama es indecodificable: CONDICI
´
ON DE ERROR
106 CAP
´
ITULO 5. FORMATO OGG VORBIS
Residuos Vorbis usa tres tipos de residuos; la decodificaci´on de sus cabeceras es
id´entica.
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) ⇒ decodifica la configuraci´on de residuos seg´ un el
tipo, y gr´abala en [vorbis residue configurations]
[i]
si no, (tipo > 2) ⇒ la trama es indecodificable: CONDICI
´
ON DE ERROR
Mapeado Los mapeados se usan para configurar pipelines espec´ıficos para la codifi-
caci´on multicanal de audio con varias aplicaciones de mapeado de canal. Vorbis I usa
un tipo ´ unico de mapeado, con los mapeados de canales PCM impl´ıcitos.
1. [vorbis mapping count] ← uint6 +1
2. para cada [i] de los [vorbis mapping count] mapeados:
leer el tipo: un uint16 (no hay raz´on para almacenarlo)
si (tipo ,= 0) ⇒ trama indecodificable
si no, (tipo = 0) ⇒
a) bandera booleana ← 1 bit
b) si est´a activa ⇒ [vorbis mapping submaps] ← uint4 +1
si no est´a activa ⇒ [vorbis mapping submaps] ←1
c) bandera booleana ← 1 bit
d) si est´a 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 representar´a la mag-
nitud y el canal que representar´a el ´angulo, respectivamente.
Si ambos son iguales o el de magnitud o ´angulo es mayor que
[audio channels]−1, la trama es indecodificable
e) lee 2 bits; si es distinto de cero, la trama es indecodificable
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)) ⇒ condici´on de
error: trama indecodificable
g) para cada submapa [j] de los [vorbis mapping submaps], lee el
n´ umero de floor y residuos a usar para decodificarlo:
• lee y descarta 8 bits (la configuraci´on tiempo-dominio no usada)
5.3. CONFIGURACI
´
ON DEL CODEC Y DECODIFICACI
´
ON DEL PAQUETE 107
• [vorbis mapping submap floor]
[j]
← uint8
• verifica que el n´ umero de floor no es mayor que el m´aximo de los
configurados para la trama. Si lo es, la trama es indecodificable.
• [vorbis mapping submap residue]
[j]
← uint8
• verifica que el n´ umero de residuo no es mayor que el m´aximo de
los configurados para la trama. Si lo es, la trama es indecodificable
h) [vorbis mapping configurations]
[i]
← esta configuraci´on 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 m´axi-
mo de los mapping en uso. Cualquier valor ilegal convierte a la trama en
indecodificable.
f ) [vorbis mode configurations]
[i]
← esta configuraci´on
3. lee 1 bit como bandera de frame.
4. Si (bandera no activa) ⇒ error en el frame, trama indecodificable
Trase leer las descripciones de los modos, la decodificaci´on de la cabecera de
configuraci´on se ha completado.
5.3.3. Decodificaci´on y s´ıntesis 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 corrupci´on de trama o de una trama que no sigue las
especificaciones. El decodificador debe ignorar el paquete y no intentar decodificarlo a
audio.
Decodificaci´on 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. selecci´on y configuraci´on de ventana ¦´esta se usar´a luego en la MDCT inversa¦:
108 CAP
´
ITULO 5. FORMATO OGG VORBIS
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 ser´a corta
Las ventanas de Vorbis usasn siempre la misma curva envolvente y = sin(2πsin
2
(
x
n
)),
pero un solapamiento de ventanas de distintos tama˜ nos pueden afectar a la forma final
de la curva. La generaci´on de la ventana es como se indica a continuaci´on:
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(2πsin
2
(
[i]−[left window start]+0,5
[left n]∗
π
2
))
5.3. CONFIGURACI
´
ON DEL CODEC Y DECODIFICACI
´
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(2πsin
2
(
[i]−[right window start]+0,5
[right n]∗
π
2
+
π
2
))
9. ventana
[right window start]...[n]−1
← 0
Una condici´on de fin-de-paquete hasta este momento deber´ıa ser considerado un
error y descartar el paquete entero de la trama. Si ocurre pasado este punto, se puede
considerar un hecho posible.
Decodificaci´on del floor
Asumimos desde ahora que la decodificaci´on usa el modo [mode number] del vec-
tor de configuraci´on [vorbis mode configurations] y el mapeado [vorbis mode mapping]
tomado del vector de configuraciones de mapeado [vorbis mapping configurations].
Las curvas floor se decodifican una por una, en el orden de los canales.
para cada floor [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) ⇒ decodifica el floor para el
canal [i] seg´ un el algoritmo del floor 0
si no, si ([vorbis floor types]
[floor number]
= 1) ⇒ decodifica el floor
para el canal [i] seg´ un el algoritmo del floor 1
4. guarda la informaci´on decodificada del canal para la s´ıntesis posterior
5. si (floor decodificado = ’no usado’) ⇒ [no residue]
[i]
← verdad
si no, (floor decodificado ,= ’no usado’) ⇒ [no residue]
[i]
← falso
Una condici´on de fin-de-paquete durante la decodificaci´on deber´ıa resultar en una deco-
dificaci´on de todo ceros en los canales de salida, y saltando la fase de suma/solapamiento.
Propagaci´on de los vectores no nulos
Un resultado posible de la decodificaci´on del floor es que un vector espec´ıfico
est´e marcado como ’no usado’, lo que indica que ese vector final ser´a un vector lleno
de ceros (lo que implica un floor de cero). El vector de residuos de ese vector no
est´a codificado en la trama, evitando una complicaci´on. 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
´
ITULO 5. FORMATO OGG VORBIS
Decodificador de residuos
A diferencia de los floors, que se decodifican seg´ un el orden del canal, los residuos
se decodifican 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. decodificar los [ch] vectores usando el residuo [residue number], seg´ un
el tipo [residue type], pasando tambi´en el vector [do not decode flag]
para indicar qu´e vectores no deben ser decodificados. La longitud decodifi-
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
decodificados [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 CODEC Y DECODIFICACI
´
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 floor del floor decodificado, seg´ un
el tipo de paquete. Hay que tener en cuenta que la longitud del vector para el c´alculo
del floor es de [n]/2.
Para cada canal, debemos multiplicar cada elemento de la curva de floor por cada
elemento del vector de residuos de dicho canal. El resultado es el producto escalar de
los vectores de floor 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
implementaci´on de punto fijo es asumir que una representaci´on de 32 bits de punto
fijo para floor y residuos, y la multiplicaci´on directa de ambos es suficiente para un
nivel de detalle del espectro aceptable en todos los casos porque parece funcionar con
el codificador 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 Modificada del Coseno
(MDCT). La informaci´on m´as detallada aparece en www.iocon.com/resource/docs/
ps/eusipco_corrected.ps. La ventana usada por la MDCT es la ventana que se
determin´o 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 est´e alineada con el punto
1/4 de la actual (tal y como se ilustr´o al inicio). La parte solapada obtenida del solapa-
miento del frame anterior y del actual son los datos finalizados que deben ser devueltos
por el decodificador. 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 est´an realmente
solapados, cosa que no supone un da˜ no a la ortogonalidad de la transformaci´on. Sim-
plemente hay que prestar atenci´on a la porci´on 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 decodifica-
ci´on. 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
´
ITULO 5. FORMATO OGG VORBIS
Orden de canales de salida
El formato Vorbis I solo especifica un tipo de mapeado de canales. En ´el, el
mapeado de canales est´a impl´ıcitamente definido como sigue para las aplicaciones
estandar de audio:
un canal: la trama es monof´onica
dos canales: la trama es est´ereo, con orden: izquierdo, derecho
tres canales: la trama es 1d-envolvente, con orden: izquierdo, central, derecho
cuatro canales: la trama es envolvente cuadraf´onico, 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)
m´as de seis canales: la aplicaci´on define el uso de cada canal y su orden
Las aplicaciones que usen Vorbis para prop´osito espec´ıfico pueden definir el ma-
peado de canales como prefieran. Futuros mapeados de canales (como el de tres y
cuatro canales Ambisonicos) har´an uso de otro tipo de mapeado distinto del 0.
5.4. Floor 0: configuraci´on y decodificaci´on
5.4.1. Introducci´on
Este tipo de floor usa una representaci´on LSP (Line Spectral Pair, tambi´en co-
nocido como LSF por Line Spectral Frecuency) para codificar una curva envolvente
de espectro de forma precisa como la frecuencia de respuesta del filtro LSP. Es una
representaci´on equivalente al tradicional filtro de respuesta infinita de todos los polos
usada en codificaci´on lineal predictiva. Se puede convertir de una a otra sin problema.
5.4.2. Formato Floor 0
La configuraic´on de este decodificador consiste en un campo de seis enteros y
una lista de codebooks VQ para codificar/decodificar los coeficientes del filtro LSP
empleado en cada frame.
Decodificaci´on de la cabecera
La cabecera dispone de los siguientes campos en el mismo orden que se mostrar´a a
continuaci´on, y se indicar´a si es necesario un procesamiento o condici´on adicional.
Los tipos de datos se expresar´an con una u si es sin signo (unsigned), seguido del
identificador del tipo de dato (int, float, . . . ), y expresando su longitud en bits a
continuaci´on. Si es un vector o array se expresar´a 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 decodificar
array [floor0 book list]: lista de [floor0 number of books] uint8
Una situaci´on de fin-de-trama en alguno de estos bits convierte a la trama en
indecodificable. Adem´as, si alg´ un elemento del array [floor0 book list] es mayor
que el m´aximo codebook de esa trama es una condici´on de error y hace tambi´en
indecodificable a la trama.
Decodificaci´on del paquete
Para generar la curva floor0 de un paquete hay primero que decodificar la amplitud
de la curva y los floor0 order coeficientes LSP de la trama, y entonces calcular la
curva floor, que se define como la respuesta en frecuencia del filtro LSP decodificado.
La decodificaci´on del paquete se hace de la siguiente forma:
[amplitude]: uint de [floor0 amplitude bits] bits
si ([amplitude] > 0) ⇒
1. [coefficients] es vector vac´ıo de 0 elementos
2. [booknumber] ← leer un uint de ilog ([floor0 number of books])
bits
3. si ([booknumber] > mayor n´ umero de decodificaci´on del codebook)) ⇒
paquete indecodificable
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 final del vector [coefficients]
8. si (longitud de [coefficients] < [floor0 order]) ⇒ continuar por el
paso 4
9. fin
Ahora veremos algunas propiedades de la decodificaci´on:
Un valor [amplitude] de 0 har´a que se devuelva un c´odigo indicando que ´este
canal no se usa en este frame (la salida del canal ser´a una sucesi´on de ceros).
Muchas de las etapas siguientes de decodificaci´on no se realizan para un canal
no usado.
114 CAP
´
ITULO 5. FORMATO OGG VORBIS
Si se encuentra una condici´on de fin-de-paquete durante la decodificaci´on, sim-
plemente se marcar´a el canal como no usado, al igual que en el caso anterior.
El n´ umero del book usado para decodificar se podr´ıa haber guardado en flujo
de datos en ilog([floor0 number of books]-1) bits, pero la especificci´on
anterior es correcta, y los valores mayores que el book m´aximo posible est´an
reservados.
El n´ umero de elementos le´ıdos 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 floor que est´a siendo decodificado 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 condici´on de
error, y hay que tener cuidado de no permitir un desbordamiento del buffer en la
decodificaci´on. Los valores extra no se usan y pueden ser ignorados o descartados.
C´alculo de la curva
Dada un entero [amplitude] y un vector [coefficients] de la decodifica-
ci´on de un paquete, y [floor0 order], [floor0 rate], [floor0 bark map size],
[floor0 amplitude bits] y [floor0 amplitude offset] de la configuraci´on del
decodificador, y un vector de salida de tama˜ no [n] especificado en el proceso de de-
codificaci´on, calcularemos un vector de floors como salida.
Si [amplitude] es cero, devolveremos un vector de [n] elementos con el valor
escalar 0. En caso contrario, supondremos las siguientes definiciones para el vector a
sintetizar:
bark(x) = 13,1atan(,00074x) + 2,24atan(,0000000158x
2
) +,0001x
map
i
= m´ınimo
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 c´alculo
de la curva LSP de salida [output] en una escala logar´ıtmica (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
4(cos([coefficients]
2j
) −cos(ω))
2
5.5. FLOOR 1: CONFIGURACI
´
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
4(cos([coefficients]
2j+1
) −cos(ω))
2
q =
(1 +cos(ω))
2
[floor0 order]−2
2

j=0
4(cos([coefficients]
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: configuraci´on y decodificaci´on
5.5.1. Introducci´on
Este m´etodo usa una representaci´on de funci´on a trozos lineales para codificar una
curva envolvente del espectro. La representaci´on dibuja esta curva de forma mec´anica
en un eje lineal de frecuencia y un eje logar´ıtmico (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 l´ınea. La
s´ıntesis construye una curva floor usando predicci´on iterativa en un proceso aproxima-
damente equivalente a la siguente descripci´on simplificada:
el primer segmento (caso base) es una l´ınea 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 floor
espectral a calcular.
el paso de inducci´on elige un punto x new en un segmento l´ogico existente y
produce una y new en ese punto, para el valor y en x new, y la diferencia deco-
dificada del paquete del flujo de datos.
el c´alculo del floor produce dos nuevos segmentos de l´ınea, 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 refinamientos posteriores tambi´en usar´an x new como valor
del extremo.
el paso de inducci´on se repite, usando una lista de valores de x especificada en
la cabecera del codec en la iniciaci´on del floor 1. El c´alculo se completa en el
´ ultimo valor de la lista de valores para x.
116 CAP
´
ITULO 5. FORMATO OGG VORBIS
Ahora veremos un ejemplo gr´afico para entender con mayor facilidad los puntos
anteriores.
Supongamos una configuraci´on del floor 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 decodificado de un paquete han sido 110, 20, −5, −45, 0, −25, −10, 30
y −10. Hacemos el floor de la siguiente forma, primero empezamos pintando la pri-
mera l´ınea, y calcularemos el valor de new Y para la primera coordenada X del vector,
teniendo en cuenta el valor de Y que decodificamos del paquete, como se ilustra en la
Figura 5.3
Figura 5.3: Reconstrucci´on del floor con dos puntos, y c´alculo de la diferencia en Y
con respecto a la estimaci´on inicial.
Ahora dibujaremos las nuevas l´ıneas para reflejar la correci´on 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 correcci´on 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
seguir´a usando como el extremo de los refinamientos asociados a esa parte de la curva.
El siguiente paso ser´ıa 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:
5.5. FLOOR 1: CONFIGURACI
´
ON Y DECODIFICACI
´
ON 117
Figura 5.5: Proseguimos refinando la curva con los valores asociados, corrigiendo cuan-
do es necesario.
Se usa un algoritmo m´as eficiente con un comportamiento de redondeo a entero
cuidadosamente definido para la decodificaci´on real, como se ver´a m´as adelante. El
algoritmo real parte el c´alculo de los valores de Y y el trazado de la curva en dos pasos
con modificaciones sobre el algoritmo anterior, para eliminar la acumulaci´on del error
producido por el redondeo/truncado de enteros.
Figura 5.6: Cuando todos los valores se han calculado, tenemos la reconstrucci´on de la
curva original.
5.5.3. Decodificacion de la cabecera
En la cabecera del paquete se almacena una lista de los valores X del floor en
formato entre (usado en orden de lista durante la decodificaci´on del paquete y la
s´ıntesis). Esta lista se parte en dos trozos, cada uno de los cuales se asigna a una clase
de partici´on. Las posiciones 0 y [n] de X son impl´ıcitas y no pertenecen a ninguna
partici´on expl´ıcita o clase de partici´on.
Una clase de partici´on consiste en un ancho de representaci´on del vector (el n´ umero
de valores Y que la partici´on codifica a la vez), un valor de subclase que representa
el n´ umero de books entr´opicos alternativos que puede usar la clase de partici´on para
representar los valores Y, la lista de [subclass] books y un book principal usado
para codificar qu´e books fueron elegidos para la representaci´on de un paquete dado. El
mecanismo de principal/sublcase est´a pensado para ser usado como una representaci´on
118 CAP
´
ITULO 5. FORMATO OGG VORBIS
flexible en cascada, mientras se mantiene el uso de los codebooks solo en un contexto
escalar.
Los pasos para obtener la informaci´on asociada de cabecera del paquete se indican
a continuaci´on.
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
11. itera [i] en el intervalo 0 . . . [floor1 partitions] −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. fin
Una condici´on de fin de paquete mientras se est´a leyendo en cualquier parte du-
rante la configuraci´on del floor 1 hace que la trama sea indecodificable. Adem´as, la
existencia de un valor del vector [floor1 class masterbooks] o del vector
[floor1 subclass books] superior al ´ındice m´aximo del codebook configurado pa-
ra esa trama es una condici´on de error que convierte a la trama en indecodificable
tambi´en.
5.5. FLOOR 1: CONFIGURACI
´
ON Y DECODIFICACI
´
ON 119
5.5.4. Decodificaci´on del paquete
La decodificaci´on comienza comprobando el flag [nonzero]:
1. [nonzero] ←1 bit como booleano
Si [nonzero] no est´a activado, indica que este canal no contiene energ´ıa de audio
en ese frame. La decodificaci´on inmediatamente devuelve un estado indicando que esta
curva floor (y por tanto este canal) no se usa en el frame. (Devolver un estado de ’no
usado’ es distinto de decodificar un floor en el que todos los puntos est´an situados en
la amplitud m´ınima, que suele ser aproximadamente −140dB).
Suponiendo que [nonzero] est´a activado, la decodificaci´on 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
5. itera [i] en el intervalo 0 . . . [floor1 partitions] −1
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. fin
Una condici´on fin-de-paquete durante la decodificaci´on de la curva deber´ıa ser
considerada una ocurrencia puntual. Si se alcanza un fin-de-paquete en alguna de las
operaciones de lectura anteriores, la decodificaci´on del floor devolver´a un estado de ’no
usada’ como si el bit [nonzero] no hubiera estado activo al inicio de la decodificaci´on.
El vector [floor1 Y] contiene los valores de la decodificaci´on del paquete necesarios
para la sintetizaci´on de la floor1.
120 CAP
´
ITULO 5. FORMATO OGG VORBIS
5.5.5. C´alculo de la curva
El c´alculo de la curva se divide de forma l´ogica en dos pasos. El primer paso obtiene
las amplitudes Y finales de la codificaci´on, usando los valores diferencia tomados del
flujo de datos. El segundo paso traza las l´ıneas de curvas. Aunque los valores con
diferencias de cero se usan en la predicci´on iterativa para calcular los valores finales de
Y, estos puntos se saltan de forma condicional durante el c´alculo final del paso segundo.
Saltar los valores de diferencia cero permite un ajuste m´as preciso de la curva.
Aunque algunos aspectos del algoritmo siguiente pueden parecer optimizaciones
inconsecuentes, se advierte a los implementadores que siguan la especificaci´on fielmen-
te. La no implementaci´on de un algoritmo estrictamente equivalente puede resultar en
graves errores de decodificaci´on.
S´ıntesis 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 predicci´on 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) ⇒
5.5. FLOOR 1: CONFIGURACI
´
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. fin
S´ıntesis de la curva
La s´ıntesis de la curva devuelve un vector [floor] de longitud [n] (donde
[n] viene dada desde el proceso de decodificaci´on que llama a la decodificaci´on del
floor). La s´ıntesis de la curva del floor 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 decodificaci´on 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 permutaci´on a los elementos de los otros dos vectores, para que
se siga correspondiendo elemento a elemento de forma correcta.
Tras esto, calcular la curva final 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. fin
122 CAP
´
ITULO 5. FORMATO OGG VORBIS
5.6. Configuracion y decodificacion de los residuos
5.6.1. Introducci´on
Un vector de residuos representa el grano fino del espectro de audio de un canal
en un frame de audio despu´es de que el codificador elimine la curva floor y realice el
emparejamiento de canales. Puede representar lineas espectrales, magnitudes espectra-
les, fases espectrales o h´ıbridos cuando se mezcla con el emparejamiento de canales.
La sem´antica del vector no influye en la abstracci´on de residuo.
Represente a lo que represente, la abstracci´on de residuo codifica el vector de
residuos en el paquete de vorbis, y reconstruye los vectores durante la decodificaci´on.
Vorbis hace uso de tres tipos diferentes de codificaci´on (numeradas como 0, 1, y 2) de
la misma abstracci´on de codificaci´on de vector.
5.6.2. Formato de residuos
El formato de residuos particiona cada vector del vector empaquetado en trozos,
clasificando cada uno, codificando la clasificaci´on de los trozos y finalmente codificando
los trozos mismo usando la clasificaci´on VQ espec´ıfica definida para cada clasificaci´on
elegida. El particionamiento y la intercalaci´on var´ıa seg´ un el n´ umero de codificaci´on del
residuo, aunque en los procesos de m´as alto nivel empleados para clasificar y codificar
el vector del residuo es el mismo en las tres variantes.
Un conjunto de vectores de residudos codificados tienen todos la misma longitud.
La estructura de codificaci´on 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
configuraci´on especificada. Si tenemos un vector de longitud n, un tama˜ no de
partici´on de residue partition size, y un total de ch vectores de residuos, el
n´ umero total de trozos codificados es
n
[residue partition size]
∗ch. Hay que destacar
que la divisi´on entera trunca. Para el ejemplo que veremos despu´es, supondremos
un [residue partition size] de 8.
Cada partici´on de cada vector tiene un n´ umero de clasificaci´on que especifica cu´al
de los codebooks VQ configurados se emplear´a para decodificar la partici´on. Los
n´ umeros de clasificaci´on de cada partici´on 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 codifican en particiones agrupadas para incremen-
tar la eficiencia de la codificaci´on, el vector de clasificaci´on tambi´en est´a divido
en fragmentos. Los elementos de tipo entero que conforman cada trozo de una
clasificaci´on se construyen como un escalar que representa el n´ umero de clasi-
ficaci´on en ese trozo. En el ejemplo de abajo, el c´odigo de clasficaci´on codifica
dos n´ umeros de clasificaci´on.
Los valores en un vector de residuos pueden codificarse en bloque de una sola
pasada por el vector de residuos, pero dise˜ nos m´as eficientes de codebook acon-
sejan que cada vector se codifique como la suma aditiva de varias pasadas por el
vector de residuos, usando m´as de un codebook VQ. As´ı, cada valor del residuo
acumula de forma potencial valores de m´ ultiples pasadas del decodificador. El
valor de clasificaci´on asociado con una partici´on es el mismo en cada pasada, por
lo que la clave de clasificaci´on se codifica solo en la primera pasada.
5.6. CONFIGURACION Y DECODIFICACION DE LOS RESIDUOS 123
Figura 5.7: Empaquetamiento de los residuos.
124 CAP
´
ITULO 5. FORMATO OGG VORBIS
Residuo 0
El residuo 0 y el 1 solo difieren en la forma en la que los valores de una partici´on
de residuos se intercalan en la codificaci´on de la partici´on (lo que en la figura anterior
eran las cajas de color marr´on y cyan).
La codificaci´on 0 de residuos intercala las codificaciones VQ seg´ un la dimensi´on
del codebook usdo para codificar una partici´on en una pasada espec´ıfica. La dimensi´on
del codebook no necesita ser la misma en m´ ultiples pasadas, solo se necesita que el
tama˜ no de la partici´on sea un m´ ultiplo exacto de la dimensi´on del codebook.
Como ejemplo, asumiremos un tama˜ no de partici´on de 8, para ser codificado 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 codificaciones VQ. Representa los escalares de
las particiones en orden. De todas formas, tal y como ocurr´ıa con el residuo 0, el tama˜ no
de la partici´on 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, codificado 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 codificar 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 ch∗n con todos sus elementos
intercalados. La codificaci´on procede entonces como en el tipo 1. La decodificaci´on es
como en el tipo 1, pero con la intercalaci´on invertida. Si se est´a operando en un ´ unico
vector para comenzar, los residuos de tipo 1 y tipo 2 son equivalentes. Un ejemplo
sencillo que ilustra r´apidamente este tipo de residuo se muestra en la Figura 5.8:
5.6.3. Decodificaci´on de los residuos
Decodificaci´on de la cabecera
La cabecera de los tres tipos de residuos es id´entica, y se procede de la siguiente
forma:
5.6. CONFIGURACION Y DECODIFICACION DE LOS RESIDUOS 125
Figura 5.8: Codificaci´on y decodificaci´on 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-porci´on espec´ıfica de cada
vector que est´a realmente codificado. Implementa algo parecido a un filtro paso ban-
da, orientado a la codificaci´on, 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 refieren 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 clasificaciones a los que una partici´on puede pertenecer, y
[residue classbook] es el n´ umero de codebook que se han usado para codificar las
claves de clasificaci´on. El n´ umero de dimensi´on del book [residue classbook] de-
termina cu´antos valores de clasificaci´on se agrupan en una ´ unica clave de clasificaci´on.
Despu´es leemos un patr´on de mapa de bits que especifica qu´e c´odigo de clases de
partici´on 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
´
ITULO 5. FORMATO OGG VORBIS
c) [bitflag] ← 1 bit como booleano
d) si ([bitflag] es activo ) ⇒ [high bits] ← uint5
e) [residue cascade]
[i]
← [high bits]∗8+[low bits]
2. fin
Para terminar, leemos en una lista de n´ umeros de book cada uno correspondiente a
un bit espec´ıfico activado en el bitmap. Iteramos los posibles codebook de clasificaci´on
y el n´ umero m´aximo posible de etapas de codificacion (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]
est´a activo ) ⇒
◦ [residue books]
[i][j]
← uint8
si no, ([residue cascade]
[i]
bit
[j]
no est´a activo ) ⇒
◦ [residue books]
[i][j]
← no usado
2. fin
Una condici´on fin-de-paquete en alg´ un punto de la cabecera hace la trama inde-
codificable. Adem´as, cualquier n´ umero en el codebook mayor que el m´aximo codebook
numerado configurado en esa trama tambi´en la convierte en indecodificable.
Decodificaci´on del paquete
La decodificaci´on de los paquetes de tipo de residuos 0 y 1 es id´entico excepto
para el intercalado espec´ıfico de la partici´on. El formato de tipo 2 se puede hacer fuera
del proceso de decodificaci´on del formato 1. As´ı, primero describiremos la estructura
de decodificaci´on com´ un a los tres formatos.
Adem´as de la informaci´on de la configuraci´on, el proceso de decodificaci´on 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 decodificar. Si el n´ umero de pasadas es 3 y el vector n´ umero 1 est´a marcado para
no decodificarse, el decodificador ignora el vector 1 en el bucle de decodificaci´on. De
todas formas, incluso los vectores que no se van a decodificar se reservan en memoria
y se inician a cero.
Estos valores son ´ utiles conceptualmente para clarificar el proceso de decodifica-
ci´on:
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 decodificaci´on sigue los pasos que especificaremos a continuaci´on,
seg´ un la descripci´on ofrecida anteriormente. Asumimos que el n´ umero de vectores
codificados, notado por [ch], se proporciona desde el nivel de decodificaci´on superior.
1. Reservar en memoria y poner a cero todos los vectores que se devolver´an
5.6. CONFIGURACION Y DECODIFICACION DE LOS RESIDUOS 127
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-decodificar ) ⇒
1) [vqclass] ←[classifications]
[j],([partition count]+[classword count])
2) [vqbook] ← [residue books]
[vqclass],[pass]
3) si ( [vqbook] ,= no-usado ) ⇒
• decodifica la partici´on 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. fin
Una condici´on de fin-de-paquete durante la decodificaci´on se considera un suceso
puntual. El decodificador devolver´a el vector resultante de la decodificaci´on hasta ese
momento.
Espec´ıfico para el formato 0
El formato de tipo 0 decodifica la particion exactamente como se describi´o en la
secci´on de dicho t´ıtulo. Un pseudoc´odigo posible para ese algoritmo podr´ıa ser el que
se escribir´a a continuaci´on. Asumiremos que:
[n] ← [residue partition size]
[v] ← vector de residuos
[offset] ← posici´on 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
´
ITULO 5. FORMATO OGG VORBIS
b) itera [j] en el intervalo 0 . . .[codebook dimensions]−1 ⇒
[v]
([offset]+[i]+[j]∗[step])
←[v]
([offset]+[i]+[j]∗[step])
+ [entry temp]
[j]
3. fin
Espec´ıfico para el formato 1
El formato de tipo 1 decodifica la particion exactamente como se describi´o en la
secci´on de dicho t´ıtulo. Asumiremos que:
[n] ← [residue partition size]
[v] ← vector de residuos
[offset] ← posici´on de inicio de lectura de [v]
Un pseudoc´odigo posible para ese algoritmo podr´ıa ser el que se escribir´a a con-
tinuaci´on:
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. fin
Espec´ıfico para el formato 2
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 decodificaci´on.
1. Asumimos que se van a decodificar ch vectores de n elementos
2. Decodificaremos usando el formato 1 un vector [v] de ch∗n
3. Desharemos la intercalaci´on del vector [v] en ch vectores independientes notados
por salida [k], siendo k un´ındice entre 0 . . .ch−1, seg´ un el algoritmo mostrado
a continuaci´on
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. fin
El formato 2 no maneja la bandera no-decodificar de forma diferente del tipo
0 ´o 1; si todos los vectores se marcan a no-decodificar, no se realiza decodificaci´on
alguna. Sin embargo, con que uno de ellos est´e marcado para ser decodificado, todos
los vectores ser´an decodificados.
5.7. FUNCIONES AUXILIARES DE LA IMPLEMENTACI
´
ON 129
5.7. Funciones auxiliares de la implementaci´on
5.7.1. Introducci´on
Cuando hemos explicado los distintos algoritmos que implementan el c´alculo de
elementos necesarios para la decodificaci´on de la onda, hemos hecho referencia a cier-
tas funciones que, si bien aparecen en los procesos de decodificaci´on, son totalmente
independientes de ´estos y no conllevan m´as que c´alculos generales. La intenci´on de
este texto es determinar qu´e hace cada una de las funciones referenciadas en distintas
partes del documento.
ilog (x)
´
Esta funci´on devuelve el bit activo m´as significativo del complemento a dos del
valor x. Los valores de x menores de cero devuelven cero por definici´on.
1. [return value] ←0
2. si ([x] ,= 0) ⇒
[return value]++
[x] ¸1
repetir paso 2
3. fin
float32 unpack (x)
Su finalidad es traducir la representaci´on binaria de un valor flotante empaquetado
que usa un codebook en la representaci´on de flotante que emplea el decodificador.
Aqu´ı se implementa para un float32 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 est´an permutados para construir la
tabla de b´ usqueda de tama˜ no codebook entries] de vectores VQ.
El valor que devuelve la funci´on se define como “el mayor valor entero para el cu´al
[return value]
[codebook dimensions]
≤ [codebook entries]”.
low neighbor (v, x)
Devuelve la posici´on n del mayor elemento de [v] para el que n < [x], y [v]
n
< [v]
[x]
130 CAP
´
ITULO 5. FORMATO OGG VORBIS
high neighbor (v, x)
Devuelve la posici´on n del menor elemento de [v] para el que n < [x], y [v]
n
> [v]
[x]
render point (x0, x1, y0, y1, X)
Esta funci´on calcula el valor Y en la ordenada X perteneciente a la l´ınea definida
con la pareja de puntos (x0,y0), (x1,y1). Esta funci´on usa un algoritmo entero para
solucionar el valor del punto de forma directa, sin calcular los valores sobre la l´ınea.
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. fin
render line (x0, y0, x1, y1, v)
La decodificaci´on de floor tipo 1 usa este algoritmo de dibujado de l´ıneas entero
para constru´ır una curva contigua a trozos. Es importante aqu´ı que la divisi´on 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. fin
132 CAP
´
ITULO 5. FORMATO OGG VORBIS
Cap´ıtulo 6
Ap´endices
6.1. Principios de la Inform´atica Gr´afica
Aqu´ı explicaremos las operaciones necesarias para realizar la transformaci´on de un
mundo 3D continuo a una imagen 2D que representa la proyecci´on de la escena dada
mediante una c´amara definida, as´ı como una breve descripci´on de las trasnformacio-
nes geom´etricas b´asicas. Si desea m´as informaci´on sobre representaci´on, iluminaci´on y
trasnformaciones, puede consultar documentaci´on especializada [22].
Comenzaremos viendo c´omo se transforma en el espacio 3D una geometr´ıa. Por
simplificaci´on, determinaremos toda la geometr´ıa como un punto en el espacio tridi-
mensional, ya que la transformaci´on de una geometr´ıa m´as 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 extensi´on de ´este. Describiremos las transformaciones geom´etricas
b´asicas que usaremos, y la forma de representarlo para su c´omputo.
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 simplificar la expresi´on, definiremos los siguientes vectores columna
P =
_
x
y
_
, P

=
_
x

y

_
, T =
_
d
x
d
y
_
(6.2)
Ahora podemos reescribir la expresi´on (6.1)
P

= P +T (6.3)
Como mencionamos en la introducci´on, todo se limita a trasladar los v´ertices que
conforman una figura. Supongamos que tenemos un segmento de recta que queremos
trasladar. Habr´ıa que trasladar todos los puntos que conforman la recta, pero como
133
134 CAP
´
ITULO 6. AP
´
ENDICES
podemos comprobar f´acilmente, basta trasladar los puntos que forman el segmento
para trasladar el segmento completo.
La rotaci´on sobre un ´angulo θ desde el origen se define matem´aticamente como
x

= xcos θ −ysen θ, y

= ysen θ +ycos θ (6.4)
En forma matricial, la expresi´on (6.4) se puede expresar como
_
x

y

_
=
_
cosθ −senθ
senθ cosθ
_

_
x
y
_
o bien P

= R P, (6.5)
donde R es la matriz de rotaci´on de la ecuaci´on (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 expresi´on para trasladar y rotar puntos en un espacio bidi-
mensional, pero nos encontramos ante la situaci´on de que no realizan las mismas
operaciones, como se puede apreciar. Tenemos que
P

= T +P, P

= R P (6.6)
Lo recomendable ser´ıa poder combinar de forma consistente las transformaciones
entre s´ı, para lo cu´al necesitamos tratarlas de forma semejante. Si expresamos los
puntos en coordenadas homog´eneas, ambas pueden tratarse como multiplicaciones.
En coordenadas homog´eneas, 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). Definimos 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 homog´eneas. La restricci´on 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 inv´alida.
Si W = 0, tenemos un punto en el infinito, 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 explicaci´on 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 intersecci´on de dicha recta con el plano definido por la ecuaci´on W = 1 en
el espacio (x, y, W).
Al estar formados por una tripleta de valores, la ecuaci´on de traslaci´on (6.1) se
reescribe en forma matricial como
_
_
x

y

1
_
_
=
_
_
1 0 d
x
0 1 d
y
0 0 1
_
_

_
_
x
y
1
_
_
(6.7)
Si consideramos la matriz de traslaci´on empleada como T, podemos reescribir la
expresi´on (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 rotaci´on (6.5) se escriben ahora como
_
_
x

y

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 ecuaci´on (6.9) lo definido en (6.10) tenemos
P

= R(θ) P (6.11)
Composici´on de transformaciones 2D
La finalidad de la composici´on es poder combinar las distintas transformaciones
de forma c´omoda y ´ util para poder obtener los resultados que se deseen. La idea
de componer las operaciones es la de simplificar c´alculos, ya que en lugar de aplicar
varias transformaciones consecutivas a un conjunto de puntos, basta aplicar una ´ unica
transformaci´on, la transformaci´on resultante, al conjunto de puntos.
Combinando la traslaci´on con la rotaci´on podemos salvar la limitaci´on que hemos
impuesto en la rotaci´on: 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 trasladaci´on que convierta a P
1
en el origen
2. Rotar los puntos deseados seg´ un los ´angulos deseados
3. Deshacer la traslaci´on realizada en el punto primero
Si definimos el punto P1(x
1
, y
1
) como punto sobre el que realizar la rotaci´on,
podemos definir 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 homog´eneas. De igual forma, las transformaciones en el
espacio tridimensional se representar´an por matrices 44, debido al uso de coordenadas
homogeneas para representar un punto de un espacio tridimensional, aportando una
coordenada m´as, igual que suced´ıa en el espacio bidimensional. Por tanto, en lugar de
representar un punto por una tripleta (x, y, z), usaremos una cu´adrupla (x, y, z, W) para
representar un punto en coordenadas homogeneas. Igual que suced´ıa 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 cu´adrupla
(0, 0, 0, 0) no es v´alida. La representaci´on 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 matem´aticos 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 traslaci´on en el espacio tridimensional es una simple extensi´on de todo lo
descrito en el espacio bidimensional. Por ello, es f´acil comprobar que la expresi´on que
rige la traslaci´on 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 rotaci´on definida en el espacio bidimensional corresponde a la rotaci´on sobre
6.1. PRINCIPIOS DE LA INFORM
´
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 expresi´on asociada a la rotaci´on 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 composici´on de traslaci´on y rotaci´on generar´a una matriz cuya matriz superior
izquierda de 33 proporciona la rotaci´on, y la ´ ultima columna proporciona la traslaci´on.
Por tanto, esta matriz ser´a 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 visualizaci´on
Normalmente, la proyecci´on se realiza desde puntos pertenecientes a un sistema
de coordenadas de dimensi´on n, a puntos de un sistema de coordenadas de dimensi´on
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 intersecci´on con un
plano arbitrario al que llamaremos plano de proyecci´on. La Figura 6.3 representa los
dos tipos de proyecci´on.
Figura 6.3: Tipos de proyecciones: paralela, conservando ´angulos y distancias, y pers-
pectiva, conservando solo ´angulos.
138 CAP
´
ITULO 6. AP
´
ENDICES
Proyecci´on paralela
La proyecci´on paralela m´as difundida es la llamada proyecci´on ortogr´afica, consis-
tente en proyectar cada punto con un proyector paralelo al eje i-´esimo en un plano de
visualizaci´on contenedor de los otros dos ejes. Por ejemplo, la proyecci´on ortogr´afica
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).
Proyecci´on de perspectiva
Todos los proyectores convergen en un punto llamado centro de proyecci´on (COP).
Para los c´alculos sucesivos, supondremos que el plano de proyecci´on es perpendicular
al eje Z, a una distancia d del centro de proyecci´on, tal y como muestra la Figura 6.4.
Figura 6.4: C´alculo de la proyecci´on en perspectiva P

del punto P.
Usando semejanza de tri´angulos podemos decir que
x

=
x
z/d
, y

=
y
z/d
(6.18)
Usando coordenadas homog´eneas podemos reescribir la expresi´on (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 t´erminos de (6.20) en (6.19) y simplificando, podemos escribir que
_
¸
¸
_
X
Y
Z
W
_
¸
¸
_
=
_
¸
¸
_
x
y
z
z/d
_
¸
¸
_
(6.21)
Si dividimos la expresi´on (6.22) por W para obtener las coordenadas cartesianas
equivalentes, obtenemos
6.1. PRINCIPIOS DE LA INFORM
´
ATICA GR
´
AFICA 139
_
¸
¸
_
x

y

z

1
_
¸
¸
_
=
_
¸
¸
_
x
z/d
y
z/d
d
1
_
¸
¸
_
(6.22)
Por tanto, en (6.22) obtenemos la relaci´on entre el punto proyectado P

y el punto
original P, cumpliendo la restricci´on que fijamos con respecto a z.
En la Figura 6.5 podemos ver el resultado pr´actico de esta transformaci´on de P
en P

, que dependa o no de P
z
, y c´omo la proyecci´on de dos objetos distintos con
distinto tipo de proyecci´on puede resultar id´entica.
Figura 6.5: Proyecci´on perspectiva y proyecci´on paralela, y objetos reales que producen
dicha proyecci´on.
140 CAP
´
ITULO 6. AP
´
ENDICES
CAP
´
ITULO 6. AP
´
ENDICES
Glosario
A
AC-3 El sistema de codificaci´on usado por Dolby Digital. Ambos t´ermino, AC-3
y Dolby Digital, se suelen usar indistintamente, p´ag. 58.
B
BIOS Acr´onimo de Basic Input/Output System, se refiere al software que se
ejecuta al inicio, que permite controlar pantalla, teclado, unidades de
disco, comunicaci´on serie y dem´as, sin acceder a ning´ un programa del
disco duro. Normalmente se encuentra en la ROM de la placa., p´ag. 51.
C
codec De ((coder/decoder)) (codificador/descodificador), tecnolog´ıa que permite
la compresi´on y decompresi´on de datos. Pueden implementarse tanto en
software como en hardware, o en una combinaci´on de ambos., p´ag. 54.
compilador cruzado Se usa este t´ermino para referirse a un compilador que genera
c´odigo objeto de una m´aquina distinta de la que ejecuta el compilador.
Sirve para generar el c´odigo objeto de una arquitectura desde otra distinta
en la que se encuentran todas las herramientas de desarrollo., p´ag. 5.
D
doublebuffer T´ermino referido al uso de dos buffers para la representaci´on 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
buffers, y se muestra el reci´en dibujado mientras se comienza a dibujar
en el anteriormente mostrado. Esta t´ecnica evita el parpadeo propio de
la escena dibujada, ya que evita que se aprecie el dibujado progresivo de
la misma., p´ag. 69.
DTS Acr´onimo de Digital Theatre Sound, se trata de un formato que hace que
las pistas de audio se aproximen m´as a la grabaci´on original que otras
pistas comprimidas. En conjunci´on con el beneficio multidismensional de
la tecnolog´ıa de sonido envolvente, la calidad del audio de las pistas
y m´ usicas en formato DTS mejoran dram´aticamente el contenido. M´as
informaci´on en su web: http://www.dtsonline.com/, p´ag. 58.
I
II GLOSARIO
F
FPGA Acr´onimo de Field Programable Gate Array, se trata de una malla de
puertas en la que la red l´ogica puede programarse en el dispositivo tras
su creaci´on. Est´a compuesta por puertas o tablas de consulta en RAM,
flip-flops y cableado de interconexi´on programable., p´ag. 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., p´ag. 6.
M
MIPS Acr´onimo de Microprocessor without Interlocked Pipeline Stages, es un
procesador RISC desarrollado por la MIPS Computer Systems Inc. (http:
//www.mips.com/), p´ag. 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 c´odigo de regi´on o el bloqueo por protecci´on anti-copia.,
p´ag. 6.
O
OpenGL OpenGL es el principal entorno de desarrollo gr´afico 2D y 3D portable.
No est´a sujeto a ning´ un sistema operativo y refleja el pensamiento y
talento de desarrolladores software de diferentes trasfondos gr´aficos. M´as
informaci´on en su web: http://www.opengl.org/, p´ag. 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., p´ag. 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.,
p´ag. 66.
RISC Acr´onimo 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 circuiter´ıa
necesaria., p´ag. 1.
S
SIMD Acr´onimo de Single-Instruction Stream Multiple-Data Stream, se refiere
a un tipo de arquitectura esencial en el mundo del c´alculo paralelo de los
ordenadores. La idea b´asica consiste en procesar un conjunto de datos de
forma simultanea, aprovechando que se ha de realizar la misma operaci´on.
GLOSARIO III
La habilidad de procesar vectores y matrices en tiempo m´ınimo ha creado
una demanda muy importante en ´areas como predicci´on metereol´ogica o
investigaci´on de las radiaciones de c´ancer. 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 multiplicaci´on
de los elementos se puede realizar de forma simult´anea. 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., p´ag. 93.
streaming T´ecnica para transferir datos de manera que pueden ser procesados con-
forme llegan, de forma cont´ınua. La tecnolog´ıa de ((streaming)) est´an
tomando relevancia debido al crecimiento de internet, ya que muchos
usuarios no tienen a´ un un acceso lo suficientemente r´apido como pa-
ra poder acceder a ficheros multimedia grandes de forma r´apida. Con
((streaming)), el cliente puede comenzar su reproducci´on antes de recibir
el fichero completo., p´ag. 56.
V
VLIW Acr´onimo de Very Long Instruction Word, describe una arquitectura de
procesamiento en la que el compilador o el preprocesador dividen la ins-
trucci´on de programa en operaciones b´asicas que pueden ser realizadas
por el procesador en paralelo., p´ag. 1.
X
x86 Se refiere a cualquier procesador de la familia Intel 80x86, o a cualquier
procesador compatible, como Cyrix o AMD., p´ag. 1.
IV GLOSARIO
Bibliograf´ıa
[1] 4Front Technologies. http://www.opensound.com/.
[2] Ars Technica. The PC Enthusiast’s 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] P´agina oficial de Sony para PlayStation. http://es.playstation.com.
[8] Proyecto ps2stuff. 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. Implementaci´on 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 Stancevic’s. 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. P´agina 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. P´agina oficial 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 User’s Manual. 2001.
[27] Sony Computer Entertainment Inc. EE Overview. 2001.
[28] Sony Computer Entertainment Inc. EE User’s Manual. 2001.
[29] Sony Computer Entertainment Inc. GS User’s Manual. 2001.
[30] Sony Computer Entertainment Inc. VU User’s 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 Rodr´ıguez Le´on. El est´andar MPEG. http://atc.ugr.es/~jesus.
[35] El liceo digital. Introducci´on 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 L´opez. 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 compresi´on de audio Ogg Vor-
bis. http://atc.ugr.es/~jesus/asignaturas/ae/descargas/trabajos/
2002-2003/vorbis.pdf.
[40] Napalm. P´agina oficila 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] Fr´ed´eric Patin. Beat Detection Algorithms. http://www.gamedev.net/
reference/articles/article1952.asp.
[43] Jes´ us Gonz´alez 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. P´agina oficial de XMMS. http://www.xmms.org/.
[47] 4Front Technologies. OSS Programmer’s guide v1.1. http://www.opensound.
com/pguide/oss.pdf.
[48] Kh. Brandenburg y B. Edler Th. Sporer. The use of multirate filter banks for
coding of high quality digital audio. http://www.iocon.com/resource/docs/
ps/eusipco_corrected.ps, 1992.
[49] Jeff Tranter. Linux Multimedia Guide. O’Reilly, http://www.oreilly.com/
catalog/multilinux/, 1996.
[50] Brennan Underwood. Brennan’s 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 Scientific Computing. http://www.library.
cornell.edu/nr/bookcpdf.html.
[53] Rafael Garc´ıa; Jes´ us Gonz´alez; 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 Gonz´alez 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/.

´ Indice general
1. Definici´n de objetivos y especificaciones o 1.1. Definici´n de objetivos y especificaciones . . . . . o 1.1.1. Objetivo . . . . . . . . . . . . . . . . . . 1.1.2. Proyecto a realizar . . . . . . . . . . . . . 1.1.3. Especificaci´n de la aplicaci´n . . . . . . o o 1.1.4. Estado actual y antecedentes . . . . . . . 1.1.5. Antecedentes bibliogr´ficos disponibles . . a 1.2. Introducci´n a la arquitectura de la PlayStation2 o 1.2.1. Introducci´n . . . . . . . . . . . . . . . . o 1.2.2. La consola de juegos PlayStation 2 . . . . 1.2.3. La arquitectura de la PlayStation 2 . . . . 1.2.4. El Emotion Engine (EE) . . . . . . . . . 1.3. La consola de videojuegos PlayStation2 . . . . . 1.3.1. Caracter´ ısticas . . . . . . . . . . . . . . . 1.3.2. Expansi´n y accesorios . . . . . . . . . . o 1.3.3. Comparativa . . . . . . . . . . . . . . . . 1.3.4. Qu´ le falta a la consola . . . . . . . . . e 1.3.5. Algunos comentarios sobre la PlayStation2 1.3.6. Curiosidades . . . . . . . . . . . . . . . . 1 1 1 2 3 3 5 6 6 6 8 13 17 19 20 22 22 25 26 29 29 29 30 30 40 40 41 43 45 47 49 49 49 50 52 54 54

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

2. Estudio del hardware: el Emotion Engine 2.1. Apendice. El EE a fondo . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.1.2. Mapa de memoria . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. El EE Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4. El Controlador de interrupciones (Interrupt Controller, INTC) . 2.1.5. TIMER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.6. El controlador de DMA (DMA Controller, DMAC) . . . . . . . 2.1.7. Interfaz del GS (GIF, GS Interface . . . . . . . . . . . . . . . . 2.1.8. Unidad de procesamiento de im´genes (IPU, Image Data Processor a 2.1.9. SIF, Sub-CPU Infertace . . . . . . . . . . . . . . . . . . . . . . 3. Desarrollo del proyecto 3.1. Desarrollo del proyecto . . . . . . . . . . . . 3.1.1. Especificaci´n de las tareas . . . . . . o 3.1.2. M´todo de programaci´n de la consola e o 3.1.3. Programaci´n de las unidades . . . . o 3.1.4. Distribuci´n en las unidades . . . . . o 3.2. Implementaci´n del proyecto . . . . . . . . . o i

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . .2. . . . . 3. .1. . . Configuraci´n del codec y decodificaci´n del paquete . . . . . . . . . . Configuraci´n del decodificador .3. . . . . Procesamiento de audio a Detecci´n de la cadencia de la canci´n . 5. . .2. . . . Decodificaci´n y s´ o ıntesis de paquetes de audio . . . . . . Floor 1: configuraci´n y decodificaci´n . . . . . . . . . . . . . o 4. . . . 3. . . . . . . . . a . . . . . 5. . . o o 5.5. . . . . . . . . . 6. . . . 5. . . .2. . . . . . . .5. o 5. . . . . . . . . . . . . .3. . o Reproducci´n de sonido . . . . .1. . . . . . . . . . . . . . . .1. .5. . . . . . . . . . Introducci´n . . . . . . . Decodificaci´n de la cabecera y configuraci´n del decodificador o o 5. . . . . . . o 5. Programaci´n in line de la VU0 como preprocesador . .1. . . . . . . . .2. . . . o 5. Pasos de la decodificaci´n . . .5. . . . . . . . . . . . . . . . .1.2. . .2. . . . . . .1. . o 5. . . . . . . . . .7. . .ii 3. ´ INDICE GENERAL . . Uso de la VU0 como ayuda del MIPS . . . . . . Decodificaci´n de sonido . . . .3.1. . . o 5. . . . .2. .2. . . . . . . . . . . . . . . . . . . . . o 6. . Funcionamiento general del decodificador . . . . .1. . . Procesamiento de los conjuntos de frecuencias . Formato Floor 1 . . Transformaciones en 3D . . . 4. . . . . Proyecciones de visualizaci´n o Glosario Bibliograf´ ıa . . . .3. . . o 5. .3. 4. 3. . . . . . . . . . . . . . . .4. .6.4. . . . Floor 0: configuraci´n y decodificaci´n . . . . .3.4. . . a 5. . Formato de residuos . . . . Introducci´n . . . . . . .3. . . . . . . . . . . . . Introducci´n . .1. Secciones de c´digo a optimizar . . . . . .1. . .2. . . . Funciones auxiliares de la implementaci´n . .4. . . . . . . . . o o 5. .2. . . . . . . .2. . Formato Floor 0 . o 5. . . . . 6. . 54 58 58 66 67 89 89 89 92 93 96 97 99 99 100 100 101 103 103 103 107 112 112 112 115 115 115 117 119 120 122 122 122 124 129 129 133 133 133 136 137 I V 4. . . . . . . . . . . . . 3. . . Introducci´n . . . . .6. . . . . . . . . .1. . . . . . 5. . . . . .7. .2. . . .5.3. . . . . . . o o Reimplementaci´n del plugin gr´fico .5.1. . . . . . . Decodificaci´n del paquete . . . . . . . . . . . . . . . Principios de la Inform´tica Gr´fica . . . . . . . . .5. . . . . . . . . . . . . . . . .1. . . . . . . .5. . 5. . . . Formato Ogg Vorbis 5. . . . .6. . . . . . . .2. . . . . . . . . o o 5. . . . . . . . . C´lculo de la curva . . Transformaciones en 2D . . . . . . . . . 5. . . . . . . . . . .1. . 5. . . . . . . 5. . . . . . . . . . . . . . o Modelo gr´fico. . . . . Optimizaci´n del programa sobre el hardware o 4. Introducci´n al formato . . Ap´ndices e 6. . . . . . . . .2. . . . . Procesamiento de frecuencias a conjuntos de frecuencias 4. . . . . . . . . . . . .1. . . o 5. . . . . . . . . Decodificacion de la cabecera . . . . . . .4. . . . . . . Configuracion y decodificacion de los residuos . . . . An´lisis de la ganancia obtenida . . . . . . . . . . . . . . . . . . . . . . . . .2.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . Introducci´n . . o 5. . . . . . . . .3. . .2. . . . . . . . . . o 5. Decodificaci´n de los residuos . . . . . o a . . . . a a 6. . .3. . . . . . . o 4. . . . . . . . . . . . .6. . . .2.2. . . . . . . . . . . .1. . . . . . . . . . . . . . .2. .

. .1. Registros existentes para especificar informaci´n asociada a un v´rtice. Antes de especificar la lista de informaci´n. . .4. 34 39 39 40 41 3. . . . . 23 a 2. .2. . .2. . 2. 2. . . . . . . . 83 o e iii . Rendimiento del GS para las distintas primitivas y opciones disponibles . . . . . 12 1. . . . . . .´ Indice de cuadros 1. . . . . . . o e Significado de las siglas de las etapas del cauce de la FPU. Interrupciones que es capaz de controlar el m´dulo INTC.5.2. . . . . . . . . . .1. . . . .1. . . . 82 a 3. . Significado de las siglas de las etapas de los cauces del EECore. 2. . . . se debe definir el tipo de o primitiva y las caracter´ ısticas que tendr´. . . . . . . . . Principales caracter´ ısticas de la consola comparada con las que ofrecen sus m´s directas competidoras en el mercado. .3. . . o Disponemos de diez canales DMA para realizar transferencias. . Organizaci´n de la memoria cach´. . . . . . . 2. . .

iv ´ INDICE DE CUADROS .

. .3. . . . Arquitectura interna del Emotion Engine de la PlayStation2 . . . . . . . . . . . . . . . . .16. . . . . . . . . . . . 2. . . . . . . . . como se puede comprobar. . 2. . . . . . . .1. . . .12. . .7. . . . . . . Arquitectura de las memorias de la PlayStation2 . . . . . . . . . . 1. Cada textura usa tan solo 4 bits de color. . . . . Registros que conforman la Unidad de Punto Flotante . . Esquema de memoria de la PlayStation2 .3. . . .12. . . . . . 2. Imagen de una PlayStation2 . .14. . . . . . . . . o 1. . . .5. . . . . . . . . . . . . . . 2. . . . . . .9. . 2. . . Ejemplo de transferencia de una regi´n rectangular de entre la memoria o principal y la SPR. . . . . . . . . . . v 2 3 4 5 10 11 14 16 17 18 20 24 25 27 29 30 31 31 33 34 35 36 38 38 39 42 43 45 46 46 47 . 1. . seg´n la unidad funcional de origen. Imagen de los componentes del kit de linux . . . . . . . . 1. . 2. . . . 1. . . . Posibles caminos hacia el GIF. Resultado de un modding por parte de un usuario de PlayStation2. . . . . PlayStation2 conectada al kit de desarrollo DTL-T10000. . .13. . . Etapas de los cauces del EECore. . . . . . . . . . a 2. o 2. . . . . . .10. . . . Diagrama de dependencia entre las principales tareas . . . . . . . . 2. . junto a las entradas/salidas o 1. . Arquitectura del sintetizador gr´fico . . . . . . . . . . . . Cauce de la Unidad de Punto Flotante . . . . Onda de audio digitalizada . . . . . . . 2. . . . . . . . . . . Estructura de la Unidad de Procesamiento de Im´genes . . . . . . . . . . . Estructura interna del EECore . . . . . . . .6. . . . . . . Planta de fabricaci´n de Sony en Nagasaki. . . . .9. . . . .2. . . . . . . . . . . . a 1. o o 2. . . 1. . .4. .11. . . . . . o e e (a) La conexi´n de la SPR con la CPU y con la memoria externa a o trav´s de DMA. .11. . .1. (b) la CPU y la memoria accediendo concurrentemente e al SPR para grabar y leer datos respectivamente.5. . . . . . 2. . a Estructura interna del Emotion Engine . . . . . . . . . . . Esquema de la disposici´n de las unidades. . Mapa de memoria del Emotion Engine . Organizaci´n de la cach´ de datos y la cach´ de instrucciones. . . .13. . . . Estructura del EE. . . . Plugin de visualizaci´n ((Iris)) para XMMS .7. . . . . . . .4. . . a nivel de unidades y buses entre las mismas . . . . . 1. . . . . . . . . . . . . 1. . 1. . . . . . . 2. .15. . . Con un n´mero reducido de colores se puede conseguir una textura de u gran calidad. . . . . . . Disposici´n de distintos tipos de transmisi´n a memoria. 2. . . . . . . .2. .6. . . . .17. . u 2. . . . . . .8. . . 1. . . . . . . . . Cauce de renderizado y asociaci´n a una unidad funcional de la consola o Reparto de las tareas m´s habituales entre el hardware de la consola. . . . . 2. . . . . . Estructura del SIF . . o 1. . . .10. . . . . . . . . . . . . . . .14. . . 2. . . . . . . . . . . .8. . . . Proceso de decodificaci´n de MPEG2 empleando el IPU.´ Indice de figuras 1.

. 3. . . . . . . . 116 . Orden de configuraci´n del dispositivo . . . De una onda (rojo) se puede estimar los golpes de ritmo (verde). . . . .2. . . . . . Flujo de datos del sintetizador gr´fico. . . . . . . .12. . .8. . . . . . . . . . . . Criterio a seguir para la distribuci´n inicial de las tareas . 3. . . Reconstrucci´n del floor con dos puntos. o 3. . Flujo de datos que sigue la implementaci´n del clasificador de frecueno cias en conjuntos de frecuencias: (a) en el MIPS. . . . . . . 97 o 5. . . (b) en un vector . . . . . . . . 3. . . necesitamos u definir unas ((bandas de frecuencia)).2. . . . . . . . . . . . . . . Desplazamiento realizado en la cola de v´rtices como consecuencia de e un vertex kick. . . 3. .5. . . . . . . 3. . . . . . . . . . . . . Uso normal de los procesadores que conforman el Emotion Engine . . Un ejemplo de la salida mostrada por top . . 49 51 53 54 55 57 57 59 59 60 62 64 66 68 71 72 77 78 80 83 4. . Componentes del decodificador de Ogg Vorbis . . . . . 48 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flujo de datos que sigue la implementaci´n del procesamiento de cono juntos de frecuencias: (a) en el MIPS. . . Flujo en una transferencia de datos entre el IOP y la memoria del Emotion Engine. . . . la transformada de Fourier (c) est´ definida entre ±fc . . . . . . .11. . .20. . . . n 3. . . . .18. . . (b) el flujo de datos perteneciente a la implementaci´n en la VU0. . La potencia fuera de ese rango se desplaza a a dicho rango. y c´lculo de la diferencia en o a Y con respecto a la estimaci´n inicial. . . . o 3. . . . . . . . . . . . . . . . . . . . . . . . 3. . pero tiene amplitud en todas sus frecuencias. . . .1. .6. . o 3. . . . . . (b) el flujo de datos perteneciente a la implementaci´n en la VU0. . . . . . Arquitectura de las VU dentro del Emotion Engine . . . . . . . . . . . . . .3. . . . . . . . .3. 5. . . . . . . . . . . . . .14. . .4. . . . La funci´n original (a) es distinta de cero en un intervalo T de tiemo po. . . . . . . . . . Cable PL2301 USB . . . . . . n 3. . . 3. . . . . . .7. . . . . . 3. . . 99 . . . . . . 95 o 4. . . .1. . . 102 . . . . . . . . . . . . .16. .2. . . . . . . . . .4. Se˜al en el dominio en tiempo y en el dominio en frecuencia . . .15. . . Si muestreamos con el intervalo ∆ como aparece en (a). . Tipo de solapamiento entre ventanas consecutivas.10. . Reordenaci´n de un vector (longitud 8 en este caso) por inversi´n de o o bits. . o 3. . . . . Arquitectura de las VU en profundidad . . . . 3. Descomposici´n en bloques del sintetizador gr´fico. . . Realizamos la correcci´n de la Y anterior y calculamos las nuevas para o 32 y 96. . . 116 .17. . . . . .19.9. . Ejemplo de espectograma (abajo) y se˜al de origen (arriba) . Proceso necesario para obtener el c´digo objeto desde el fichero ensamo blador. . a 3. . . . . Entrelazado de los canales . Esquema para la ejecuci´n de un programa en las unidades vectoriales . . . . . . . . . . o 5. . . . . . . . ya que calculamos la existencia o no de cadencia para cada uno de ellos. Aqu´ hemos representado todo el buffer de 1024 muestras como golı pe de ritmo. . . . . .1. . . . . . . . o a 3. . . . . . . . . . . y no para muestras concretas. . .13. . . . . . . . . 3. . . . .vi ´ INDICE DE FIGURAS 2. Tareas de las que se compone la decodificaci´n de Ogg Vorbis . . . . . . . . (a) entre dos vectores. considerando que cualquier frecuencia contenida en dichas bandas pertenece a un ((conjunto de frecuencia)) 3. .18. . . . . . . . . . . . . . 5. . . . . . . . . . Su transformada de Fourier (b) no tiene limitaci´n por ancho de o banda. . . . Para poder considerar un espectro de frecuencia suficientemente ´mplio a con un n´mero bastante reducido de barras a representar. . . . . .

. corrigiendo cuando es necesario. . 136 . . . . . . . . . . . . 138 . 117 . El espacio de coordenadas XY W . . . con el plano W = 1 y el punto P (X. . . Codificaci´n y decodificaci´n de un residuo de tipo 2. o o 6. . Empaquetamiento de los residuos. 6. . y objetos reales que proo o ducen dicha proyecci´n. . . . . . . . . . tenemos la reconstrucci´n o de la curva original. . a o 6. .5. . 139 . . . . . . . . . . y a perspectiva. . . . Proyecci´n perspectiva y proyecci´n paralela. . . . . . . . . 135 . . . . . . . . 125 . . .4. . . . . . . C´lculo de la proyecci´n en perspectiva P del punto P . . Y. a 6. . . . 5. . . . . . . . Cuando todos los valores se han calculado. . 5.5. . . W ) proyectado en ´l. . . . . . . . . . . Tipos de proyecciones: paralela. . . . 137 . . .3. . . . . . . . . .´ INDICE DE FIGURAS 5. .6.1. . . . .8. . . . . .2. . 123 . . Sistema de coordenadas de la mano derecha.7. . e 6. . . . . . . conservando solo ´ngulos. . . . . . . . 117 . conservando ´ngulos y distancias. . . . . . . . . . . . . . . . . . . . . . o vii . . 5. . . . . . . . . . Proseguimos refinando la curva con los valores asociados. . . . . .

viii ´ INDICE DE FIGURAS .

ya que las microarquitecturas como PIC. La carencia a radica en el resto de arquitecturas dif´ ıciles de conseguir. reflejando tambi´n dichas a e caracter´ ısticas en su repertorio. Estas tres unidades. Su procesador principal. adem´s de ser un procesador RISC puro. posee un par de unidades vectoriales VLIW. hay un conjunto de arquitecturas sobre las que no se realiza ninguna taera pr´ctica para hacer comprender que realmente existen en el a mercado actual.1. Tras haber recibido una formaci´n variada sobre la arquitectura x86 principalmente o como m´ximo exponente de los procesadores de prop´sito general. y no son meros dise˜os posibles en los que no se trabaja. 1. a que aporta un paradigma de programaci´n distinto al habitual cuando se programa un o procesador de prop´sito general. y la informaci´n que a o este efecto se puede obtener por los distintos medios. junto a un coprocesador matem´tio a 1 . el panorama actual en el que se encuentra el campo al que afecta este proyecto de forma directa o indirecta. o las FPGA s´ disponen de asignaturas en las que se recibe la pertinente ı instrucci´n pr´ctica en la que se ponen de manifiesto las ventajas y desventajas de o a dichas arquitecturas. ya sea programando al nivel m´s bajo o bien a un o a nivel superior de abstracci´n. se ha recibido un a o complemento pr´ctico acorde debido a la gran cantidad de procesadores basados en a dicha arquitectura que existen tanto en los hogares como en los centros de estudio. Definici´n de objetivos y especificaciones o Objetivo El principal objetivo de este proyecto es demostrar la validez de la arquitectura de la PlayStation2 como plataforma did´ctica sobre la que desarrollar los conocimientos a recibidos sobre distintas arquitecturas. Esto implica poseer un repertorio distinto de instrucciones.1. un procesador de prop´sito general. 1. como se representa en la Figura 1. as´ como ı las opciones que se barajan inicialmente. La PlayStation est´ compuesta de varias a unidades.1. pues se trata de la arquitectura m´s difundida y usada entre los usuarios. Adem´s. no forma parte de la familia de o los x86. Sin embargo.1. con distintas arquitecturas. n Es un hecho comprobado que un ejercicio pr´ctico sobre los contenidos te´ria o cos ayudan a reafirmar y aclarar conceptos. pues es un derivado del MIPS III.Cap´ ıtulo 1 Definici´n de objetivos y o especificaciones En este cap´ ıtulo comentaremos lo que se pretende con este proyecto.

optamos por intentar aprovechar la mayor cantidad posible para distribuir la carga de una aplicaci´n en tiempo real.1.1: Arquitectura interna del Emotion Engine de la PlayStation2 co de apoyo al procesador MIPS. interesante y a suficientemente motivante para tener una val´ did´ctica frente a otras posibles ıa a aplicaciones que llamen menos la atenci´n del alumnado. a˜adiendo o n la ejecuci´n de todas de forma sincronizada y en paralelo. con lo que deber´ o ıamos usar tanto el procesador principal de prop´sito general como las unidades VLIW.2 ´ CAP´ ITULO 1. se debe generar una salida auditiva: hace uso del dispositivo de sonido. tambi´n en tiempo real y de forma sincronizada con la salida de audio. por una serie de razones que expono dremos a continuaci´n: o la descompresi´n de sonido es algo muy habitual hoy en d´ consideramos que es o ıa: un tema de bastante relevancia en el sentido de ser algo pr´ctico. Proyecto a realizar Disponiendo de una variedad de unidades de procesamiento interconectadas para realizar tareas en paralelo. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES Figura 1.2. o e . siendo f´cil su detecci´n durante las pruebas. liberando de dicha tarea al resto de componentes y logrando un procesamiento a paralelo mayor. hace uso de la unidad gr´fica: no solo necesita el procesamiento de c´lculo y a a la reproducci´n del sonido. forman el centro de procesamiento de c´lculo de la a m´quina. o La apliaci´n elegida fue un reproductor con una visualizaci´n sincronizada del o o formato Ogg Vorbis [23] de compresi´n de audio. aumentando la visi´n pr´ctica del proyecto al aportar una caracter´ o a ıstica esencial del mundo multimedia. sino que se necesita profundizar m´ o ınimamente en el funcionamiento de la unidad gr´fica para poder mostrar la evoluci´n de la a o canci´n. ya que un retraso de menos de un segundo provoca una interrupci´n en el sonido. 1. o posee unos requisitos de tiempo real bastante importantes: es una aplicaci´n o de tiempo real cr´ ıtico. a Aparte posee un MIPS I como procesador de gesti´n de entrada/salida y un proo cesador gr´fico totalmente independiente dedicado exclusivamente a la representaci´n a o gr´fica. y una o a o prioridad ante todo.

hay que enviarlo o a la salida de audio a la correspondiente frecuencia. Es la base n o de muchas de las aplicaciones de sonido que existen hoy d´ ya que sin los m´todos ıa. 1.1. En este e apartado trabajaremos desde el punto de vista global de la aplicaci´n. visualizaci´n del sonido decodificado: con el sonido a reproducir se debe calcuo lar una serie de propiedades de ese fragmento que sean representables de forma gr´fica. Aunque este proyecto no trata de la compresi´n o o de una se˜al de audio. transformando las tramas de o ogg vorbis en formato de codificaci´n por pulsos interpretables por el sistema de o audio. reproducci´n del sonido decodificado: una vez decodificado. se trata de realizar una aplicaci´n que sincroniza la reproo ducci´n de audio con la visualizaci´n de dicho audio.´ 1. podemos distinguir o o tres tareas b´sicas: a decodificaci´n del fichero ogg vorbis en muestras de audio: realiza todo el o proceso de decodificaci´n del fichero comprimido. canales y tipo de dato.1. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES 3 uso del formato ogg vorbis frente a otros formatos de compresi´n: nos centramos o en el soporte de un formato de compresi´n libre y sin patentes al contrario que o el resto de formatos de compresi´n con p´rdidas de audio. sin profundizar o en los distintos aspectos que la componen. es un hecho de vital relevancia y diaria investigaci´n. Especificaci´n de la aplicaci´n o o Como hemos esbozado. a Es inmediato ver la dependencia de las tareas que tenemos a nuestra disposici´n. ser´ inmanejable la cantidad de informaci´n que tendr´ que o ıa o ıa .1. como es el caso del popular MP3. Cada tarea se descompondr´ en subtareas m´s detalladas como se mostrar´ posa a a teriormente en secciones siguientes y en ap´ndices a final del documento. e de codificaci´n de audio. para crear una imagen que se corresponda con dicho fragmento.2. obtenemos el ´rbol de la Figura a a 1. que est´n sujetos a o e a patentes. En el uso habitual de cualquier ordenador dom´stico entra o e como tarea la reproducci´n de audio.4. Figura 1.2: Diagrama de dependencia entre las principales tareas 1. Estado actual y antecedentes Ya expusimos la actualidad de este tipo de aplicaciones como uno de los motivos que nos llevaron a su elecci´n. o Si representamos de forma gr´fica dicha dependencia.3. Por tanto.

en favor de una descodificaci´n muy r´pida. tanto a nivel de documentaci´n como a nivel de implementaciones disponibles para o distintas plataformas. y un esbozo de las razones que nos han llevado a elegirlo. Hay otro tipo de algoritmos de compresi´n. Para ello. ogg vorbis. que es el l´ ımite psicoac´stico del o´ humano. donde se necesita estar codificando y a descodificando de forma constante lo m´s r´pido posible. concretamente el plugin ((Iris)). debido a la distinta complejidad que supone su codificaci´n y e o su descodificaci´n. 38 Mbytes. Se trata por tanto de un m´todo de los o e denominados asim´tricos. para un segundo.4 ´ CAP´ ITULO 1.3: Onda de audio digitalizada Tenemos entonces que. y la ingente cantidad de espacio necesario para poder almacenarlo. lo que implica que para la canci´n de 4 a o minutos. necesitar´ ıamos aproximadamente 121. Con un Dolby Digital. Hemos expuesto ya el codificador que usaremos. apta para o o a una aplicaci´n de tiempo real. Una canci´n o normal de 4 minutos. e necesitar´ ıamos tres veces m´s de espacio.4 se muestra uno de estos plugins gr´ficos. ocupar´ 176 400 ∗ 60 ∗ 4 40. Eso hacen 44 100 ∗ 2 ∗ 2 a 176 400 bytes por segundo. o Sin embargo. llamados sim´tricos. debemos almacenar 44 100 muestras de 16 bits (2 bytes) por canal. la parte relativa a la programaci´n en el hardware de la PlayStation2 o .3 muestra una onda digitalizada a dichos par´metros. e a Figura 1. La Figura 1. Windows Media Player o XMMS [46] entre muchos otros. que no es m´s e a que 44 100 muestras por segundo.free. en o o e los que el tiempo de codificaci´n y descodificaci´n son similares. Sonique. libre de patentes y con un gran soporte por parte de sus creadores. que tiene seis canales de sonido. a disponible en la direcci´n http://cdelfosse. Supongamos que queremos oir una canci´n a una calidad l´ o ımite de la audici´n o humana. o de lo que pretendemos hacer. La finalidad de los algoritmos sim´trie e cos est´ orientada a conferencias en tiempo real. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES circular por los distintos buses del sistema. como es el caso. como bien pueden ser Winamp. con u ıdo muestras de 16 bits y en dos canales (el est´reo b´sico). algo indiso o pensable hoy d´ Relacionado con nuestra aplicaci´n. a a Con nuestra elecci´n intentamos dar soporte a un formato de codificaci´n asim´trio o e ca de alta calidad. encontramos diversas muestras ıa. La otra parte de la aplicaci´n conforma una demostraci´n multimedia. Recordemos que esto era u e o para una muestra en est´reo. En la figura 1. Es evidente que es ıa necesario encontrar alg´n m´todo de compresi´n de sonido. Este formato. principalmente como plugins de visualizaci´n de los prino cipales reproductores multimedia. aunque no alcanzan o o las caracter´ ısticas de calidad de los asim´tricos.fr/xmms-iris/. comparte gran parte de las caracter´ ısticas de cualquier codificador alternativo de semejante prop´sito: posee una o codificaci´n costosa en tiempo. necesitamos que est´ en un formato ((calidad CD)). optaremos por el programa XMMS como modelo a seguir por temas de soporte hacia el programador. 12 Mbytes. En este caso.

tanto a nivel de herramientas de desarrollo como de informaci´n. a Un tercer m´todo descartado desde el inicio es el que recibe un soporte completo e de Sony.4: Plugin de visualizaci´n ((Iris)) para XMMS o est´ pr´cticamente indocumentada y sin soporte de ning´n tipo. Sony ha hecho una especie de campa˜a en cierta forma a a n elitista en lo que a su programaci´n se refiere. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES 5 Figura 1. En cierta forma o . El principal o e o m´todo de aprendizaje es el ensayo y error. volvemos a a tener una notable carencia de informaci´n sobre qu´ o c´mo se hace algo. su enfoque principalmente o n orientado a ser un producto final de ocio y consumo destinado al entretenimiento interactivo de los usuarios hace que la documentaci´n otorgada de forma p´blica sea o u m´s bien inexistente. El principal inconveniente de este a sistema es la necesidad de estar reconocido como un desarrollador oficial por Sony. Es m´s. sin comprar ning´n producto externo a la consola propiamente dicha.1. Aunque tenemos a un conjunto de bibliotecas para compilar de forma cruzada a la m´quina. cosa no muy recomendable para nuestro e objetivo ultimo. pues dispone de un kit [14] de desarrollo bajo el sistema operativo GNU/Linux para la consola. y son poco m´s que meros productos finales. a De hecho. a Si disponemos de fondos suficientes.1. ıcil a o 1. No otorga soporte de ning´n tipo o u a la programaci´n de la consola si no hay un contrato por medio. que es mostrarle al alumno la programaci´n de una arquitectura ´ o distinta de forma did´ctica. El principal problema n a que se encuentra es el que las propias palabras de uno de sus m´ximos exponentes a de estas bibliotecas: ((es m´s divertido programar que documentar)). con manuales sobre las principales unidades funcionales inclu´ ıdos. Aunque hay a a u aplicaciones desarrolladas para la m´quina a tratar.5. cosa dif´ de conseguir. incluyendo o una m´quina PlayStation2 especial para desarrollo. ninguna est´ destinada al aprendia a zaje de la programaci´n. podemos adquirir cierto soporte de Sony a la hora de desarrollar los programas. Esto supone una ventaja y una desventaja con respecto al m´todo anterior: tenemos m´s soporte e informaci´n para la programaci´n. y m´s para nuestro prop´sito. u la unica forma de programarla es mediante el empleo de un compilador cruzado y unas ´ bibliotecas m´ ınimas creadas por un grupo de gente sin soporte de Sony de ning´n tipo u cuyo pasatiempo es desenmara˜ar los secretos de la m´quina. si bien ale a o o gunas unidades quedan ocultas por el sistema operativo y las aplicaciones desarrolladas solo funcionar´n en una PlayStation2 que tenga el kit de Linux instalado. creaciones de o a 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 m´quina. Antecedentes bibliogr´ficos disponibles a A pesar de su aparici´n en el mercado hace varios a˜os.´ 1.

El a programador ((free-lance)) o el usuario curioso con el suficiente conocimiento como para querer probar a hacer cosas en la m´quina por mero placer no son el perfil de a programador que le interesa. Dentro del soporte que Sony proporciona a los usuarios que no est´n registrados a como un desarrollador ((serio)) de productos para la PlayStation2. Tambi´n encontramos una breve e introducci´n [36] por Rob Louie al uso del kit de linux en la WEB de GameDev [5]. solo se encuentran disponibles un par de ejemplos con el c´digo fuente ligeramente comentado como principal o fuente de informaci´n. sin compa˜´ que nıas respalden un producto de calidad. o donde se muestra un programa m´ ınimo para proporcionar un cambio de modo gr´fico y a un dibujado de una malla en la pantalla. demos y algunas heı n o rramientas y proyectos que pueden facilitar el inicio de la gente a la programaci´n de o la consola sin soporte de Sony. Como un esfuerzo de desarrollo sobre la m´quina. a o as´ como una peque˜a serie de tutoriales. b´sicamente los repertorios de instrucciones de las a unidades y algunas consideraciones de uso. ni publicistas que puedan distribuirlos por el mercado. Introducci´n a la arquitectura de la PlayStation2 o Introducci´n o Esta seccci´n pretende ser una introducci´n did´ctica a la arquitectura de la cono o a sola PlayStation 2. Se tratar´ la arquitectura de forma general para no perder el fin a did´ctico y no aburrir al lector y se profundizar´ en cada secci´n que lo requiera mea a o diante los ap´ndices.2.2. solo encontramos el ya mencionado kit de Linux. 1. publicado en n el portal de Sony para el Linux de la PlayStation. confeccionado como ayuda para la participaci´n en el VU o Demo Coding Contest [15]. e 1.6 ´ CAP´ ITULO 1. constru´ desde cero sin soa ıdo porte de ning´n tipo por Sony. c´digos de ejemplo. encontramos un tutorial bastante interesante denominado Harnesses [45]. 1. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES es comprensible. aunque sea usando unicamente el procesador ´ principal.2. o Para ´ste m´todo.2. Dentro del sistema. Respecto a la unidad vectorial. una competici´n que realiza Sony cuyo objetivo princio pal es confeccionar una demo lo m´s impresionante gr´ficamente usando unicamente a a ´ la VU1. ya que la clase de programadores que quiere Sony para su consola son parte de estudios de desarrolladores de videojuegos con suficiente calidad como para poder crear un producto de deleite que atraiga m´s usuarios a su consola. El principal inconveniente es la necesidad de tener un ((mod-chip)) en la consola para poder arrancar los programas.1. u Han desarrollado una serie de bibliotecas b´sicas para la programaci´n de la consola. Sony proporciona una serie de manuales en el soporte digital. s´ podemos encontrar ciertas referencias introductorias por la e e ı red. La consola de juegos PlayStation 2 Aunque en esta secci´n nos centraremos en la arquitectura de la PlayStation 2 o y en especial en el microprocesador que hace las veces de coraz´n de la misma no o conviene olvidar que ´sta es una plataforma de ocio e interesa ralizar una introducci´n e o a sus caracter´ ısticas para que el lector nunca pierda la perspectiva. En el ap´dice ((La consola de juegos PlayStation 2)) se puede o e . Un ejemplo es el peque˜o tutorial [21] escrito por Sarah Ewen. parte de los ejemplos de la biblioteca ps2dev [13]. Haremos aqu´ una ı muy breve descripci´n. podemos encontrar el gran proyecto de PS2DEV [19].

permite a PlayStation 2 mover a una cantidad impresionante de pol´ ıgonos en la pantalla del televisor (que en conjunto forman los gr´ficos en pantalla).4 Gp´ ıxeles/s Con un significado tan simple como ’Entrada/Salida’. Este chip. con la ayuda o de la memoria principal y el sintetizador de gr´ficos.4 Gbytes/seg. claramente est´ orientada a juegos 3D. Estas son sus caracter´ a ısticas principales: Chip Emotion Engine multimedia personalizado de 128 bits para CPU Frecuencia de reloj del Sistema: 294 912MHz Memoria Cach´: Instrucciones 16KB. Con el a exclusivo chip del sintetizador de gr´ficos que incorpora. sino que ofrece unas reconociadas o a capacidades multimedia. la consola PlayStation 2 es realmente potente en el interior de su esbelta cubierta. los sistemas E/S de PlayStation 2 aseguran un funcionamiento sin problemas de la consola.5MHz Memoria IOP: 2MB Sub Bus: 32-bit Respecto al sonido la PlayStation 2 presenta una procesador de sonido de hasta 48 canales. se muestran ´ a continuaci´n: o El coraz´n de la PlayStation 2 es el chip Emotion Engine. lo que la convierte en un centro integral de entretenimiento dom´stico. o La PlayStation 2 sali´ al mercado en el a˜o 20011 al despu´s de la gran espectaci´n o n e o causada en el mercado internacional. INTRODUCCION A LA ARQUITECTURA DE LA PLAYSTATION2 7 encontrar informaci´n completa y descriptiva acerca de la consola. sus gr´ficos cobran vida. e Debajo de la elegante cubierta exterior oscura2 de la consola PlayStation 2 hay una completa central electr´nica. Es uno de los equipos de juegos m´s potentes jam´s o a a creados. do que asegura una compatibilidad al 100 N´cleo de la CPU: CPU de PlayStation mejorada u Frecuencia de reloj: 37. en realidad se llevaba comercializando en Jap´n desde su o presentaci´n el 4 de Mayo del 2000 o 2 Aunque este mismo a˜o est´n saliendo al mercado versiones de distintos colores n a . Los detalles pormenorizados de la consola PlayStation 2. Datos 8KB + 16KB (ScrP) e Memoria Principal: 32MB Ancho de banda del Bus de memoria: 128 bits DMA Coprocesador: 2 Unidades paralelas de operaciones vectoriales Actuaci´n del Punto Fluctuante: 6. Pero esta plataforma tambi´n permite al usuario reproducir video DVD y e reproducir CDs de audio. Adem´s el procesador a de entrada/salida de la PlayStation 2 es la CPU de la PlayStation mejorada. Es una plataforma de ocio m´s que una consola. los CDs que oigas o los DVDs que veas sean una experiencia unica.´ 1.2. N´mero de Voces: 48 canales con sonido surround 3D u Memoria de la selecci´n de sonido: 2MB o Frecuencia de Salida: Hasta 48 KHz (calidad DAT) 1 Esto fue al mercado internacional. a a Sintetizador gr´fico a Frecuencia de reloj del Sistema: 147MHz Memoria interna 4MB DRAM Velocidad del frame buffer: 38. a pues no s´lo est´ orientada a poder jugar con ella.2 GFLOPS o Transformaci´n Geom´trica 3D CG: 66 millones de pol´ o e ıgonos por segundo Descodificador de compresi´n de imagen: MPEG2 o El rendimiento del procesador gr´fico de la PlayStation 2 es excelente. En lo que respecta a los juegos. Velocidad de dibujado: 2. para que todos los juegos.

8

´ CAP´ ITULO 1. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES

En lo que respecta a la capacidad de almacenamiento, la PlayStation 2 incorpora un DVD con estas caracter´ ısticas: Tama˜o m´ximo: Doble capa 9GB n a Velocidad del Dispositivo DVD-ROM: velocidad aproximada de 4X. CD-ROM: velocidad aproximada de 24X. La PlayStation 2 tambi´n incorpora varias interfaces que la dotan de gran versae 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 p´gina oficial de Sony [7] podemos encontrar adem´s de ´stas caracter´ a a e ısticas un completo cat´logo de complementos de la consola a

1.2.3.

La arquitectura de la PlayStation 2

La PlayStation 2 est´ dise˜ada para conseguir unas altas prestaciones, sobre todo a n en lo referente a juegos 3D. Es esta car´cter´ a ıstica la que va a condicionar toda la arquitectura. Las caracter´ ısticas del cauce general de renderizaci´n 3D son las que o 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 cach´ m´s o menos pequea˜, el EE se compone de vaios procesadores con peque˜as e a n n cach´ e interconectados por r´pidos buses. e a Por su diferente arquitectura, la filosof´ de programaci´n de una m´quita y otra ıa o a deben ser radicalmetne distintas. Haciendo una a analog´ programar un PC ser´ tener ıa, ıa ((unos grandes cubos de agua conectados con unos tubitos peque˜os)) y programar la n PS2 ser´ tener ((unos cuencos conectados por amplios canales)). ıa El dise˜o de la arquitectura de la PS2 se rige por unos puntos principales (que n podemos llamar restricciones) que estableci´ el equipo de desarrollo de Sony y que o debemos tener en cuenta a la hora de comprender correctamente la arquitecura [27]. Est´ orinetada al entretenimiento dom´stico. Esto siginifica que las especificacioa e nes de la m´quina no pueden cambiar a lo largo de su vida y si cambian tiene que a ser de una forma tranparente al desarollador y al usuario. A efectos pr´cticas esto a nos asegura que cualquier aplicaci´n que hagamos basada en el Emotion Engine o va a funcionar all´ donde haya un EE. Esto nos ofrece un ´ngulo de visi´n muy a a o interesante desde el putno de vista comercial y de la investigaci´n. o Potencia para sintetizar emociones. Los gr´ficos 3D de alta calidad requieren ua a gran potencia de c´lculo. Adem´s, los juegos de calidad no solamente tienen unos a a buenos gr´ficos, sino que tambi´n manejan una pesada l´gica y una simulaci´n a e o o de fen´menos f´ o ısicos considerable en aras de conseguir realismo. La consola tiene que dise˜arse para soortar estos c´lculos. n a R´pido renderizado. Para conseguir un buen frame rate en juegos 3D se necesita, a entre otras cosas, poder realizar un renderizado r´pido. La PS2 usa un sintetizador a gr´fico (GS) con DRAM embebida lo que consigue que el ancho de bandea entre a 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 p´ ıxeles en la

´ 1.2. INTRODUCCION A LA ARQUITECTURA DE LA PLAYSTATION2 renderizaci´n3 o

9

Simultaneidad de c´lculos geom´tricos. La consola proveer´ al desarrollador de a e a la posibilidad de simultanear c´lculos geom´tricos. a e Descompresi´n de datos bajo demanda. Una buena soluci´n para abaratar el o o 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 resoluci´n. o Control de stall y memoria FIFO. Una enorme cantidad de datos intermedos (display lists) se transfieren constantemente desde el motor geom´trico hasta e el motor de renderizado. Para controlar este flujo 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 geom´trico hasta e la memooria y desde la memoria hasta el motor de renderizado usando la memoria como un buffer. Procesadores espec´ ıficos. Los video juegos usan cadena de procesamiento comunes comom el procesamiento de im´genes. Adem´s, de la carga de los procesos a a por s´ misma, el overehead debido a los cambios de contexto producen una pesada ı carga para la CPU. Por esta raz´n se usar´n subprocesadores a peque˜a escala o a n para ejecutar esas cadenas de procesamiento comunes para compartir tiempo de procesamiento de la CPU. Transferencia inteligente de datos. El procesamiento distribu´ incrementando ıdo el n´mero de subprocesadores requiere mecanismos de sincronizaci´n y arbitraje. u o Para no sobrecargar la CPU con estas, tareas todas las intrucciones (programas) se transfieren junto con los datos usando un controlador de DMA4 . Buffer de camino de datos. En un sistema UMA (Unified Memory Arquitecture)5 con varios subprocesadores las competiciones por accesos al bus crean cuellos de botella. Por ello se a˜aden a cada subprocesador unos buffers de peque˜a n n capacidad (cach´s) donde se almacenan temporalmetne los resultados del proe 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 DMAC6 y la eficiencia de las transmisiones se puede mejorar. Si se quiere sintetizar emociones es necesario realizar una cantidad enorme de ´ c´lculos. Estas altas prestaciones se cosiguen con un esmerado dise˜o que busca la a n m´xima paralelizaci´n de componentes. Principalmente, la arquitectura de la PlayStaa o 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 4 m´s a

era el principal problema del renderizado en el a˜o 2000 n adelante veremos que ´ste es la piedra angular para sacarle partido al EE e 5 arquitectura de memoria unificada 6 Direct Memoy Access Controler

10

´ CAP´ ITULO 1. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES

Figura 1.5: Esquema de la disposici´n de las unidades, junto a las entradas/salidas o Emotion Engine (EE) Este es el verdadero coraz´n de la consola. Se trata de un procesador con varios o 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 secci´n. o 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´n m´s atractiva al usuario final u a poseedor de una PS la PS2; ya que el usuario podr´ seguir usando los t´ a ıtuos que pose´ y puede comprar nuevos t´ ıa ıtulos a bajo precio debido al salto de tecnolog´ ıa. Sony no se qued´ ah´ y mejor´ el procesador. El IOP contiene un procesador MIPS o ı o 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 perif´ricos y puertos de la e 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 conexi´n de la ı o consola a m´ltiples perif´ricos presentes y futuros tales como teclados, ratones, c´maras u e a digitales, impresoras, joysticks, etc. Con respecto al procesador original de la PS esta versi´n mejorada incorpora el IEEE 1394, una cach´ mejorada y una nueva arquitectura o e 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 ejecuci´n, PS o PS2, el IOP funciona a 33 o 36 MHz respectivamente, o
7 La llamaremos PS y no como err´neamente se hace en otros art´ o ıculos PSOne pues PSOne es una versi´n de la PS original con un nuevo aspecto externo y una nueva organizaci´n del PCB que dificulta o o la instalaci´n de chips. La consola sigue siendo la misma o

GS) a El GS es el procesador gr´fico de la PS2 y se encarga de dibujar el mundo 3D por a pantala. a El Sintetizador Gr´fico (Graphics Synthesizer.2.6: Arquitectura del sintetizador gr´fico a Los motores de p´ ıxeles 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 trav´s e de un bus de sistema. Para ello traduce las display lists (listas de datos) que le env´ el EE. Figura 1. En la Figura 1. ıa Es un procesador gr´fico de muy alto rendimiento que consigue su potencialidad a rgacias a unso buses muy anchos con los que se consigue un gran ancho de banda. a 16 motores de p´ ıxeles que operan en paralelo y a una DRAM de 4 MB embebida en el chip. INTRODUCCION A LA ARQUITECTURA DE LA PLAYSTATION2 11 como se analiza en el art´ ıculo publicado sobre la posible aplicaci´n de la consola a fines o did´cticos [53].6 mostramos un esquema general de la arquitectura del GS. el GS tiene la memoria embebida conectada directamente a los motores de p´ ıxeles con un bus de 2560 bits con lo que se consiguen unas transferencas .´ 1.

2 Gp´ ıxeles/s con texturas. La tasa de escritura de p´ ıxeles m´xima es de 2. e o Este m´dulo puede generar la salida seg´n el est´ndar VESA (hasta 135 MHz como o u a .1: Rendimiento del GS para las distintas primitivas y opciones disponibles El GS contiene tambi´n un m´dulo encargado de su salida que es el PCRTC.12 ´ CAP´ ITULO 1. a a El GS procesa 16 p´ ıxeles (32 bit por p´ ıxel) por ciclo sin texturas y 8 p´ ıxeles por ciclo con texturas. Como vemos en la figura hay una configuraci´n o de doble puerto para acceder simult´neamente a las dos zonas de memoria.6 GB/s (512 bits x 150MHz).1 muestra una tabla donde podemos ver cuantos pol´ ıgonos es capaz de procesar el GS en distintas condiciones de funcionamiento. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES de 48 GB/s lo que ayuda a mejorar las tareas de renderizado y da mejor rendimiento que un sistema de video tradicional. La Tabla 1.4 Gp´ a ıxeles/s sin texturas y de 1. a por ahora. si procede. M´s a delante.4 GB/s (1024 bits x 150 MHz x 2) y cuando se transmite al texture buffer se alcanza una velocidad de 9. Cuadro 1. en m´s detalles y despu´s de haber destacado los elementos distintivos de a e la arquitectura del GS vamos a comentar a t´ ıtulo descriptivo las capacidades del GS. Cuando se transmite al frame buffer se consigue un ancho de banda de 38. trataremos el GS en m´s profundidad. Sin entrar.

´ 1. Son tres los componentes que pueden realizar operaciones en punto flotante en paralelo: 1. Cuando se aplica al procesamiento de transformaciones de perspectiva y geom´tricas. a 1. De todas formas Sony proporciona una o WEB [6] donde podemos encontrar un listado actualizado de monitores probados. ya que Sony considera que no tiene mucho sentido ver o texturas de alta definici´n televisor con las limitaciones que ´ste tiene. dos unidades independientes de calculo de vectores en punto flotante (VU0. a Por ultimo a˜adir que no todos los monitores pueden conectarse con la PS2.4. La capacidad de c´lculo en punto flotante a es muy superior a la de los ordenadores personales corrientes. la PS2 no est´ hecha para conectarse a un o n a monitor de alta definici´n. En su dise˜o.912 MHz. El Emotion Engine (EE) Introducci´n o El Emotion Engine es el coraz´n de la Playstation2. e que son las que se usan normalmente para el c´lculo de gr´ficos en 3D. Coprocesador 2 VU0 con 4 FMAC y 1 FDIV 3. y todo tipo de transformaciones geom´tricas 3D. Para el proceso masivo de informaci´n multimedia a altas velocidades. Est´ basado en la arquitectura MIPS III a aunque implementa un subconjunto de instrucciones de la arquitectura MIPS-IV. NTSC o PAL. el rendimiento a a 8 En el desarrollo de CELL.2 a a GFLOPS/seg. Con una capacidad de c´lculo en punto flotante de 6. el procesador para la PlayStation3 participa tambi´n IBM e . una unidad SIMD de 128 bits con 107 instrucciones para el procesamiento multimedia.2 GB/seg. como la memoria o cach´ y los registros son de 128-bits. 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. un circuito decodificador de MPEG-2 y controladores DMA de alto rendimiento. tanto el bus de datos. Coprocesador 1 FPU con 1 FMAC1 y 1 FDIV 2. es posible procesar y transferir vol´menes masivos de datos multimeu dia. Adem´s de procesar los e a datos a 128-bits. El Emotion Engine ha sido la primera CPU e desarrollada completamente de 128-bits.2. el rendimiento de esta CPU alcanza el de algunos supercomputadores. adem´s de decodificar Dolby. AC3 y DTS. INTRODUCCION A LA ARQUITECTURA DE LA PLAYSTATION2 13 m´ximo). VU1). o e El Procesador de Sonido (SP) [53] El procesador de sonido est´ formado por 2 DSPs conectados a 2 MB de memoria a integrada y es capaz de manejar hasta 48 canales simult´neamente a una frecuencia a de reloj de hasta 48 KHz. Con la incorporaci´n del decodifcador o o MPEG-2 en un chip. Unas cuatro veces el rendimiento de las memorias PC-100 que se montaban en los ultimos PCs cuando sali´ al mercado la PS2. se trata de una CPU RISC de o 128-bits desarrollada por Sony y por Toshiba8 . La CPU incorpora dos unidades de enteros (IU) de 64-bits. Unidad de proceso vectorial con 5 FMAC y 2 FDIV El rendimiento combinado de todos estos elementos permite calculos f´ ısicos complicados. es posible procesar en paralelo datos gr´ficos 3D de alta resoluci´n a o y im´genes DVD de alta calidad. de ah´ que no se requiera excesivo espacio de almacenamiento o ı para texturas de alta definici´n. S´lo ´ n o aquello que tenga la sincronizaci´n en verde. Una puntualizaci´n. La CPU funciona con una velocidad de reloj de 294.

02mm × 15. a nivel de unidades y buses entre las mismas El EE Core est´ formado por el MIPS r5900 y por la FPU. En la Figura 1. realiza el control del videojuego teniendo en cuenta las entradas del usuario9 .7: Estructura del EE. El principal es un procesador basado en la arquitectura MIPS-III y MIPS-IV de 64 bits. Su misi´n es la del a o procesador principal. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES llega a 66 millones de pol´ ıgonos por segundo.5 millones de transistores. Figura 1.14 ´ CAP´ ITULO 1.18 micras. adem´s de un repertorio a 9 Es el que ejecuta el n´cleo de Linux u . lo que es con el rendimiento de las estaciones gr´ficas usadas en la producci´n de pel´ a o ıculas de animaci´n contempor´neas a o a la consola. Es un dado de 15.25 micras con una longitud a ıa de puerta de 0. Los otros dos procesaa dores son dos unidades vectoriales denominadas VU0 y VU1. funciona a unos 300 MHz y consume 18 watios. Sobre la implementaci´n [10] o El EE est´ implementado con tecnolog´ CMOS de 0. De ah´ la estructura de e ı interconexi´n que tienen los 3 procesadores. es decir. La idea de la arquitectura es que la VU0 se use junto con el MIPS r5900 para simular el juego y los procesos f´ ısicos de ´ste. Es un procesador superescalar de 64 bits basado en la arquitectura MIPS-III e incorpora instrucciones de la arquitectura MIPS-IV. Este procesador funciona junto a un coprocesador de punto flotante al que est´ directamente conectado mediante un bus de 128 bits. el r5900. o ıa n Estructura principal El EE se compone de 3 procesadores independientes que pueden trabajar en paralelo.04 mm con 13.7 podemos ver la estructura o general del EE. en tanto que el VU1 se use para simular el mundo 3D. Podemos encontrar una descripci´n detallada de la metodolog´ de dise˜o seguida en [16] [20] [18] [17].

La FPU contiene una unidad FDIV y otra FMAC (multiplicaci´n o y acumulaci´n) para realizar operaciones de 32 bits en coma flotante.5 MHz cuando es el procesador de entrada/salida del EE y a 33 MHz cuando trabaja como si fuera una PlayStation. Este m´dulo se denomina EFU(Elementary Function Unit).2. Adem´s. una mitad inferior y otra superior. una unidad load/store de 128 bits y una unidad de predicci´n de saltos. El DMAC puede realizar transferencias de ı datos que se encuentran en zonas de memoria discontinuas. En m´dulo INTC que vemos en la imagen es el interrupt controller. INTRODUCCION A LA ARQUITECTURA DE LA PLAYSTATION2 15 de instrucciones multimedia SIMD de 128 bits y que es capaz de emitir 2 instrucciones por ciclo. El GS trabaja a 147 MHz [7] [17]. sinedo responsabilidad del programador comprobar dihcos registros. El r5900 tiene dos unidades de enteros de 64 bits que pueden usarse de forma combinada para operaciones multimedia. El IPU decodifica los macrobloques. ıa o La VU1 tiene adicionalmente otra FMAC y otra FDIV. Cada unidad vectorial contiene 4 unidades FMAC de un ciclo y una unidad FDIV de 7 ciclos.912 n MHz para los procesadores del EE. o Las dos unidades vectoriales tiene una arquitectura SIMD-VLIW y permiten operaciones con matrices 4x4 y correciones de perspectiva. DMA Controller) de 10 canales que se encarga de realizar todas las transferencias entre los distintos elementos. El m´dulo SIF (Sub-Processor Interface) es una interfaz entre el EE y el IOP que o contiene una memoria FIFO bidireccional para intercambiar datos entre los procesadores . 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 simulaci´n del juego) su memoria es mayor que la de la VU0. recordemos. o El r5900 puede usar como coprocesadores a la FPU (cop1) y a la VU0 (cop2) y para ello existen instrucciones espec´ ıficas. descargando as´ al EECore de esta tarea. Las se˜ales de reloj que rigen el sistema que son 150 MHz para los buses y 294. se encarga o de gestionar las interrupciones que lleguen al EECore para minimizar los cambios de contexto. Para una completa informaci´n a cerca del funcionamiento del est´ndar o a MPEG se puede consultar [34].´ 1. en el FPU y en el r5900. As´ en los programas que se ejecuratar´n en ı. El m´dulo IPU (Image Data Processor) implementa la descompresi´n por hardware o o de im´genes 2D seg´ne l est´ndar MPEG2 o un subconjunto de ´l. M´s adelante veremos que operaciones que en otros procesadores causar´ a ıan einterrupciones en las unidades vectoriales s´lo causan cambios de bits en los registros o de estados. trabaja a una frecuencia 37. Tambi´n realiza a u a e e VQ (Vector Quantization). Estra caracter´ ıstica se debe principalmente a que la labor principal de EE es la produci´n de display lists que o ser´n interpretadas por el GS y ´stas no tienen por qu´ estar siempre en posiciones a e e de memoria consecutivas. El IOP. pero la compensaci´n o d e movimiento la tinee que realizar el EE por software con ayuda de las instrucciones mltimedia. El EE cuenta con un controlador de DMA (DMAC. Para realizar estas transferencias el DMAC una una lista de punteros enlazada. Dentro de cada VU se consigue paralelismo local dividiendo ´stas en dos unidades e funcionales que pueden operar independientemente y en paralelo. El m´dulo TIMER contiene 4 contadores de 16 bits que se usan con prop´sito o o general para los programas. o Las unidades vectoriales son dos exactamente iguales salvo por el tama˜o de n sus memorias (que es mayor en el VU1) y por una unidad adiconal que incorpora el VU1. a el procesador principal pueden ir mezcladas intrucciones para ejecutarse en el VU0. la VU1 tiene un a m´dulo adicional para realizar operaciones elementales usadas comunmente en operao ciones con geometr´ 3D.

Adem´s. Arquitectura de memoria Para conseguir una mayor eficiencia en las transacciones de datos. as´ mismo. el procesamiento multimedia de o se˜ales de audio y video de alta resoluci´n requiere un ancho de banda muy superior. PATH3:Entre memoria principal y el GIF) y arbitra la preferencia entre ellos. Te´ricamente. cada procesador cuenta con sus peque˜as memorias internas.8 se muestra la arquitectura n de memoria de la PS2. El GIF (GS Interface) es la interfaz con el GS. Todos los m´dulos del EE pueden acceder a esta memoria a rtav´s de una arquitectura o e UMA (Unified Memory Architecture). DEFINICION DE OBJETIVOS Y ESPECIFICACIONES sin sobrecargar el bus.8: Esquema de memoria de la PlayStation2 La memoria principal del EE est´ formada por 2 m´dulos de 16 MBs de memoria a o RDRAM a 400 MHz que alcanza una velocidad de transferencia pico de 3.2 GB/s. n o Este ancho de banda se consigue mediante el uso en cada procesador de peque˜as n memorias dedicadas que se utilizan como buffers para agilizar las transferencais de datos entre los diferentes procesadores del EE. a el GIF da el formato adecuado a los datos para que el GS los pueda interpretar adecuadamente (GIFTag) y se los env´ ıa.9. PATH2:Entre el VIF y el GIF. En la Figura 1. recibe los datos de tres caminos distintos posibles (PATH1:Entre el VU1 y el GIF. Estas memorias son. una memoria interna muy r´pida y con unas propiedades especiales denominada Scratchpad RAM (SPR) de 16 a KB en el r5900 y dos memorias cach´s de dos v´ asociativas por conjuntos. Figura 1. una de e ıas . En el ap´ndice ((El EE a fondo)) podemos encontrar informaci´n en profundidad e o sobre el EE. en el ap´ndice ((Las VUs a fondo)) podemos hacer lo mismo ı e sobre las unidades vectoriales. como vemos en la Figura 1.16 ´ CAP´ ITULO 1.

Por e eso existe un modo de transferencia de memoria que salta la cach´ (UnCached Mode). El ultimo mode que provee el EE es el denominado UCA (UnCached ´ Accelerated) que acelera la lectura de datos adyacentes mientras escribe asincronamente interponiendo un buffer de prop´sito especial denominado UCAB (UnCached o Accelerated Buffer). Ken Kuratagi fue el principal desarrollador del motor de la consola y podemos encontrar varios art´ ıculos suyos en la bibliograf´ ıa. de la que por o aquellos entonces se hab´ vendido m´s de 50 millones10 . Todos estos rumores o 10 Actualmente se han vendido m´s de 73 millones de unidades a . Se anunciaba que la consola ıan a iba a mejorar infinitamente a su predecesora. Sony Computer Entertaiment anunci´n el lanzao miento de la nueva generaci´n de consolas sucesoras de la PlayStation. Figura 1.9: Arquitectura de las memorias de la PlayStation2 La VU0 puede acceder tambi´n a la SPR para compartir datos y cuenta adem´s e a con una cach´ de datos de 4 KB y otra de instrucciones de 4 KB. 1. el uso de cach´s disminue el rendimiento del sistema. El IOP posee tambi´n 2 e MB de memoria independiente. Hubo tambi´n rumores a e cerca de discremancias enrte los ingenieros y la directiva de Sony sobre las potencialidades de la consola de la que se hicieron eco varios peri´dicos. lo que es ideal para a e a e datos temporales. e Est´ tambi´n el modo de transferencia est´ndar usando la cach´.3. e 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 proceso principal es la generaci´n de display lists y ´stas o e se calculan con los datos que se acaban de leer de memoria. Los accesos a memoria se hacen a trav´s del DMAC. En los juegos. En este tipoo de aplicaciones multimedia donde el flujo de datos es claramente unidireccional. La cach´ de datos cuenta con un e mecanismo de escreitura write back. Existen tres modos de acesos e diferente. La consola de videojuegos PlayStation2 El 13 de Septiembre de 1999. Se o lleg´ incluso a decir que la importaci´n estaba congelada en China porque el porderoso o o hardware de la consola pod´ tener aplicaciones b´licas y comenz´ a especularse con ıa e o posibles adquisiciones masivas de los gobiernos de consolas.1. Fueron muchos los rumores que salieron sobre la consola y su comercializaci´n. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 17 dats de 8 KB y otra de instrucciones de 16 KBs.3. se env´ al GS y no se ıan vuelven a utilizar.

Esta consola ha sido dise˜ada desde el pricipio con un claro objetivo: n Juegos 3D. etc. 1 puerto Firewire de alta velocidad. S´lo la primera semana se vendieron m´s de 1 mill´n o o o a o de unidades. 2 slots para los nuevos controles. o . El panel frontal contiene. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES Figura 1. los juegos de la PS2 est´n repletos a de videos.1. el 4 de Mayo de 2000 la consola PlayStation2. aunque siguiendo con la pol´ ıtica de compatibilidad tambi´n funcionan los controles antiguos de la PSX. Es por eso que todo el hardware est´ orientado a que se puedan ejecutar a este tipo de juegos con las m´ximas prestaciones posibles. La PS2 es la evoluci´n de la a o primera consola desarrollada por Sony. e 2 puertos USB que pueden ser usados con cualquier dispositivo USB compatible como teclados. Adem´s de juegos. As´ el consumidor puede reutilizar todos sus juegos de PSX en la PS2. DTS y Dolby Digital 5. Gracias a la gran capacidad de los DVDs. Hab´ continuos problemas de estocaje. Por fin. impresoras. La PSX fu´ de las primeras e consolas cuyos juegos se distribuian en soporte CDROM. la Playstation (PSX). Incluso algunos ı. ıa Para el resto del mundo la consola se hizo esperar y no fue hasta el a˜o 2001 n cuando pudimos adquirirla en Espa˜a. m´sica y sonido en 3D.10: Imagen de una PlayStation2 claramente beneficiaban a Sony pues la consola fue ganando cada vez m´s en espectaa ci´n. Las caracter´ n ısticas t´cnicas de la consola son e impresionantes. Uno de los golpes de efecto comerciales mejor pensados de Sony es la compatibilidad absoluta de las dos consolas. que se puede en la Figura o 1. para televisi´n o o de alta defnici´n y salidas de sonido surround. adem´s de la bandeja para los DVDs/CDs: a 2 slots para las tarjetas de memoria que son de 8 MB normalmente.18 ´ CAP´ ITULO 1. ratones. la PS2 puede reproducir CDs de u a audio y pel´ ıculas en DVD por tanto es una completa plataforma de entretenimiento. Los juegos de la PS2 se distribuyen en DVD aunque tambi´n es capaz de reproducir los juegos de la PSX en e CDROM. La parte trasera contiene conectores para la salida de televisi´n. aunque el formato es el mismo que las de la PSX por lo que se pueden intercambiar. sali´ a la venta en Jap´n. juegos se mejoran ya que se hace un suaizado de pol´ ıgonos.10.

Dolby Digital (AC-3).3. Interfaces: 11 Con 12 Tecnolog´ ıa formas. Start y Select.4 kg Formatos compatibles: CD-ROM / DVD-ROM PlayStation 2 CD-ROM PlayStation CD audio.456 MHz 75 millones de pol´ a ıgonos/s max. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 19 Los mandos est´ndar.864 MHz (seleccionable) Memoria IOP: 2 MB Dispositivo de disco CD-ROM y DVD-ROM: Velocidad CD-ROM: 24x DVDROM: 4x Sintetizador de gr´ficos: 147.912 Mhz Memoria principal: Direct RDRAM Tama˜o de la memoria: 32 MB n Gr´ficos: Graphics Synthesizer (Sintetizador gr´fico) Frecuencia de reloj: 147. DTS Unidad Central de Procesamiento (CPU): Emotion Engine de 128 bits Frecuencia de reloj del sistema: 294.1. a o excepto Analog. El mando consta de: 4 botones ordenados como cursores direccionales (arriba-izquierda). R2 (frente-derecha) 2 joysticks anal´gicos con force-feedback12 (arriba-izquierda y arriba-derecha) o 1.456 a a MHz VRAM cach´ integrada: 4 MB e Sonido: SPU2 No de voces: 48 canales. Dual Shock 2. todos son anal´gicos. L2 (frente-izquierda) y R1. video DVD. Start y Select (medio) 4 botones de acci´n de distintos colores (arriba derecha)11 o 4 botones de accion. L1 . muy importantes pues son el distintivo comercial de la consola de retroalimentaci´n de joystck o . Caracter´ ısticas En la siguiente lista vamos a morstrar las caracter´ ısticas principales de la consola dadas por el fabricante: Dimensiones: 301 mm (altura) x 182 mm (anchura) x 78 mm (profundidad) Peso: 2.868 MHz o 36. tienen 15 botones.3. Botones Analog. Dos posibles frecuencias selecionables 44 y 48 KHz Memoria de sonido: 2 MB IOP: Procesador I/O N´cleo CPU: PlayStation CPU mejorado u Frecuencia de reloj: 33.1.

El kit de Linux mostrado en la Figura 1. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES • Conector DIGITAL OUT (OPTICAL) • Conector para Bus Serie • Universal (USB) Conector para i.2. La salida de nuevas versiones de la consola dificultan u tambi´n el uso de modchips para las mismas.11 contiene: un disco duro interno de 40 GB un teclado usb . o Figura 1.20 ´ CAP´ ITULO 1. Las posibles mejoras n del reproductor de DVD que es lo que es m´s susceptible de mejorar con el tiempo a se resuelven a base de nuevas versiones de la consola que actualizan el firmware o bien cambian la disposici´n de la PCB o introducen m´ o ınimos cambios que para nada cambian ning´n requerimiento. e Los modchip son unos chips que modifican las funciones de la BIOS de la consola y permiten principalmente ejecutar backups de los juegos originales y algunos reproductores multimedia mejorados que permiten reproducir DivX y otros codecs similares.11: Imagen de los componentes del kit de linux Esto convierte a la consola en un ordenador de sobremesa plenamente funcional. El o kit de Linux para PS2 [14] permite ejecutar una distribuci´n Linux en la PS2.LINK Puerto de mando (2) • Ranura de MEMORY CARD (2) • Conector AV MULTI OUT Perif´ricos incluidos: Mando anal´gico DUALSHOCK2 e o 1.S400 i. La principal ampliaci´n que se le puede hacer a la consola es el kit de Linux. Expansi´n y accesorios o Las posibilidades de expansi´n en s´ de la consola son limitadas pues esto ir´ en o ı ıa contra de la pol´ ıtica de dise˜o de mantener la compatibilidad.3.

de aspecto exactamente o igual al del mando anal´gico DUALSHOCK original. El cluster lo constituyen 70 PS2 14 . Pero tambi´n ha desarrollado perif´ricos exclusivos e e para la nueva consola: ´ MANDO ANALOGICO DUALSHOCK2: Sony Computer Entertainment ha desarrollado un nuevo mando anal´gico DUALSHOCK. adem´s de los juegos. la memory card (tarjeta de memoria) incorpora el sistema de autenticaci´n y cifrado ((MagicGate)). La distrubuci´n es una modifici´n o o o de la RedHat13 . PBS. en principio (pese a las negativas de Sony) funciona cualquiera que sea ATA. Es un cluster de C´mputo cient´ o ıfico basado en PS2. Maui Scheduler . las xfree y muchas otras utilidades. Aunque los programas o juegos que se desarrollen sobre el kit de Linux solo podr´n ejecutarse en a una PS2 que tenga el kit. Sony. pero o dotado con controles anal´gicos sensibles a la presi´n (exo o cepto los botones ((START)) y ((SELECT))). Sony proporciona s´lo los binarios de estos drivers por lo o que existen limitaciones a la hora de programar la PS2 con este kit. Con ´l exploran el uso de PS2 en C´mputo e o Cient´ ıfico y Visualizaci´n de Alta Resoluci´n.3. Nosotros hemos empleado el kit de linux en el desarrollo de nuestro proyecto. por lo que es imposible de programar este puerto. El segundo disco contiene todo el software de la distribuci´n que se puede instalar en el disco duro. o 13 Hay 14 Sony otra distribuci´n llamada BlackRhino que est´ basada en Debian o a Linux Kit + MPI. Respecto o al HD. Respecto al teclado y al rat´n valen cualesquiera con tal de que sean usb. De todos los dispositivos que el Kit de Linux trae sellados y etiquetados por Sony. o o Lo dem´s son accesorios que la consola tiene y que tienen su utilidad para los a juegos [7]. u a 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 m´s r´pida que la mea a mory card (tarjeta de memoria) de PlayStation. tambi´n ha hehco compatibles los perif´ricos de a e e la PlayStation con la PlayStation2. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 un rat´n usb o una tarjeta de red 10/100 Base-T dos discos DVD 21 El primero contiene el entorno de ejecuci´n (RTE) y los manuales de la PS2 que o Sony suele incluir en el kit de desarrollo. El Kit viene con el compilador de GNU gcc. El kernel de Linux contiene drivers que ocultan el hardware e impiden el acceso directo a la IOP. el unico que no puede ser est´ndar por sus especiales caracter´ ´ a ısticas es la tarjeta de red. Estos conocimiento son o interesantes de cara a la construcci´n de un cluster de PS2 como el que existe en la o Universidad de Illinois en Urbana-Champaign. para mejorar el control de lo que ocurre en la pantalla y hacer la experiencia de juego interactivo a´n m´s atractiva. mostrado en la Figura ??. Por ejemplo estos drivers no proporcionan interfaz con el puerto Firewire.1. Para mejorar la seguridad de los datos en las posibles aplicaciones futuras en red. En la interfaz que tiene s´lo se puede colocar un disco duro. Por lo que tenemos un completo entorno de desarrollo.

Ubisoft y Virgin Interactive. simplemente. Adem´s de un amplio espacio para o a la PlayStation2 y accesorios. a 1. BOLSA PLAYSTATION2: La bolsa oficial de PlayStation2. Qu´ le falta a la consola e La verdad es que nos encontramos ante una m´quina impresionante que nos ofrece a unas capacidades asombrosas. Squaresoft. el partido perfecto. redise˜ado para PlayStation 2. Sin embargo. Titus Interactive. PORTA CD‘S PLAYSTATION2: Este estuche cuenta con espacio para guardar 12 CDs y un bolsillo especial para la tarjeta de memoria. Podemos hacer el mismo comentario que antes. Kemco. Take2.3. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES MULTITAP: Con el multitap. Crave. Microids. Rockstar.4. Konami. Electronic Arts. Swing. Resistente por fuera y acolchado por dentro. Sony no provee de unas herramientas adecuadas ıcil . no todo es tan maravilloso.3. Ridge Racer V y Formula One 2001. entre o otros Gran Turismo 3: A-spec. Midas. Este accesorio puede parecer una tonter´ pero es una muestra clara de la implicaıa ci´n de Sony en sacar adelante su producto y de dar soporte o original hasta en el m´s m´ a ınimo detalle. Activision. Infogrames. Interplay. con grupos de amigos api˜ados delante del televisor intentando conseguir el gol m´s n a art´ ıstico.3. o. Acclaim. 1. From Software. LucasArts. facilita la movilidad y protecci´n de esta consola. Los principales desarrolladores de juegos han desarrollado y est´n a desarrollando juegos para la PS2. NAMCO. El Speedster2 incluye todos los botones standard de una PlayStation as´ como el sistema de vibraci´n que le proı o porcionan dos motores duales integrados en el mismo volante. cuenta con un compartimento con capacidad para guardar 5 DVDs. Midway. Capcom. los videojuen gos siguen siendo una actividad social. buscando el puro disfrute de una experiencia compartida. son los datos m´ximos. Los datos proporcionados por Sony o a y Microsoft no son realistas. Koei. Este monstruo es un coloso muy dif´ de gobernar. Pese a la dificultad para su programaci´n la PS2 sali´ al mercado con m´s de 30 o o a t´ ıtulos disponibles. FANATEC SPEEDSTER 2: El Speedster2 presenta una combinaci´n de volante y pedao les compatible con la lista siempre creciente de t´ ıtulos para PlayStation y PlayStation2 de juegos de conducci´n. Tecmo.2 muestra algunas consolas disponibles en el mercado en el a˜o de n presentaci´n de la PS2 y las consolas m´s recientes. Eidos. entre otros. este porta CDs oficial de Sony resulta un accesorio casi indispensable para cualquier usuario de PlayStation2.22 ´ CAP´ ITULO 1. mientras que los de Nintendo y a Sega est´n medidos en un juego real. THQ. SCI. Rage Games. Comparativa La Tabla 1.

operativo procesador velocidad procesador gr´fico a pol´ ıgonos por segundo resoluci´n m´xio a ma en pantalla ancho de banda memoria total tarjeta de memoria canales de sonido audio 3D disponible sonido AC3 disponible (DVD) m´dem incorporao do conexi´n en red o almacenamiento DC SEGA Windows CE Hitachi SH4 Risc 200 Mhz. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 23 compa˜´ nıa s. 3 millones 640x480 0.8 gigas/seg.2: Principales caracter´ ısticas de la consola comparada con las que ofrecen sus m´s directas competidoras en el mercado. 20 millones 1280x1024 3. ATI 200 Mhz.1. 20 millones 1280x1024 3.4 gigas) 4 S´ I S´ (8gigas) I NO GD-ROM (1.6 PS2 SONY propio Emotion Engine 300 Mhz. V-25 300 Mhz. 38 megas 8 megas 64 S´ I NO NO / 56 Kbps cablemodem NO formato propio (1.2 gigas/seg. 26 megas 2 megas 64 NO NO S´ / I Kbps 33. a .5 gigas) 4 NO NO XBOX MICROSOFT Windows 2000 Pentium III 733 Mhz.3. 100 millones 1920x1080 6. Power VR 100 Mhz.4 gigas/seg. 64 megas 8 megas 256 S´ I S´ I NO / 56 Kbps Ethernet 100Mb S´ I DVD 5x (9. 38 megas 8 megas 48 NO NO NO / Kbps 56 GAMECUBE NINTENDO propio Gekko IBM 405 Mhz.2 gigas/seg. Sony GS 150 Mhz.2 gigas) 4 NO NO NO DVD 4x (4.7 gigas) 2 S´ I S´ I puertos para mandos de control DVD-video disco duro Cuadro 1.

El KIT contiene dos PS2 de desarrollo: La PS2 TEST.as´ como asesor´ y ejemplos. Sony s´lo proporciona el hardware y o o las librerias. La escasa documentaci´n de la consola hace ı ıa o que sea muy dificil programar ´sta. Entre o ellos los dos m´s conocidos: a . DEFINICION DE OBJETIVOS Y ESPECIFICACIONES de desarrollo y aventurarse en la empresa de programar un juego para PlayStation2.24 ´ CAP´ ITULO 1. es bastante m´s grande que una PS2 normal debido al aumento a de los componentes con respecto a esta. s´lo se hac´ un uso o ıa del 2 % de la VU0 y s´lo el 56 % de la VU1. Disco duro 3. adem´s de ser una empresa intelectualmente muy costosa tambi´n lo es econ´micaa e o mente. 128 MB de memoria principal 2. Primero hay que inscribirse como desarrollardor oficial de Sony y firmar por los t´ ıtulos que se vayan a publicar. como se muestra Figura 1. lo que es un coste muy significativo que lo hace prohibitivo para o usuarios particulares y peque˜as e intr´pidas empresas que quieran aventurarse en este n e mundo. es igual que una PS2 normal pero puede leer CD-R sin necesidad de modchips.12. El coste por unidad es de aproximadamente 20 000 d´lares americanos. Figura 1. o Existen una serie de entornos de desarrollo comerciales pero ´stos suponen un e desembolso econ´mico adicional y no necesariamente una mejora significativa. destacan: 1. Una prueba clara de ello es seg´n los datos de los an´lisis de rendimiento oficiales de Sony a fecha de 2003. un s´lo kit de desarrollo se hace insuficiente para un equipo serio y a o completo de desarrollo de un juego. adem´s. entre las diferencias. Despu´s hay que comprar el kit de desarrollo que da e Sony que se denomina Sony Computer Entertainment Development Kit DTL-T10000. El paradigma de programaci´nde esta consola es e o 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. La PS2 TOOL. Tarjeta de red Sony proporciona a los desarrolladores esta m´quina de tal forma que compilan su a c´digo y se ejecuta sobre el hardware de esta PS2. u a entre todos los juegos analizados todos anteriores a esa fecha.12: PlayStation2 conectada al kit de desarrollo DTL-T10000.

Algunos comentarios sobre la PlayStation2 ((PlayStation 2 est´ trazando una ruta hacia el futuro del entretenimiena to digital en red. Todos los discos los graba Sony en una f´brica en Salzburg. Con este sistema se consigue o porder compilar en el PC y ejecutar directamente en la PS2 sin necesidad de estar continuamente generando CDs por cada prueba. o a Figura 1. Para adquirir cualquiera de estas plataformas de desarrollo propietarias hay que ser desarrollador ofical de Sony. Austria. Hace poco ha salido un compilador denominado VectorEE de Codeplay [3] que aparenta ser la mejor herramienta de desarrollo ya que permite compilar directamente c´digo C y promete paralelizar el solo el c´digo en las distintas unidades vectoriales del o o EE.5. con los gastos adicionales que ello conlleva.13 muestra el interior de la f´brica situada Nagasaki.1.3. No tenemos datos sobre sus resultados.3. Al igual que Snsys nos proporciona un entorno de desarrollo completo con multitud de herramientas. La Figura 1. Tambi´n tiene heramientas de e debug que redirigen la salida al pc para facilitar el desarrollo. Prometen que no existen las a listas de espera para grabar las copias. incluido uno muy interesante llamao do proview que permite mediante el uso del interfaz firewire conectar una PS2 modelo DTL-H Test Unit a un pc.13: Planta de fabricaci´n de Sony en Nagasaki. en la que se a puede ver la fabricaci´n del Emotion Engine y del Sintetizador Gr´fico. Otro gran inconveniente de desarrollar para esta consola es que una vez que tengamos desarrollado el software nos lo tiene que grabar Sony por los especiales sistemas anticopia que posee la consola. Snsys proporciona con el proview los archivos de una iso que corre en esta PS2 a modo de programa monitor permitiendo la comunicaci´n con el software que corre en el PC. 2. ProDG de Snsys. o 1. Tienen diferentes m´dulos. CodeWarrior de Metrowerks. Al igual que PlayStation puso los videojuegos al alcance . LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 25 1.

Curiosidades Una prueba m´s de que la consola PS2 est´ en auge pese a sus ya 4 a˜os de a a n mercado es que ha entrado tambi´n en ella la fiebre del modding. Ridge Racer V y o Tekken Tag Tournament estar´n disponibles en el d´ del lanzamiento. bueno. — Phil Harrison. a Por eso eleg´ el color negro. y depende s´lo de la imaginaci´n del usuario)). No hay resultado predecible. Lo que a nosotros nos cost´ a˜os alcanzar. Podemos encontrar m´s a . En cuanto la vi (la cone sola PlayStation 2). magn´ a ıfico sonido y v´ ıdeo DVD de PlayStation 2. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES de un mercado de masas sin precedentes. Cada viaje es e o activo y unico. infinitas y emotivas experiencias que PlayStation 2 nos reserva es la imaginaci´n.3. a a o ((Acababa de terminar esta pel´ ıcula (La guerra de las galaxias Episodio I: La amenaza fantasma) que es. ´ o o — David Patton. — Ken Kutaragi. sinti´ndonos extremadamente satisfechos de a e nosotros mismos. presidente y director ejecutivo de SCE Inc. Lo que han logrado con PlayStation 2 se sit´a sencillamente u m´s all´ de toda posibilidad de comprensi´n)). director de marketing europeo de SCE Europe ((PlayStation 2 est´ lista para revolucionar el sector del entretenimiento a de la misma manera que PlayStation revolucion´ el sector de los juegos. cuando se combine la potencia deI hardware de PS2 con la de la imaginaci´n y de la narraci´n. legendario dise˜ador de PlayStation 2 n ((La herramienta necesaria para descubrir las nuevas. es alucinante.26 ´ CAP´ ITULO 1. ((Yo me qued´ tan impresionado como vosotros. pens´: ¡esto va rapid´ e ısimo! No puedo seguir este ritmo. tecnol´gicamente de lo m´s o a avanzado Y en eso est´bamos. El ı azul representa inteligencia y vida)). Esto significa que e existe toda una comunidad interesada en realizarle mejoras. o Namco considera que PlayStation 2 es la plataforma m´s viable para la a explotaci´n de sus capacidades de desarrollo de software. la combinaci´n de impresionantes o gr´ficos digitales. estar´ dentro de un a˜o a disposici´n de todo el muno n a n o do. cuando pusieron este juguetito en la mesa. Es impresionante)). No hay o m´todo correcto ni err´neo. y o o a a superar´ nuestras m´s descabelladas fantas´ a a ıas)). el resultado final ser´ fant´stico. director general de Namco 1. abrir´ las a puertas a una nueva forma de entretenimiento en el hogar)). vicepresidente de SCE America ((Los gr´ficos en tiempo real de PlayStation 2 no tienen limitaciones. director y guionista de cine ((Creo que. y result´ ser o todav´ m´s potente que lo que hab´ ıa a ıamos hecho. — George Lucas.6. porque representa la infinidad del universo. — Teeiyu Goto. y a ıa hay otros apasionantes proyectos en curso)). — Yashuhiko Asada.

Figura 1. .1. que no temen destrozar la consola para variar el dise˜o n original.3. La Figura 1.14 muestra los l´ o ımites de la imaginaci´n por o parte de los usuarios de Sony. LA CONSOLA DE VIDEOJUEGOS PLAYSTATION2 27 informaci´n sobre esto en [9].14: Resultado de un modding por parte de un usuario de PlayStation2.

28 ´ CAP´ ITULO 1. DEFINICION DE OBJETIVOS Y ESPECIFICACIONES .

u 2.1. 2. Apendice.1. En la Figura 2. en vez de empe˜arse los ingenieros en mejorar estructuras de procesadores n de prop´sito general decidieron hacer un procesador espec´ o ıfico para lograr mejor rendimiento. El EE a fondo Introducci´n o El Emotion Engine est´ dise˜ado para hacer funcionar a la perfecci´n juegos 3D. La principal carga de procesamiento de un juego 3D es el renderizado de las im´genes. Veremos los aspectos m´s relevantes de las unidades o a que conforman este n´cleo computacional. centro neur´lgico de la potencia de coma putaci´n de la que se ha dotado. La PS2 es una 29 .1 veremos el esquema normal del cauce de renderizado y a como la estrcutura de la consola se adapta perfectamente a este cauce: Figura 2.1: Cauce de renderizado y asociaci´n a una unidad funcional de la consola o Este cauce marca la arquitectura de la consola y explica la topolog´ de los buses. a n o Para ello. ıa El cauce de renderizado es un cauce de datos multimedia en una unica direcci´n y ´ o que se puede realizar concurrentemente con la arquitectura de la PS2.1.Cap´ ıtulo 2 Estudio del hardware: el Emotion Engine En este cap´ ıtulo realizaremos un estudio a fondo del centro de procesamiento principal de la consola: el Emotion Engine.

1. Se proveen instruciones espec´ ıficas para acceder a los dos procesadores e incluso hay una memoria (SPR) que se comparte entre el MIPS y la VU0. a Estas son las partes principales de las que se compone el EE.3. sobre el que explicaremos sus a particularidades.2. Este procesador funciona junto a un copocesador de punto flotante al que est´ directamente conectado mediante un bus de 128 bits.30 CAP´ ITULO 2. lo primero que tenemos que tener claro a la hora de a programar con ´xito el EE es su mapa de memoria.2 del manual de usuario del Emotion Engine[28] podemos encontrar o cual es la direcci´n espec´ o ıfica de los registros. El principal es un procesador basado en la arquitectura MIPS-III y MIPS-IV de 64 bits. Los posibles coprocesadores que puede utilizar el MIPS son el FPU (y se denomina COP1) y la VU0 (y se denomina COP2). ESTUDIO DEL HARDWARE: EL EMOTION ENGINE arquitectura especializada para juegos 3D.2 esta interconexi´n y distribuci´n. 2. 2.3 que representa un esquema que o trata m´s en profundidad el procesador Emotion Engine. Lo podemos ver en la Figura 2. e En la Secci´n 2. Antes veamos la Figura 2. Podemos ver en ı o la Figura 2.2: Reparto de las tareas m´s habituales entre el hardware de la consola. El EE se compone de 3 procesadores independientes que pueden trabajar en paralelo. e De ah´ la estructura de interconexi´n que tienen los 3 procesadores. Ya veremos los modos .1. Para que la unidad vectorial se pueda usar como coprocesador tiene que estar funcionando en modo ”micro”. o o Figura 2. en tanto que el VU1 se use para simular el mundo 3D. igual que el TriMedia de Philips lo es para la descompresi´n de video o el Audigy 2 de Creative lo es para el tratamiento del audio. el r5900. El EE Core El EE Core es la denominaci´n que recibe conjuntamente el MIPS r5900 junto o a sus coprocesadores. Mapa de memoria Adem´s de su estructura. La idea de la arquitectura es que la VU0 se use junto con el MIPS r5900 para simular el juego y los procesos f´ ısicos de ´ste.4. Los a otros dos procesadores son dos unidades vectoriales denominadas VU0 y VU1. Las describiremos en detalle a continuaci´n. o Como hemos visto en la figura anterior el principal elemento de procesamiento del cauce es el EE.

1. APENDICE.3: Estructura interna del Emotion Engine Figura 2.2. EL EE A FONDO 31 Figura 2.4: Mapa de memoria del Emotion Engine .

Tiene 32 bits para a o su espacio de direcciones. En su unidad de gesti´n de meo o moria (MMU) implementa una TLB (Translation Look-Aside Buffer) completamente asociativa de 48 entradas (96 p´ginas). El EECore cuenta tambi´n con una bater´ de instrucciones propias de su especial arquitectura e ıa que sobre todo aprovechan el paralelismo de los cauces y que podemos consultar en [25]. El EECore tiene los tres modos de operaci´n est´ndar de un procesador MIPS [24]: Usuario (User. ıas e El EECore es un procesador superescalar de dos cauces que implementa la arquitectura de instrucciones de 64 bits MIPS-III y parcialmente la de MIPS-IV (instrucciones de precaptaci´n y de movimiento condicional). Supervisor (OS) y Kernel. la multiplicaci´n de tres operandos. e e Adem´s de los 16 KB de SPR para manipular muy r´pidamente grnades estructuras a a de datos y de un buffer para las transmisiones de datos contiguos r´pidamente sin usar a cach´: UCAB (UnCached Accelerated Buffer). tanto f´ ısicas como l´gicas.32 CAP´ ITULO 2. lo que corresponde a un espacio de direcciones de 4 GB y 32 bits para direccionar direcciones l´gicas o virtuales. 4 MB y 16 MB. El micro soporta instrucciones de carga no a bloqueantes. 256 KB. Tiene 16 KB de cach´ de instrucciones (I$) y 8 KB de cach´ de datos (D$). o n a que puede ser 4 KB. PC Unit El PC Unit es el contador de programa (Program Counter). En modo Usuario se pueden direccionar hasta 2GB por proceso de usuario. e Cach´ de direcciones destino de saltos ) que se usa para la predicci´n de saltos. por ejemplo. Esta unidad tambi´n o o e e contiene una cach´ de 64 entradas denominada Branch Target Address Cache (BTAC. 64 KB. o Dentro del esquema que hemos visto anteriormente el EECore se compone del MIPS r5900 junto con sus cach´s. Por las especiales caracter´ ısticas de las VUs nosotros denominaremos EECore s´lo al conjunto o formado por el MIPS (junto con sus memor´ locales y cach´s) y el FPU. Las direcciones virtuales est´n formadas por un n´mero de p´gina o a u a (VPN. En general. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE de funcionamiento de las unidades vectoriales en el apartado dedicado a ellas. Cach´s y Scratchpad RAM (SPR) e Implementa una cach´ de datos de 8 KB y una cach´ de instrucciones de 16 KB. Virtual Page Number) y un desplazamiento (offset). adem´s se le han a˜adido 107 instruo a n ciones SIMD de 128 bits para el procesamiento multimedia paralelo[26]. e o MMU. podemos aplicar al r5900 cualquier documentaci´n sobre la o arquitectura MIPS-III salvo por las instrucciones espec´ ıficas para acceder a los coprocesadores. La estructura del EECore se muestra en la Figura 2. 16 KB. e . la multiplicaci´n de tres operandos que soporta. Usa 32 bits para direccionar direcciones f´ ısicas. los 16 KBs de memoria Scratchpad RAM (SPR) y e la FPU. e e adem´s cuenta con 32 registros de prop´sito general de 128 bits. 1 MB. User o a program).5. Es un PC de 32 bits y mantiene la direcci´n de la instrucci´n que se est´ ejecutando. el taama˜o de la p´gina. esto es. Los tres bits m´s signifia cativos del VPN identifican el modo de operaci´n. la extensi´n de todos los o o registros de 64 bits a 128 bits y el uso del registro r31 reservado para instrucciones de salto. Citemos. Implementa tablas separadas para a datos y para instrucciones. Memory Management Unit (Unidad de Control de Memoria) Como ya dijimos antes implementa una TLB (Translation Look-Aside Buffer) completamente asociativa de 48 entradas (96 p´ginas).

5: Estructura interna del EECore .2. EL EE A FONDO 33 Figura 2. APENDICE.1.

Para conseguir suplir e estas necesidades los ingenieros de Sony dotaron al EE de la Scratchpad RAM (SPRAM o SPR) de 16 KB. lo que significa que e . pero el DMAC tiene prioridad. e e a Algunas aplicaciones requieren una memoria embebida de alta velocidad que se pueda acceder con lecturas/escrituras convencionales para manejar eficientemente estructuras de datos (sobre todo si ´stas son grnades y complejas).1. respectivamente. Est´ configurada como 1024 e a x 128 bits. cuando no e est´ la l´ a ınea de cach´ que se necesita o cuando ´sta es inv´lida. Tanto la CPU como el DMAC pueden acceder a la SPR. Podemos consultar exhaustivamente la e disposici´n de las cach´s en [26]: o e Figura 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE Las cach´s son de dos v´ completamente asociativas y tienen una longitud de e ıas l´ ınea de 64 bytes.1: Organizaci´n de la memoria cach´. implentan una pol´ ıtica Write-back y permiten el bloqueo de l´ ıneas de cach´ y lecturas no bloqueantes.34 CAP´ ITULO 2. Se tienen que usar las instrucciones de cach´ para e e mantener la coherencia. S´lo se lee de e o memoria principal cuando se usan isntrucciones para transparas la cach´. Usa el mismo camino de datos que la cach´ de datos. e u Cach´ e Datos Instrucciones Tama˜o n 8 KB 16 KB Organizaci´n o 64 bytes × 64 entradas × 2 v´ ıas 64 bytes × 128 entradas × 2 v´ ıas Cuadro 2. o e e Todas las lecturas que se hacen de memoria se hacen de cach´. o e En la Figura 2.6 vemos la organizaci´n de la cach´ de datos y la organizaci´n o e o de la cach´ de instrucciones. La SPR es como una cach´ de datos sin etiquetas. Las cach´s se organizan seg´n la Tabla 2.6: Organizaci´n de la cach´ de datos y la cach´ de instrucciones.

2.1. APENDICE. EL EE A FONDO

35

en ciclo determinado de CPU la CPU puede acceder bien a la SPR, bien a la cach´ de e datos, no a las dos simultaneamente. La SPR est´ mapeada en el espacio de direcciones a virtuales. Lo vimos en la secci´n de Mapa de Memoria un poco m´s arriba o lo podemos o a consultar en [26]. Tanto como para leer datos desde la SPR como para escribirlos, se provee de un protocolo especial de DMA (adem´s de las instrucciones de lectura/carga). El espacio a de pagina de ls SPR es de 16 KB. Los 14 bits menos significativos de la direcci´n virtual o se usan para indicar la direcci´n en la SPR, en tanto que los 18 bits m´s significativos o a se usan para acceder a la TLB y determinar si un bloque de 16 KB est´ mapeado en la a SPR o no. Para direrenciar entre los espacios de memoria (puede estar en la cach´ de e 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 env´ una se˜al especial a la CPU ıa n de escritura en la SPR con una direcci´n de SPR de 10 bits. Los datos se colocan el o el CPU BUS. Despu´s la CPU muestrea los datos del bus y los escribe en la direcci´n e o 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 est´ ejecutando mientras concurrentemente, a 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 planificaci´n por parte o de la CPU.

Figura 2.7: (a) La conexi´n de la SPR con la CPU y con la memoria externa a trav´s o e de DMA, (b) la CPU y la memoria accediendo concurrentemente al SPR para grabar y leer datos respectivamente. El UCAB (UnCached Accelerated Buffer) es una peque˜a cach´ de s´lo lectura n e o que se usa en las transacciones de datos que se saltan la cach´ y que sirve para e optimizar las transmisiones y reducir el tr´fico del bus. Acelera las transmisiones de a datos desde direcciones contiguas de memoria. Su disposici´n se muestra en la Figura o 2.8, comparada con otros tipos de transferencia. Issue logic Esta unidad se encarga de colocar un m´ximo de dos intruciones por ciclo en cada a cauce f´ ısico que le corresponda.

36

CAP´ ITULO 2. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE

Figura 2.8: Disposici´n de distintos tipos de transmisi´n a memoria. o o Registros de la CPU Los registros del EECore amplian el conjunto general de registros que define la arquitectura MIPS [24]. Cuenta con los siguientes registros: 32 registros de 128 bits registros de prop´sito general (GPRs, General Purpose o 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 especificar la cantidad de desplazamietno en las instrucciones de desplazamiento. Es de 32 bits y para acceder a ´l se han tenido que definir nuevas instrucciones. e El Contador de Programa (PC). Notar que los 64 bits m´s significativos de los GRPs s´lo se usan con las instruca o ciones espec´ ıficas del EECore (lectura/carga de qword e instrucciones multimedia). Los registros LO y HI tambi´n se han ampliado a 128 bits. Los 64 bits menos significativos e de estos registros (HI0/LO0) se corresponden exactamente con sus hom´logos de 64 o bits HI y LO. Los 64 bits m´s significativos (HI1/LO1) s´lo se usan para las nuevas a o instrucciones de multiplicaci´n y divisi´n. Estas instrucciones son MULT1, MULTU1, o o DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1, MTLO1. Los registros de prop´sito general r0 y r31 son especiales. o El r0 est´ siempre puesto por hardware a valor cero. Cuando se necesita un cero a en una operaci´n se puede usar este registro. Tambi´n se puede usar se realiza o e una operaci´n de la que no se necesita el resultado. o 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 multiplicaci´n entera, de la multiplicaci´n y acumulaci´n entera y de o o o la divisi´n entera. Cuando se realiza esta ultima, el cociente y el resto se almacenan en o ´ LO0 and LO1, y HI0 y HI1, respectivamente.
1 Los

registros en la arquitectura MIPS-III son de 64 bits

2.1. APENDICE. EL EE A FONDO

37

El registro SA especifica la cantidad de desplazamiento cuando se usa la instrucci´n o QFSRV. El registro es espec´ ıfico del EECore y se necesita salvar como parte del contexto del procesador si procediera. Existe una instrucci´n espec´ o ıfica que se ha creado para cargar intercambiar datos entre el SA y los GPRs. El contador de programa (PC) mantiene la direcci´n de la instrucci´n que se o o est´ ejecutando. El PC se incrementa autom´ticamente en pasos de 4 cuando ins a a instrucci´n se ejecuta. Cuadno se produce un salto el PC se actualiza a la nueva o direcci´n destino. Cuando ocurre una excepci´n se cambia el valor del PC a la direcci´n o o o del vector que maneje las excepciones. Cauces f´ ısicos Los cauces f´ ısicos ejecutan las operaciones de las intrucciones. El EECore tiene 6 cauces f´ ısicos que describiremos a continuaci´n: o 1. Cauces I0 y I1. Son los cauces que contienen la l´gica para soportar la aritm´tica o e 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 configuran ambos cauces din´micamente para ser un unico cauce de 128 bits y ejecurar a ´ operaciones de 128 bits. 2. Cauce LS. El cauce LS (Load/Store Pipe) contiene la l´gica para soportar las o instrucciones Load y Store. Cauce BR. El cauce BR (Branch Pipe) contiene la l´gica para ejecutar instruco ciones de salto. Cauce C1. El cauce C1 contiene la l´gica para soportar el coprocesador de punto o flotante FPU (COP1). Cauce C2. l cauce C1 contiene la l´gica para soportar el coprocesador vectorial o VU0.

3.

4.

5.

L´gica de bypass o La l´gica de bypass es una unidad que toma los datos de los GPRs y del Bus de o Resultados y los env´ a los cauces y a la SPR. ıa Buffer de WriteBack (WBB) El buffer 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˜ales del bus n interno del core al bus de la CPU.

Adem´s hay un registro adicional de 32 bits o a a que se usa en las operaciones de multiplicaci´n-acumulaci´n. Figura 2. Soporta operaciones con el 0. Soperta el formato de precisi´n simple definido en el est´ndar IEEE 754. Tiene 32 registros de prop´sito general (FPRs) de 32 bits a los que puede acceder o la CPU meidante instrucciones espec´ ıficas. o a No soporta NaNs ni infinitos.2 muestra cada una de estas etapas.9.10: Cauce de la Unidad de Punto Flotante . en la etapa donde se muestre una barra(/) lo que hay a la izquierda de ´sta se e ejecuta en cauce I0 y. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE La Unidad de punto flotante (FPU. como antes.9: Registros que conforman la Unidad de Punto Flotante La FPU s´lo soporta redondeos a cero. Las operaciones que se relizan en cada etapa concretamente las podemos consultar en el manual [26] proporcionado por Sony. Las instrucciones del COP1 se ejecutan simult´neamente en el cauce de enteros I0 y a en el cauce del COP1. Figura 2. Est´n estructurados como o o a muestra la Figura 2. En la Figura 2. Hay 32 registros de control de punto flotante de los cuales s´lo dos est´n implenetados. en el cauce del COP1. No hay un mecanismos de excepciones hardware que afecte a las instruciones y es compatible con el COP2 (VU0). No sopora ning´n otro tipo de redondeo o u definidos en el est´ndar IEEE 754. cada una con dos fases.10. La Tabla 2.38 CAP´ ITULO 2. a El cauce de la FPU consta de 8 etapas. lo que hay a la derecha. Floating-Point Unit) La unidad de punto flotante es un coprocesador fuertememte acoplado al MIPS del EECore.

enumeradas en la Tabla 2. decodificar y ejecutar un m´ximo de dos instrucciones en paralelo cada ciclo. a El EECore tiene 4 cuaces distintos de enteros: los cauces I0 y I1.3: Significado de las siglas de las etapas de los cauces del EECore.1. Cada cauce tiene las siguientes 6 etapas cada una con dos fases.3 y mostradas en la Figura 2. Las operaciones que se relizan en cada etapa concretamente las podemos consultar . Figura 2. EL EE A FONDO S´ ımbolo 1I 2I 1Q 2Q 1R 2R 1T 2T X Y Z 1S 2S Etapa Captaci´n de instrucci´n o o Captaci´n de instrucci´n o o Decodificaci´n de instruccion o Decodificaci´n de instruccion o Captaci´n de los registros o Captaci´n de los registros o Captaci´n de los registros en COP1 o Captaci´n de los registros en COP1 o Ejecuci´n 1 o Aritm´tica/ALU1 e Aritm´tica/ALU2 e Escritura de resultados Escritura de resultados Fase Fase 1 Fase 2 Fase 1 Fase 2 Fase 1 Fase 2 Fase 1 Fase 2 39 Fase 1 Fase 2 Cuadro 2. y los cauces LS y BR.2: Significado de las siglas de las etapas del cauce de la FPU.11. Cauce de las operaciones superescalares El EECore tiene u cauce superescalar segmentado en 6 etapas.11: Etapas de los cauces del EECore.2. S´ ımbolo 1I 2I 1Q 2Q 1R 2R 1A 2A 1D 2D 1W 2W Etapa Captaci´n de instruccion o Captaci´n de instruccion o Decodificaci´n de instruccion o Decodificaci´n de instruccion o Captaci´n de los registros o Captaci´n de los registros o Ejecuci´n o Ejecuci´n o Captaci´n de los datos o Captaci´n de los datos o Escritura Escritura Fase Fase 1 Fase 2 Fase 1 Fase 2 Fase 1 Fase 2 Fase 1 Fase 2 Fase 1 Fase 2 Fase 1 Fase 2 Cuadro 2. APENDICE. Puede captar.

2.4: Interrupciones que es capaz de controlar el m´dulo INTC.4. Se pueden inicializar y producen interrupciones cuando alcanzan el valor de referencia o cunado producen overflow. INTC) El m´dulo INTC es el controlador de interupciones que gestiona las interrupciones o de los procesadores y de los otros elementos del EE salvo las del DMAC. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE en el manual del Emotion Engine [26]. Este procesador es muy did´ctico y puede usarse a como ejemplo para la docencia de la asignatura ((arquitectura de computadores)). TIMER El m´dulo TIMER es un m´dulo que implementa cuatro contadores independientes o o de 16 bits cada uno. 2.1. Si es el DMAC el que la produce. Cuando un dispositivo (que no sea el DMAC) produce una interrupci´n. 1/256 BUSCLK y con las se˜ales externas n H-BLNK/V-BLNK para sincronizarlos con la imagen de la pantalla. El Controlador de interrupciones (Interrupt Controller. Hay un flag en el registro de estado que indica cual ha sido la causa que ha producido la interrupci´n. El INTC controla quince posibles ıa n interrupciones que se resumen en la Tabla 2. consultar el Manual de Usuario [28] proporcionado por Sony a o junto al kit de linux. Los contadores se o pueden sincronizar con 1/16 de BUSCLK.5.40 CAP´ ITULO 2. tanto el Timer 0 como el 1 tienen un registro donde almacenar el valor de la cuenta cuando se produce una interrupci´n SBUS. Adicionalmente. o .1. el INTC la gestiona y o env´ al EECore la se˜al de interrupci´n INT0.4: ID 0 1 2 3 4 NOMBRE INT GS INT SBUS INT VB ON INT VB OFF INT VIF0 CAUSA Detecci´n deuna interrupci´n en el GS o o Detecci´n de una interrupci´n en un perif´rico del o o e SBUS Comienzo del V-Blank Final del V-Blank Detecci´n de un VIFCode en el VIF0 con el bit de o interrupci´n activado o una excepci´n en el VIF0 o o que activa una interrupci´n (stall) o Detecci´n de un VIFCode en el VIF1 con el bit de o interrupci´n activado o una excepci´n en el VIF1 o o que activa una interrupci´n (stall) o Ejecuci´n de una micro instrucci´n en la VU0 con o o el bit de interrupci´n activado o la ocurrencia de o una interrupci´n en la VU0 (stall) o Ejecuci´n de una micro instrucci´n en la VU1 con o o el bit de interrupci´n activado o la ocurrencia de o una interrupci´n en la VU1 (stall) o Detecci´n en el IPU del final de los datos o una o excepci´n o Condicio´n de interrupci´n del contador 0 o o Condicio´n de interrupci´n del contador 1 o o Condicio´n de interrupci´n del contador 2 o o Condicio´n de interrupci´n del contador 3 o o Detecci´n de error durante una transferencia SFIFO o Interrucpci´n que se produce cuando la VU0 lleva o en el estado RUN mucho tiempo (ForceBreak) 5 INT VIF1 6 INT VU0 7 INT VU1 8 9 10 11 12 13 14 INT IPU INT TIMER0 INT TIMER1 INT TIMER2 INT TIMER3 INT SFIFO INT VU0WD Cuadro 2. ´l ıa n o e mismo env´ otra se˜al distinta INT1 al EECore. o Para m´s informaci´n.

Modo de transferencia l´gico (Logical Transfer Mode) que es seleccionable en o cada canal. o Las transferencias desde y hacia un perif´rico se realizan en paquetes de 8-qwords e denominadas slices. Existe la a funci´n de control de stall que permite sincronizar las transferencias desde y hacia o memoria principal.1. Es este modo los datos se tranfieren en grupos. 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. es to no impide que la CPU acceda a memoria principal. adem´s. Los canales que tiene como origen la memoria (excluyendo toSPR) pueden seleccionar como origen bien al memoria. ID 0 1 2 3 4 5 6 7 8 9 Canal VIF0 VIF1 GIF fromIPU toIPU SIF0 SIF1 SIF2 fromSPR toSPR Sentido hacia desde/hacia hacia desde hacia desde hacia desde/hacia desde desde Prioridad A C C C C C C B C C Cuadro 2. Hay dos modos de transferencia por los canales del DMA: 1. Hay 10 canales de DMA. EL EE A FONDO 41 2.2. Se divide en dos tipos: 1. Modo r´faga (Burst Mode). Dentro de cada modo hay distintas categor´ Las vamos a enumerar y a describir ıas. La unidad m´ ınima que se transfiere es la cuaddruplepalabra (qword. El SBUS tiene tres canales (ID = 5. En este modo los datos se transfieren en paquetes de 8 qwords en conjunci´n con otros canales de DMA. a 2. bien la SPR. o . Los datos que se transfieren tiene que estar alineados a fronteras de 128 bits. 6. 128 bits). a Como hay m´s de un bus se permiten transferencias concurrentes por los distintos a buses. El controlador de DMA (DMA Controller. 2. brevemente. 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. APENDICE. Modo Slice (Slice Mode). Hasta que la transferencia de un slice no se completa el canal que est´ usando la transferencia permanece ocupado y monopoliza los derechos del bus. La prioridad es A > B > C. mostrados en la Tabla 2. Modo de transferencia f´ ısico (Physical Transfer Mode) que es fijo para cada canal. bien la SPR. Modo de transferencia f´ ısico (Physical Transfer Mode). Las transferencia con el DMAC se especifican en base a sus direcciones f´ ısicas y no se hace traducci´n alguna con la TLB.5.6.1.5: Disponemos de diez canales DMA para realizar transferencias.

Cuando hay m´s de una petici´n simult´nea de DMA. Es e una transferenca DMA normal. las peticiones se ordenan a o a seg´n la prioridad siguiente de los canales: u . Modo Normal (Normal Mode). Cada bloque que se transfiere contiene informaci´n o a cerca de la direcci´n del siguiente bloque a transferir en una estructura o denominada DMATag. Es un modo especial de transferencia en el que se puede transferir un rect´ngulo dentro de una regi´n de mea o moria bidimensional (una imagen) y transferirla a la SPR (y viceversa). Se pueden seleccionar tres o modos: 1. Para transferir datos desde la SPR al GIF o al VIF1. Transfiere desde una direcci´n de origen a o una destino tantos bytes consecutivos como se indiquen. Si el modo es Slice Mode los bloques se trocean en Slices y posteriormente se transmiten. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE Modo de transferencia l´gico (Logical Transfer Mode).42 CAP´ ITULO 2. Figura 2. Este modo lee datos continuamente de la memoria principal o de la SPR y los transfiere a un perif´rico o viceversa. Este buffer circular o se llama MFIFO (MemoryFIFO). a 2. Modo Cadena (Chain Mode). Su funcionamiento queda ilustrado en la Figura 2.12. En este modo se transfienren datos entre la SPR y la memoria principal. Las transferencias se dividen en slices (8 qwords) si est´ seleccionado el Slide Mode o de una a sola vez si est´ seleccionado el Burst Mode. Si el modo es Burst Mode cada bloque se transmite seguido.12: Ejemplo de transferencia de una regi´n rectangular de entre la memoria o principal y la SPR. En este modo se transfiere desde posiciones de memoria no contiguas. Modo Entrelazado (Interleave Mode). se puede usar como memoria FIFO para agilizar las transferencias un buffer circular que hay implementado en memoria principal en conjunci´n con los DMATag correspondientes. 3. El DMAC realiza los cambios de direcci´n de los o bloques a transferir sin ayuda del EECore.

(ii) interrupci´n de DMA debida a un stall. El GIF puede obtener los datos de tres caminos distintos mostrados en la Figura 2. o 2. Normalmente los datos que se env´ al ıa ıan GS los genera la VU1 (simple stream) o el EECore en conjunci´n con la VU0 (complex o stream).1. Este es el camino entre la FIFO del VIF del VU1 y el GIF. GS Interface El GIF es la interfaz entre el EE y el GS. (iii) o o interrupci´n debida a que la Memoria FIFO se queda vac´ y (iv) interrupci´n BUSERR o ıa o (error en el bus). Interfaz del GS (GIF. se produccir´ un stall. 3. Obtiene los datos que se generan en el EE y los env´ con su formato adecuado al GS. PATH1.2. seg´n la unidad funcional de origen. Este camino se usa cuaando se usan las instrucciones DIRECT/DIRECTHL. PATH 2 y PATH 3: 1. Aunque estos datos se generan y se env´ en paralelo.13.13: Posibles caminos hacia el GIF. La instrucci´n de la VU1 que o realiza este envio es XGKICK. PATH 2. u . PATH 3. a saber. PATH 1. se encolar´ S´lo puede encolarse uan transferencia. Figura 2. Se usa cuando se transfieren datos al GIF directamente desde memoria principal o desde la scratchpad RAM. APENDICE. Este camino de datos es el que siguen los datos que van desde la memoria de datos de la VU1 (VU1 Mem1) al GS. Si se produjera esta instrucci´n antes de que se o terminara otra transferencia por el mismo camin. el GIF establece un ıan mecanismo de arbitraje de prioridad entre ellos.7. Si la ıa transferencia se produjera mientras ocurren otras por cualquiera de los otros dos caminos.1. ıa. EL EE A FONDO 43 V IF 0 > SIF 2 > V IF 1 > GIF > f romIP U > toIP U > SIF 0 > SIF 1 > f romSP R > toSP R El controlador de DMA puede producir interrupciones por las siguientes cuatro causas: (i) Interrupci´n del canal. Este es el camino directo entre el bus principal del EE y el GIF. 2.

listado. no se hacen consecutivas. Si se especifica el intermitente. o a PRE: Bit 46: Ignorar el campo PRIM o no. El GIFtag tiene 128 bits y especifica el tama˜o y la a n estructura de los datos que vienen a continuaci´n. Modo Empaquetado (Packed Mode).59: Formato de los datos (empaquetados. tambi´n indica si es empaquetada. lo que es l´gico si tenemos en mente la idea inicial de la aro quitectura de que sea el VU1 quien se ocupe de calcular el mundo 3D. 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.127: Descriptor de los registros Tanto el GIFTag como los datos tienen que estar alineados a una frontera de 128 bits. EOP: Bit 15(End Of Packet) Informaci´n de si vienen m´s primitivas. 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. Hay dos e formas de hacer esto. La unidad b´sica de transferencia con el GIF es una primitiva del GS que consiste a en una GIFtag y a continuaci´n datos. Cuando se usa el PATH 3 en IMAGE Mode se pueden especificar dos modos de transmisi´n. Estos modos son: 1. su prioridad es P AT H1 > P AT H2 > P AT H3. N´mero de registros a usar.63: Descriptor de los registros. NREG: Bits 60 . Su estructura es: o NLOOP: Bits 0 . a Las transferencias por el PATH 3 pueden ser tambi´n enmascaradas. Despu´s del GIFTag los datos pueden estar en tres modos distintos que especifican e como tratarlos. Si se piden trasmisiones simultaneas por los canales se resuelven en base al esquema de prioridad anterior. 3. aunque las transferencias se ordenen consecuivas. u Cuando el valor es cero son 16. 2. Datos a mandar al registro PRIM del GS. Por lo tanto. continuo e intermiente. tama˜o de la primitiva. ´stas.44 CAP´ ITULO 2. Este modo se usa cuado se manda una imagen (como puede ser una textura) al GS. imagen. e efectivamente. o Modo REGLIST (REGLIST Mode). n e o imagen. Las transferencias se hacen por los distintos caminos a una frecuencia de 147. Las transferencias se hacen en paquetes que o consisten en dos o m´s primitivas. bien a trav´s de la instrucci´n MSKPATH3 o bien a trav´s del e o e campo M3R en el registro GIF MODE. PRIM: Bits 57 . Mientras se hace el arbitraje de la prioridad se produce un ciclo desocupado (idle cycle). o n Modo Imagen (IMAGE 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 direcci´n especificada en esos mismos registros. .14.456 MHz. deshabilitado). ESTUDIO DEL HARDWARE: EL EMOTION ENGINE Estos tres canales tienen un esquema de prioridad.47. tras cada slice o que se transmita se sondean los otros caminos y se les da la preferencia si necesitan transmitir (son de m´s prioridad). Luego se hacen los paquetes en funci´n de estos registros y se reduce su tama˜o. FLG: Bits 58 . REGS: Bits 64 .

Podemos apreciar una muy buena calidad.8. El plano alpha (plano de transparencias) se genera a partir del valor de luminacia decodificado y de un coeficiente. Unidad de procesamiento de im´genes (IPU. La compensaci´n de movimiento no la a o realiza el IPU. La imagen decodificada se transfiere al GS que la usa como textura o como datos de animaci´n. Esta tecnica se usa para proveer el patr´n de texturas que la t´cnica CLUT requiere. en la Figura 2. Esto significa que los datos se leen. Control de transparencias.1. 2. Tambi´n se usa o e e cuando la capacidad del area de texturas est´ limitada. la conversi´n RGB.2. La idea de Sony es que a para ver una textura en la TV al 50 fps no es necesario que sea una textura de 32 bits. La tiene que realizar el EECore ayudado por las instrucciones multimedia. De hecho. APENDICE. El IPU puede convertir una imagen a color deodificada o directamente a una paleta de colores indizada de 4 bits haciendo la cuantizaci´n o de vectores dada por CLUT (Color LookUp Table). El IPU decodifica los macrobloques que van en o el bit stream y los convierte a RGB. El IPU interpreta y decodifica por hardo a ware el bit stream est´ndar de MPEG2. o a o la cuantizaci´n de vectores y la descompresi´n de chorros o cadenas de bits (bits o o streams). EL EE A FONDO 45 El registro de privilegios del GS est´ directamente mapeado en el espacio de dia recciones del EECore. Image Data a Processor El IPU es una unidad de procesamiento de imagenes con capacidad para realizar la decodificaci´n de los macrobloques del est´ndar MPEG2 [34]. Cuando se hace una transferencai al GS el GIF especifica en cual de los dos contextos posibles del GS se almacena. Esta es una de las capas de MPEG2. Cuantizaci´n de vectores.1.14: Estructura de la Unidad de Procesamiento de Im´genes a El IPU implementa las siguientes capacidades: Decodificaci´n est´ndar de bit streams. Las funciones b´sicas del IPU son: a . No posee ning´n buffer especial y comparte la memoria principal con los u otros procesadores a tiempo compartido. se colocan en memoria principal.15 vemos texturas de la PS2 de 4 bits solamente. o Figura 2. se decodifican y se vuelven a colocar decodificados en memoria principal. Decodificaci´n de macrobloques.

16: Proceso de decodificaci´n de MPEG2 empleando el IPU. o . como se puede comprobar. Figura 2.15: Con un n´mero reducido de colores se puede conseguir una textura de u gran calidad.46 CAP´ ITULO 2. Cada textura usa tan solo 4 bits de color. ESTUDIO DEL HARDWARE: EL EMOTION ENGINE Figura 2.

Figura 2. 3. el DMAC trabaja en cooperaci´n con el SIF y con su memoria FIFO bidireccional (SFIFO). SIF. De esta manera. Decodificar los macrobloques MPEG2. Para transmitir datos desde el IOP al EE. La Figura 2. el controlador de DMA del IOP lee del DMATag la direcci´n de su espacio de memoria y carga los datos con el tama˜o o n especificado desde la direci´n le´ hasta la SFIFO. de la direcci´n de los datos en el espacio de memoria del EE y del o tama˜o de los datos en s´ n ı. . Decodificar el bit stream MPEG2.1.17: Estructura del SIF Para transmitir los datos.18 nos ilustra el proceso.9. APENDICE. A cada paquete se le asocia una etiqueta (DMATag) que es uan estructura de datos que contiene metainformaci´n a cerca de la direcci´n de los datos en el espacio o o de memoria del IOP. el DMAC del EE vuelve o ıda e a leer el DMATag para obtener la direcci´n de los datos en su espacio de memoria o y saca los datos de la SFIFO y los copia donde proceda. 47 Esquem´ticamente.17 se muestra la estructura del SIF. En la Figura o 2. 2.16.1. el proceso de descompresi´n de video MPEG2 usando el IPU se a o muestra en la Figura 2. ´stos se agrupan en unas unidades llamadas paquetes e (packets). el disco duro y los dem´s perif´ricos de entrada/salida de a e la consola. el uso del DMAC y de la SFIFO evita que se produzcan interrupciones innecesarias y se mejora el rendimiento. EL EE A FONDO 1. Extraer el bit stream MPEG2.2. Despu´s. Sub-CPU Infertace El SIF el un m´dulo que sirve como la interfaz de la unidad con el IOP. 2. Para realizar las transferencias con los dispositivos. Recordemos o que el IOP tiene sus propios 2 MB de memoria local y su propio bus para controlar el procesador de sonido.

ESTUDIO DEL HARDWARE: EL EMOTION ENGINE Figura 2.48 CAP´ ITULO 2. .18: Flujo en una transferencia de datos entre el IOP y la memoria del Emotion Engine.

a fin de servir como manual did´ctico.Cap´ ıtulo 3 Desarrollo del proyecto Explicaremos con detalle las alternativas de las que disponemos para realizar el proyecto. Iremos comentando al par las decisiones a de dise˜o y de implementaci´n. Ahora comenzaremos el desarrollo de cada parte. ı o Primero debemos observar el hardware disponible. y comentaremos los problemas encontrados as´ como las soluciones propuestas y la soluci´n adoptada. inicialmente hemos organizado el proyecto en tres tareas bien definidas.2. as´ como una gu´ paso a paso de la soluci´n que hemos adoptado definitivaı ıa o mente.1.1 o a o e muestra un funcionamiento normal de las unidades funcionales que vamos a emplear seg´n su dise˜o original. as´ como los posibles problemas encontrados. Figura 3. mientras que la VU1 se emplea principalmente para c´lculos a computacionalmente pesados que se aplican constantemente y de forma invariante a la geometr´ ıa. y la funcionalidad de cada parte.1. Como se aprecia.1. para poder determinar una distribuci´n lo m´s l´gica posible sobre ´l. Desarrollo del proyecto Especificaci´n de las tareas o Como vimos en la Figura 1. La Figura 3. el procesador central y la VU0 se encargan u n del procesamiento variado. o 3. y la n o ı soluci´n adoptada. 3.1: Uso normal de los procesadores que conforman el Emotion Engine 49 .

Por tanto. o o Los ficheros necesarios pueden encontrarse en el proyecto ((ps2stuff)) [8] del portal de linux para la Playstation2 [14]. y o para ello debemos permitirle una cierta sencillez de depuraci´n para evitar la apat´ o ıa que produce la frustraci´n de la impotencia. quedan dos alternativas que detallaremos a continuaci´n. necesitamos nuevamente poder arrancar un programa cualquiera en la consola.1. M´todo de programaci´n de la consola e o Como mencionamos anteriormente. y a supone programar a un nivel demasiado cercano a la m´quina. y permite mostrar mensajes de depuraci´n directamente en el PC. DESARROLLO DEL PROYECTO 3. requisito principal en un ambiente u o educativo. B´sicamente se necesitan los siguientes elementos: a Compilador para el procesador central MIPS (el Emotion Engine) Ensamblador para las unidades vectoriales (las VU) Con ´stos elementos configurados de forma adecuada podremos generar ejecue tables tanto para el procesador MIPS como para las unidades vectoriales VLIW. Teniendo en cuenta que lo que buscamos es poder programar las unidades principales de procesamiento de forma c´moda para facilitar la realizaci´n de o o pr´cticas de laboratorio sobre arquitecturas no comunes. mediante una arquitectura cliente-servidor. a trav´s del puerto USB. o ıa Grabar un CD-ROM cada vez que vayamos a probar el programa supone un gasto considerable en material. Se realiza mediante la o creaci´n de los ejecutables usando compilaci´n cruzada desde el PC. e mediante un cable especial denominado PL2301.2. Para poder o cargar el cliente de Naplink en la consola. El programa resultante se ejecuta directamente en la consola. pues no disponemos de a ning´n tipo de facilidad a la hora de la depuraci´n. Podemos recurrir a la implantaci´n de un ((mod-chip)) o para paliar esta limitaci´n. existen principalmente tres formas de programar la consola. Otra posible v´ para enviar el ejecutable a la m´quina pasa a trav´s de la aplicaci´n ıa a e o conocida como ((Naplink [40])). no necesitando ninguna configuraci´n adicional de software ni hardware en la consola. De nuevo surge un inconveniente con esta v´ de trabajo. Este programa crea un link de comunicaci´n mediante el puerto USB entre o el PC y la consola. tampoco necesitamos el equia po y soporte requerido en un desarrollo comercial. por lo que necesitamos disponer de un ((mod-chip)). No hay que olvidar que queremos iniciar la programaci´n al alumnado.50 CAP´ ITULO 3. de forma que la consola ejecuta el ejecutable que se le transfiere desde el PC.2. adem´s de la necesidad de implantar una grabadora de CD a en los ordenadores que se vayan a destinar para el desarrollo sobre la consola. con la p´rdida de garant´ o e ıa que ello supone. Adem´s necesita tener al menos un PC para programar las consolas. ni disponemos del presupuesto necesario para hacerlo. Esta opci´n requiere tener modificada cada consola. pues no podemos acreditarnos como desarrolladores oficiales de Sony. un programa de transmisi´n de ficheros entre la consola o y un ordenador. El principal inconveniente que presenta este m´todo es la forma de hacer que el ejecutae ble generado sea cargado por la consola. esperando que arranque. cuyo aspecto es el que muestra la Figura 3. o Tambi´n tenemos que tener en cuenta que ninguna de las bibliotecas usadas de e esta forma tienen soporte de Sony. o Programaci´n stand-alone o Nos referimos a la que se realiza sin soporte alguno por parte de la consola. funcionar . y que pueden variar sin previo aviso. La ((mejor)) alternativa es inviable para nosotros. Debido a la protecci´n anticopia presente en o el hardware de la Playstation2. no se puede grabar un CD-ROM e insertarlo en la bandeja.

clientes y utilidades entre muchas otras aplicaciones. dejando las VU totalmente libres.adquirimos el kit de desarrollo linux que ofrece Sony. toda la funcionalidad de este sistema operativo est´ disponible. Tambi´n recibimos una distribuci´n especial de linux para la arquie o tectura MIPS de la PlayStation2. DESARROLLO DEL PROYECTO 51 mal. aunque sea a nivel ensamblador de procesador. Al estar trabajando bajo un linux. ya que ambos estar´n generando c´digo objeto a a o de un MIPS III modificado. facilitan la tarea del usuario hacia la programaci´n. Esta familiaridad conseguida supone una gran reducci´n de la complejidad que supone enfrentarse a un nuevo tipo de hardware. pero no limita por ello la capacidad de utilizaci´n en cuanto a o formaci´n did´ctica se refiere. servidores. basada en Red Hat. o a . contamos con una gran o cantidad de bibliotecas y utilidades que facilitan el desarrollo. y lo suficientemente completa como para traer gran cantidad de herramientas y utilidades de desarrollo para la plataforma. adem´s de proporo a cionar un entorno familiar de desarrollo. el MIPS. como apuntamos inicialmente cuando la mencionamos. Supone una capa mayor de abstracci´n entre el e o hardware y el usuario. sin embargo. compiladores. Para las unidades vectoriales disponemos de un ensamblador espec´ ıfico para dichos fines. pero hay que pensar que cuando se trabaja con una arquitectura general. as´ como sus herramientas m´s a ı a comunes. Esto conlleva la seguridad de que todo lo que se programe para las VU no se ver´ afectado por el a sistema operativo. Hay que tener en mente que el sistema operativo est´ ejecut´ndose unicamente a a ´ en el procesador central. o pues al menos el entorno de desarrollo se mantiene m´s o menos inalterado. los mandos de control (o ((gamepad))). lo que supone un grado de similaritud muy elevado para el programador. as´ como una interface ı de entrada/salida hacia el lector de DVD.2: Cable PL2301 USB Programaci´n mediante el kit de linux o Con esta opci´n. Tan solo lo que ejecute el procesador principal competir´ con el a sistema operativo en cuanto a recursos. estar incompletas. En esta ocasi´n. Puede parecer un gran impedimento a priori.1. pudiendo centrarse unicamente en el ´ aprendizaje del nuevo hardware subyacente.3. el disco duro. el sistema operativo siempre va inherente (excepto en contadas excepciones en las que unicamente se emplean ´ instrucciones de la BIOS). pudiendo a aplicar conocimientos adquiridos hace tiempo para obviar la parte del aprendizaje de un nuevo conjunto de herramientas de desarrollo. como es la x86. Editores. mientras que para el MIPS tendremos el compilador nativo. o simplemente indocumentadas. que a efectos pr´cticos a resultar´ ser semejante al cruzado. Figura 3. con lo que contamos con una ayuda oficial de Sony. y disponeo mos de los manuales de las unidades funcionales. los puertos USB. ya acostumbrado a trabajar en entornos linux. etc´tera.

52 CAP´ ITULO 3. quiz´s sea un punto m´s delicado a tratar. La distribuci´n. siendo imposible compilar la aplicaci´n para que funcione o de forma ((stand-alone)). El driver del n´cleo abstrae dicho hardware y proporciona una u interface similar a la que encontramos en cualquier sistema operativo linux. Tambi´n hay que recordar que o e recibe soporte de Sony. que repartir´ tareas y se encargar´ de coordinar el resto de unidades. Si se desea obtener m´s informaci´n sobre la a o programaci´n de ´sta arquitectura. es un producto muy competente para arquitecturas de prop´sito general. pensando en el a o prop´sito real del proyecto. Consideramos o que el c´digo objeto generado es suficiente ´ptimo como para descartar la idea de o o programar en ensamblador para el MIPS. e Elecci´n del sistema de programaci´n o o Teniendo en cuenta las ventajas y desventajas proporcionadas por cada m´todo. y disponiendo del visto bueno del departamento. para aprovechar el uso de bibliotecas ya disponibles y la programaci´n con o los componentes de entrada/salida del resto de consola. sabemos por experiencia propia que el compilador de C nativo disponible en el sistema. No podemos olvidar el descargo monetario que supone esta opci´n que. el compilador GNU C Compiler (gcc).3. Por tanto. e conclu´ ımos que la mejor opci´n ser´ disponer de una facilidad de depuraci´n y deo ıa o sarrollo por encima del rendimiento. ya que los drivers e e del n´cleo de la distribuci´n de linux que trae el kit nos impiden controlar dicho proceu o sador a un nivel similar al del resto de componentes. ya que no existe un gran inter´s did´ctico en acceder o e a al lector de DVD o a los mandos de control de forma cercana al hardware. basada en dispositivos. supone un gasto o adicional que no posee la opci´n anteriormente descrita. y la abstracci´n que hacen las bibliotecas y el sistema operativo de los mismos evitan la ardua o tarea de tener que realizar muchas llamadas a bajo nivel para abrir un fichero o leer los botones presionados. tambi´n conocido como IOP. la aplicaci´n necesita de bibliotecas y soporte del sistema operativo o que solo se encuentran disponibles en un kit de linux. algo que se pierde casi con total seguridad al intentar usar el m´todo ((stand-alone)) debido a la necesidad de implantar un ((mod-chip)). o concretamente al manual de instrucciones [25] del MIPS espec´ ıfico de la PlayStation. ya que se trataba de comenzar desarrollos en la m´quina. cualquier aplicaci´n o desarrollada bajo un kit de linux solamente funcionar´ en otra consola en la que se a disponga de un kit de linux. 3.1. adquirimos o un kit de linux para comenzar el desarrollo sobre la PlayStation2. Por tanto. Por tanto. por contra. esto no supone una limitaci´n para nuestros fines. aunque no o a a repercute en la funcionalidad did´ctica del material. DESARROLLO DEL PROYECTO La unica limitaci´n que encontramos a nivel de programaci´n es la unidad de con´ o o trol de entrada salida de perif´ricos. lo que aprovecharemos de este procesador es su arquitectura de prop´sio to general. puede remitirse al Manual de Referencia sobre los o e MIPS [32]. si bien o no es comparable a la opci´n que hemos descartado directamente. Sin embargo. Al haber sido desarrollado bajo a el kit de linux. Programaci´n de las unidades o EE Core (procesador MIPS) Aunque disponemos del repertorio completo de este procesador en los manuales que ofrece Sony en los DVD del kit adquirido. y no de realizar una producci´n de alta calidad. siendo el procesador ((central)) de la aplicaci´n. o a a .

DESARROLLO DEL PROYECTO 53 Como hemos dicho. disponemos de un ensamblador para dicha unidad.3 muestra un esquema con los pasos necesarios para ejecutar un programa en la unidad vectorial. El manual se refiere a ambas unidades vectoriales. ´ o La informaci´n detallada sobre su repertorio de instrucciones viene en el manual o de las unidades vectoriales proporcionado por el DVD de documentaci´n que acompa˜a o n al kit de linux.1. ya que basta crear un programa y ejecutarlo tal y como se llevar´ a cabo en cualquier otro linux ejecut´ndose en una arquitectura ıa a soportada cualquiera. suponiendo una disponibilidad del procesador variable y dependiente del tiempo para nuestra aplicaci´n. De hecho. por lo que las consideraremos de momento como n una unica unidad en cuanto a programaci´n. Figura 3. por lo que nuestra aplicaci´n a a e o competir´ por cuantums de procesamiento con el resto de servicios del sistema operaa tivo.3: Esquema para la ejecuci´n de un programa en las unidades vectoriales o El Sintetizador Gr´fico (GS) a La programaci´n del sintetizador gr´fico siempre se muestra de forma relativao a mente indirecta. todo lo relativo al sistema operativo linux que tenemos ejecut´ndose en la m´quina se ejecuta en ´ste procesador. Este hecho conlleva tambi´n a que la ejecuci´n de un prograo e o ma en dicho procesador sea inmediato. no es un procesador e de prop´sito general. junto al sintetizador gr´fico. con el que generamos el c´digo objeto para luego cargarlo en la unidad vectorial. b´sia camente se trata del mismo dise˜o. La forma de ejecutar un programa en la unidad vectorial difiere bastante de la forma explicada para el procesador central.3. ya que la carga del programa en la memoria de la unidad vectorial se debe hacer mediante instrucciones del procesador central. los elementos m´s a a espec´ ıficos de la arquitectura de la consola. Unidades Vectoriales (VU0 y VU1) Este tipo de unidades conforman. como ya veremos o posteriormente. No hay una e o a programaci´n ((real)) tal y como sucede con el MIPS o las VU. o u es necesario el uso del procesador principal para poder ejecutar algo en la unidad vectorial. y no ejecuta ning´n fragmento del sistema operativo. donde se hacen las distinciones oportunas a la hora de explicar las instrucciones que posee y los modos de funcionamiento disponibles. simplemente se le env´ ´rdenes ıan o desde la VU1 o desde el EE. Al contrario que ´ste. La Figura 3. en las que cargamos un o . Aunque sus caracter´ ısticas difieren. ya que no se programa como tal. Como mencionamos anteriormente. y ´sta realiza su funci´n de forma autom´tica.

para ver lo que podemos usar y lo que tenemos que hacer desde cero. para poder obtener la imagen a dibujar. Distribuci´n en las unidades o Debemos distribuir las tareas que necesitamos implementar entre las unidades que queremos usar. Siguiendo los detalles mostrados en la Figura 3. Si no tuviera suficiente potencia para dicha tarea. ya que ogg vorbis corresponde a dos conceptos distintos: mientras que vorbis hace menci´n al codec de audio en s´ o ı.1.5. El sintetizador se limita a recibir una serie de paquetes gr´ficos llamados ((GIF tags)). determinamos que para la decodificaci´n o de ogg vorbis usaremos el procesador principal.4: Criterio a seguir para la distribuci´n inicial de las tareas o En el ap´ndice correspondiente a ogg vorbis se detalla todo lo referente a dicho e formato. 3.2. que contiene el sonido codificado. distribuir´ ıamos la carga entre las unidades vectoriales. Ahora debemos pensar en el procesamiento de audio que haremos para obtener unos patrones dependientes del sonido moment´neo a y que sean representables de forma gr´fica. Si desea m´s detalles sobre su funo a cionamiento o m´s informaci´n sobre los t´rminos usados. Estos ((GIF tags)) est´n compuestos de una geometr´ y unos atributos a nivel a ıa de v´rtice.54 CAP´ ITULO 3. Al a final nos hemos decidido por hacer un espectrograma del sonido. Figura 3. ogg hace referencia a la encapsulaci´n de las tramas o de vorbis en el fichero. lista para ser enviada al dispositivo de sonido.2 y el uso normal de las unidades mostrado en la Figura 3. ı Teniendo en cuenta las tareas consideradas en la Figura 1. para su almacenamiento f´ ısico y su transmisi´n. Aqu´ simplemente mostraremos el esquema de las tareas que necesita realizar ı la decodificaci´n. Implementaci´n del proyecto o Decodificaci´n de sonido o En la p´gina WEB de Xiph [23] podemos encontrar una implementaci´n realizada a o para sistemas unix/linux. a a Tras todo este proceso. Disponemos de dos bibliotecas. debe referirse al ap´ndice a o e e mencionado. aunque el hecho de que el algoritmo de decodificaci´n no sea computacionalmente muy pesado y el o procesador principal del que hablamos es un procesador a 300MHz hace que pensemos que ser´ m´s que suficiente para dicha tarea. En lugar de ogg o . DESARROLLO DEL PROYECTO programa y vamos interactuando con los datos que recibimos.4. as´ como lo que necesitamos aprender a hacer en cada una de ellas.1. con los atributos determinados. que usa el hardware inherente a dicha unidad y los transforma en pol´ e ıgonos 2D proyectados en la pantalla. 3. obtenemos un buffer con la salida de audio.1. y realiza su salida en a pantalla. representado en la Figura 3.2. 3.1.4. distribuiremos las tareas pertinentes siguiendo el criterio mostrado en la Figura 3.

IMPLEMENTACION DEL PROYECTO 55 Figura 3.5: Tareas de las que se compone la decodificaci´n de Ogg Vorbis o .´ 3.2.

Contiene tambi´n otra e biblioteca a m´s alto nivel denominada vorbisfile. Nos centraremos principalmente en el fichero de ejemplo de la biblioteca libvorbisfile. el n´mero de bytes de audio PCM decodificado.vorbis. extra´ ıdas de la documentaci´n online de la biblioteca.com/download_unix_ o 1. disponible o en la direcci´n http://www. seg´n el tama˜o de muestra u u n para cada valor. album de la canci´n y dem´s informaci´n de semejante tipo va o o a o almacenada como comentario del fichero. Esta biblioteca es requisito para la biblioteca de vorbis. por ejemplo. Para m´s informaci´n sobre la forma de a o almacenar estos comentarios y el formato usado.0/examples/ encontramos unos peque˜os programas de n ejemplo que sirven de demostraci´n del uso de la biblioteca para cargar y decodificar los o ficheros ogg vorbis. el nombre del autor. o Como es com´n en los productos desarrollados para linux. nuestra primera opci´n es probar a compilarlo o para nuestra arquitectura MIPS. Una vez instalada. En el fichero vorbisfile example. Esta estructura contiene informaci´n relativa a la versi´n de ogg vorbis. para comprobar si la biblioteca es totalmente portable a nuestra m´quina o si por el contrario necesitamos reprogramar a ciertas partes del c´digo para hacer que se pueda ejecutar sin problema. La decodificaci´n en el buffer genera u o un entrelazado en los canales como se muestra en la Figura 3. simplemente tenemos u que instalar las dependencias necesarias y compilar el paquete. Por tanto.xiph.1.0. ambas disponibles en la direcci´n http://www. Realmente este entrelazado no hace m´s que facilitarnos la tarea a la hora de reproducir. en el directorio libvorbis-1. el n´mero de o o u canales y la frecuencia de muestreo.c podemos ver las siguientes llamadas principales a la biblioteca mencionada.psp: libogg: es una biblioteca que se encarga de la decodificaci´n del encapsulado o ogg.org/ogg/vorbis/doc/vorbisfile/reference. . entre otras. Procedemos a realizar la prueba inicial. y ser por tanto independiente de la arquitectura. Esta estructura contiene la informaci´n contenida en los comentao rios del fichero. el a˜o. ov info: devuelve la estructura vorbis info del fichero especificado. el dispositivo de salida espera este mismo formato a como datos de entrada. Datos como el t´ ıtulo de la canci´n. a ov read: esta funci´n es la funci´n principal de la decodificaci´n en s´ Devuelve o o o ı. o n estilo de canci´n. se puede consultar el ap´ndice e destinado al formato ogg vorbis.56 CAP´ ITULO 3. y el n´mero de canales. que presenta una capa de absa tracci´n mayor sobre el fichero ogg vorbis. acompa˜adas de una breve sinopsis n de su funcionamiento.6. ofreciendo un interface al programador o m´s sencillo en cuanto a manipulaci´n del mismo. a o Al estar implementado para un linux en un lenguaje portable como C. libvorbis: es la biblioteca encargada de decodificar el audio contenido en las tramas vorbis encapsuladas en un flujo ogg de datos. que es donde viajan las tramas vorbis. DESARROLLO DEL PROYECTO se podr´ usar uno distinto para realizar una transmisi´n streaming de vorbis mediante ıa o red. ya que a como veremos m´s adelante. Xiph ha desarrollado una biblioteca para cada uno de ellos. Estos dos ultimos par´metros ´ a son los que nos interesar´n a nosotros. o html: ov comment: devuelve un puntero a la estructura vorbis comment para el fichero especificado. y probar alguno de los programas de ejemplo que traen las bibliotecas.

y la Figura 3. ordenados seg´n su ocupaci´n de CPU. Para ello nos basta mirar el uso de la CPU por parte del programa de ejemplo comentado.groupsys. tan solo queda cerciorarse de que el procesador MIPS ser´ lo suficientemente potente como para decodificar el a fichero. para hacernos una idea de los recursos computacionales que emplea en la decodificaci´n. Este programa genera una tabla en la que muestra una lista de procesos activos.6: Entrelazado de los canales ov clear: con esta funci´n cerramos el fichero y limpiamos los buffers auxiliares o de la decodificaci´n.´ 3. Por tanto. o Una vez probado el ejemplo y viendo que compila. lo que supone una carga suficientemente baja para no tener que realizar a priori ninguna optimizaci´n del c´digo proporcionado por Xiph. o o Figura 3. Como ya hemos comentado varias veces. Para esta labor nosotros usaremos el a afamado programa top. IMPLEMENTACION DEL PROYECTO 57 Figura 3.2.7: Un ejemplo de la salida mostrada por top .com/top/. toda la informaci´n que el ´ o sistema operativo sea capaz de proporcionar sobre los procesadores que usa se referir´n a unicamente a dicho procesador. ya que podemos emplear una utilidad cualquiera que muestre el o uso de CPU por proceso para saber de forma aproximada qu´ porcentaje del procesador e est´ siendo usado por cada una de las tareas. Esto nos supone una ventaja para lo que pretendemos ´ realizar a continuaci´n.7 muestra un ejemplo de su salida. Nuestra aplicaci´n de ejemplo ocupa aproximadamente el 23 % de los recursos computacionales o del procesador. Se puede encontar en http: u o //www. el procesador central es o unico encargado de ejecutar el sitema operativo.

Con la informaci´n obtenida del libro Linux Multimedia Guide [49] en su o versi´n WEB. y de la informaci´n proporcionada por 4Front Technologies [1] sobre o o la programaci´n [47] de OSS (Open Sound System). o Esta circunstancia supone una ventaja. 3. el kit de linux abstrae algunas unidades de la consola. a Como podemos leer en las anotaciones que se realizan para la reproducci´n de o varios canales.58 CAP´ ITULO 3. tal y como aparece en la parte inferior de la Figura 3. Otra raz´n es o o la dependencia de bibliotecas externas. DESARROLLO DEL PROYECTO 3. y no tenemos que cambiar nada. n . Al ser programaa ci´n general de linux podemos acelerar el desarrollo del prototipo realiz´ndolo para o a PC. Procesamiento de audio a Ahora es momento de implementar el sistema gr´fico. Por tanto. Antes de representar gr´fia a camente el sonido debemos procesar los datos PCM que obtenemos de la decodificaci´n o de ogg vorbis y transformarlos en una serie de valores utiles para su representaci´n en ´ o pantalla. Normalmente esto implica una programaci´n a un nivel m´s bajo de lo que o a supondr´ emplear una API de mayores caracter´ ıa ısticas y abstracci´n. proporcionando una total abstracci´n de su hardware al programador. y todo est´ muy documentado. lo pasamos a la PlayStation2 para cerciorarnos de que funciona como hab´ ıamos previsto. la unidad encargada de dicha tarea es el procesador de sonido. El procesador de sonido es una de ellas. con todas las o facilidades que ello conlleva. ya que disponemos de nuestro entorno de programaci´n completo. y enviar el flujo de datos obtenido tras la decodificaci´n. Modelo gr´fico. por lo que se requiere un orden espec´ ıfico para poder configurar todos los par´metros a valores personalizados. nuestro siguiente o objetivo es la reproducci´n del sonido decodificado.2. necesitamos uno lo m´s simple y r´pido posible. Reproducci´n de sonido o Una vez solventado el tema inicial de decodificaci´n de audio. Toda interacci´n con este procesador se realiza a trav´s del dispositivo de sonido del o e sistema linux (/dev/dsp) como si se tratara de la tarjeta de sonido de un PC normal. pues aunque no tenemos experiencia programando sonido desde linux. debemos ahora prograo mar el dispositivo de salida. Los pasos a seguir para el funcionamiento del dispositivo de audio se representan en la Figura 3. Determinamos antes que vamos a realizar un espectrograma de la se˜al. Estamos intentando minimizar la cantidad de aplicaciones necesarias para la ejecuci´n de nuestro programa. Esto se debe a que. Nosotros no necesitamos un sistema muy elaborado o de sonido. impidiendo su acceso directo. Es decir. ning´n docuu mento de los proporcionados por Sony trae nada referente a dicho procesador. o Como ya mencionamos.6. Por tanto. El orden ha de ser ese. El programa funciona perfectamente en la consola tal y como esper´bamos. la informaci´n que se puede encontrar sobre este punto o en INTERNET es bastante amplia. creamos una aplicaci´n prototipo o o que genera una salida por el dispositivo de audio. con el menor retardo asoa a ciado.8. la programaci´n del procesador de sonido lo realiza un m´dulo del n´cleo de o o u linux. Tras modularizar ambas partes en audio y fich. capaz de producir sonido digital 3D usando AC-3 y DTS. como ya dijimos anteriormente. En el portal linux.3. Sin embargo.2. por lo que podemos dar por finalizada la primera parte del desarrollo a inicial sobre el procesador central MIPS.2. debe mandarse entrelazado cada canal. pues la configuraci´n de un par´metro hace que otro par´metro vuelva a tomar o a a su valor por defecto. decidimos o programar directamente el sonido usando con el driver que proporciona el n´cleo del u sistema.com [4] podemos ver un art´ ıculo [51] comentando las distintas alternativas de programaci´n de sonido que hay en el mercado en cuanto a programao ci´n de sonido en linux se refiere.

dividiendo fraga n mentos del sonido en trozos en los que analizaremos las frecuencias presentes. IMPLEMENTACION DEL PROYECTO 59 Figura 3. La Figura 3.2.9 muestra una se˜al representada mediante su onda y su espectro n en frecuencias en la parte inferior. La onda que obtenemos al decodificar est´ en el dominio a .´ 3. Figura 3. para realizar un estudio estad´ ıstico de las frecuencias principales que est´n presentes en caa da trozo.8: Orden de configuraci´n del dispositivo o Con espectrograma nos referimos al an´lisis espectral de la se˜al.9: Ejemplo de espectograma (abajo) y se˜al de origen (arriba) n Lo primero que debemos hacer para poder contabilizar las frecuencias de la canci´n o es un cambio de dominio.

Si quiere profundizar m´s.3. Para una breve introducci´n sobre los elementos que conforman un sonido. ıa Figura 3. denominados par´metros.60 CAP´ ITULO 3. En dicha ecuaci´n vemos que o o o la transformada de Fourier es una operaci´n lineal. El dominio m´s ((frecuente)) con el que se trabaja en sonido para la reproducci´n a o es el del tiempo. En la Figura 3. ya que representar´ a ıa el estado de excitaci´n de la se˜al en un tiempo determinado. Tenemos los valores que toma la se˜al a lo ´ n largo del tiempo de forma discretizada. que es el que n nos proporciona informaci´n util para nuestro prop´sito: caracterizar el fragmento de o ´ o sonido que decodificamos. de la Universidad de Texas. debemos convertir nuestra se˜al al dominio en frecuencia. n .10 se puede ver la diferencia conceptual existente entre ambos dominios.10: Se˜al en el dominio en tiempo y en el dominio en frecuencia n Transformada de Fourier Un proceso f´ ısico puede describirse tanto en el dominio del tiempo como en el dominio de la frecuencia. el domio a nio en frecuencia es mucho m´s util para determinados campos. un dominio que no nos es util. Es la forma m´s natural de pensar en el sonido. Normalmente se entienden ambas formas como dos representaciones distintas de una misma funci´n. ya que permite una a ´ manipulaci´n mucho m´s c´moda de la se˜al. por una serie de valores. que ser´ reflejado en la o n a vibraci´n que recibir´ el altavoz. Para pasar del dominio del tiempo al dominio de la frecuencia necesitamos realizar una transformada de Fourier [52] a la se˜al. Es capaz de extraer la frecuencia del o a o n sonido. Sin embargo. Aqu´ veremos una n ı explicaci´n sencilla sobre la transformada de Fourier. La transformaci´n de la suma de o o dos funciones es igual a la suma de las transformaciones de cada se˜al por separado. obviando el resto de factores que conforman la textura del sonido. viendo la representaci´n de varios tipos de se˜al tanto en tiempo como en frecuencia. Podemos definir la o relaci´n entre ellas como aparece en la ecuaci´n (3. o n Por tanto.1). puede visitar la p´gio a na del Centro de Estudios Avanzados en las Artes [41]. le o a recomendamos que lea la bibliograf´ anteriormente citada. reproduciendo dicho sonido. Podea mos tener h(t) o bien H(f ) si estamos refiri´ndonos a la expresi´n gobernada por e o un par´metro que depende del tiempo (dominio en tiempo) o de un par´metro que a a depende de la frecuencia (dominio en frecuencia). como representamos en la Figura 1. DESARROLLO DEL PROYECTO del tiempo.

. . Cualquier componente en frecuencia fuera de dicho rango es transladado a ese rango al muestrear. como mostramos en fn ≡ n .. La otra raz´n ocurre cuando se muestrea n ıda o una se˜al sin cumplir el teorema anterior.4) Con N valores de entrada. 1.1) h(t) = −∞ H(f )e−2πif t dt Transformada de Fourier sobre un conjunto de datos discretos En la mayor´ de las ocasiones. 2. calcularemos el valor de H(f ) para dichos puntos concretos. dada por la expresi´n o fc ≡ 1 2∆ (3.2) Como sabemos. . obtenemos la relaci´n (3. Supongamos que tenemos N muestras. o llamada transformada discreta de Fourier. . para cualquier ∆ existe una frecuencia especial.6). por lo que en lugar de calcular H(f ) en todo el rango de f entre −fc y fc . Como puede apreciarse. denominada frecuencia cr´ ıtica de Nyquist. . Una de ellas es por el teorema de muestreo.6) . N −1 Hn ≡ k=0 hk e2πikn/N (3. Si usamos ∆ para denotar el intervalo de tiempo entre muestras consecutivas. .. 0. N∆ n=− N N . como era la escala temporal u a ∆.2). tk ≡ k∆.2. . N − 1 (3. −1. 2 2 (3. la funci´n h(t) est´ muestreada a intervalos espaıa o a ciados en el tiempo. que viene a determinar la frecuencia m´ ınima a la que hay que muestrear una se˜al para poder ser reconstru´ sin error. fc . −2. a Transformada Discreta de Fourier Podemos estimar la transformada de Fourier desde un n´mero finito de puntos u muestreados de la curva original. 3. no depende de ning´n par´metro dimensional. 2. El o inverso de ∆ se denomina tasa de muestreo. k = 0. −3. . El efecto obtenido es que toda la densidad de n potencial espectral que cae fuera del rango −fc < f < fc se desplaza de forma err´nea o a ese rango.. . IMPLEMENTACION DEL PROYECTO +∞ 61 H(f ) = −∞ +∞ h(t)e2πif t dt (3. La unica opci´n contra este efecto es conocer el rango de la ´ o funci´n a muestrear y muestrear a la suficiente velocidad para proporcionar al menos o dos puntos por ciclo de la frecuencia m´s alta presente. la secuencia de valores muestreados se muestra en la ecuaci´n (3. . a la que denotaremos como Hn . (3. hn = h(n∆) n = .3) Esta frecuencia es importante por dos razones.5) Una vez aproximada la integral por una suma discreta. solo obtendremos N valores independientes a la salida.´ 3. como expresamos en hk ≡ h(tk ). 1. .

Si muestreamos con el intervalo ∆ como aparece en (a).9) Tenemos un vector de hk multiplicado por una matriz cuyo (n. la transformada de Fourier (c) est´ definida entre ±fc .5). La transformada discreta de Fourier tiene las mismas propiedades de simetr´ que la transformada continua de fourier.11: La funci´n original (a) es distinta de cero en un intervalo T de tiempo. pero tiene o amplitud en todas sus frecuencias. La potencia fuera de a ese rango se desplaza a dicho rango. o Su transformada de Fourier (b) no tiene limitaci´n por ancho de banda.8) Hn = k=0 hk W kn (3. ıa Transformada R´pida de Fourier (FFT) a Si analizamos la carga computacional que supone calcular la transformada discreta de Fourier para N puntos. Dicha multiplicaci´n produce un vector o .7) donde fn viene dada por (3. DESARROLLO DEL PROYECTO Figura 3. podr´ ıamos llegar a la conclusi´n de que. definiendo W como o W ≡ e2πi/N podemos expresar (3.6) como N −1 (3. k)-´simo elemento e es la constante W elevado a la n × k potencia. La relaci´n entre la transformada discreta y la transformada cont´ o ınua cuando las vemos como muestras de una funci´n cont´ o ınua muestreada a un intervalo ∆.62 CAP´ ITULO 3. puede escribirse como H(fn ) ≈ ∆Hn (3.

hay una transformada de un punto que es simplemente o uno de los n´meros de entrada fn u eoeeoeo···oee Fk = fn para alg´n n u (3.12). y sustituir e = 0 y o = 1. subdivisi´n hasta que tengamos transformaciones de logitud 1. En 1942. y combinamos parejas adjacentes de parejas para obtener transformadas de cuatro puntos.10) N/2−1 = j=0 e2πijk/(N/2) f2j + W k j=0 e2πijk/(N/2) f2j+1 e o = Fk + W k Fk Lo bueno de este lema es que puede usarse recursivamente. podemos hacer la misma reducci´n o e para Fk . La prueba es La demostraci´n es la siguiente: o N −1 Fk = j=0 e2πijk/N fj N/2−1 N/2−1 = j=0 N/2−1 e 2πi(2j)k/N f2j + j=0 e2πi(2j+1)k/N f2j+1 (3. cada una de longitud N/2.11. Supongamos que cogemos el vector u a original de valores fj y lo reordenamos en su orden inverso de bits. Una tiene los puntos pares y otra los puntos impares de la original. Danielson y Lanczos probaron que una transformada discreta de longitud N puede ser reescrita como la suma de dos transformadas discretas de Fourier. La transformada en ese o caso es simplemente la operaci´n identidad que copia una entrada en una salida. Sin embargo.11) El siguiente paso es determinar qu´ valor de n corresponde a qu´ patr´n de e y o en e e o la ecuaci´n 3. As´ podemos a ı. Para o cada patr´n de log2 N de e y o. obteniendo un vector ordenados seg´n el inverso de j. Por razones de sencillez. transform´ndolo en su N/4 entrada impar y N/4 entrada par. La soluci´n es invertir la secuencia de e y o. se puede calcular en Θ(N log2 N ) con el algoritmo llamado transformada r´pida de Fourier a (FFT). y son log2 N combinaciones. IMPLEMENTACION DEL PROYECTO 63 cuyas componentes son las Hn . Cada combinaci´n conlleva un orden de N o operaciones. u la aplicaci´n recursiva del lema de Danielson-Lanczos es extraordinariamente sencilla. Habiendo reducido el e o proglema de calcular Fk al de calcular Fk y Fk .2. supondremos simpre que N es una potencia de 2. y as´ hasta la primera y segunda mitad de todo el conjunto de ı datos se combine en la transformada final. ee eo definir Fk y Fk como la transformada discreta de Fourier de los puntos que son los par-par y par-impar en las sucesivas subdivisiones de los datos. u Por tanto.´ 3. As´ podremos aplicar esta ı. lo que hace un total de N log2 N . . parece que la transformada discreta de Fourier es de Θ(N 2 ). como muestra la Figura (3. Esta multiplicaci´n requiere N 2 multiplicaciones como plejas. y un menor n´mero de operaciones para generar las potencias de W necesarias. Sobre este vector. o o y el n´mero formado ser´ el valor en binario de n. o Podemos combinar parejas adjacentes de puntos para obtener transformaciones de dos puntos.

Una vez m´s rea o o a currimos al programa XMMS [46]. recurrimos a una implementaci´n usada para algo o similar a nuestro prop´sito. que ser´ necesario reimplementar en ensamblador o o a para la unidad vectorial VU1. Sin embargo. DESARROLLO DEL PROYECTO Figura 3. para definir el algoritmo de espectrograma. . Por contra. Esto es posible dadas las circunstancias actuales: (i) la parte de decodificaci´n. Podemos encontrar gran cantidad de implementaciones en la WEB. y disponemos de diversas utilidades que facilitan la tarea de desarrollar y depurar c´digo en el mismo. reproducci´n y transformaci´n al dominio en frecuencia se o o o realizar´n en el procesador central MIPS de la consola. (iii) la indepeno dencia del c´digo de visualizaci´n.12: Reordenaci´n de un vector (longitud 8 en este caso) por inversi´n de bits. la o consola no est´ concebida para ser una plataforma de desarrollo directamente. dista mucho del repertorio del que dispone un PC. pensamos buscar una implementaci´n fiable y suficientemente opo timizada para evitar sorpresas futuras al encontrar errores durante la depuraci´n dadas o por un fallo en la implementaci´n del algoritmo. con una representaci´n en calidad de prototipo bajo el estandard gr´fico o a OpenGL [33]. (b) en un vector Implementaci´n e integraci´n de la FFT o o Dada la importancia de una implementaci´n optimizada y la gran difusi´n de este o o proceso por doquier. nuestra u plataforma de desarrollo habitual es el PC. pues la velocidad de la FFT es cr´ ıtica en nuestro procesamiento visual. que contiene en su c´digo [11] unas funciones que o transforman los datos de sonidos decodificados a su espectro de frecuencias mediante una transformada r´pida de Fourier. bibliotecas [56] completas incluso. Esta decisi´n se toma por diversas razones. o o (a) entre dos vectores.64 CAP´ ITULO 3. Las razones son principalmente: N´mero de herramientas disponibles: como comentamos anteriormente. y a aunque la cantidad de herramientas disponibles no es despreciable. as´ como la creaci´n de un innecesao ı o rio cuello de botella. que supoo nen una mayor facilidad y rendimiento del desarrollo de esta parte. con el prop´sito de aislar o los errores posibles encontrados. decidimos realizar una implementaci´n de prueba aparte o de la consola. (ii) el c´digo referente a cada a o uno de los pasos anteriores es c´digo C portable entre plataformas. a Llegado este momento. entendiendo que es una implementaci´n suficientemente o o v´lida para nuestra aplicaci´n al ser usada para prop´sitos similares.

El primer paso consiste en escalar el rango de valores que obtenemos de la FFT a un rango que nosotros podamos manipular. tener un n´mero de muestras o u N potencia de dos facilita mucho la aplicaci´n de las propiedades de recursividad. lo que repercute en una gran sencillez a la o a hora de desarrollar un prototipo gr´fico en el que mostrar un avance del efecto a producido por el algoritmo de caracterizaci´n de sonido. debemos agrupar valores de frecuencias en conjuntos. podemos expresar las bandas de frecuencia λ como f λ= . Teniendo una medida sobre la aparici´n de cada banda o de frecuencias considerada. Dado o a nuestra inexperiencia con este hardware espec´ ıfico. k ≡ cte (3. Como comentamos en la itroducci´n a la FFT. podr´ ı.12) k siendo k el valor que determina el ancho de cada ((banda de frecuencia)). o . o lo que hace que sea m´s eficiente de implementar. hemos sido realistas al pensar que el n´mero de errores de programaci´n en este apartado ser´n numerosos y u o a su desarrollo ser´ lento. a La intenci´n inicial es obtener un gr´fico de bandas en el que quede representado o a el espectro de la se˜al. a a Por todo esto. Aplicando ese algoritmo obtenemos una salida en frecuencia. IMPLEMENTACION DEL PROYECTO 65 Familiaridad con la API de OpenGL: poseemos cierta experiencia con el sistema de programaci´n gr´fico OpenGL. provocando una saturaci´n en ellas y una carencia de valores en las restantes. Lo primero que necesitamos hacer es convertir los datos de salida de la FFT para nuestro uso. El rango completo de valores obtenido por la FFT es demasiado grande para poder clasificarlo directamente en ((bandas de frecuencia)). esto es. As´ como muestra la Figura 3. El tama˜o concreto para o n dicha implementaci´n es de 512. Primero describiremos el efecto que pretendemos obtener. Nos referimos a la posibilidad de desarrollar el a a algoritmo que generar´ a su salida una serie de propiedades que usaremos para a representar gr´ficamente un patr´n que identifique las caracter´ a o ısticas del sonido sin tener que lidiar de momento con el hardware de dibujo de la consola. proporcional al valor de a dicho conjunto. y desligar completamente los errores de programaci´n o del mismo a los errores de programaci´n relativos al apartado gr´fico. preferimos aislar todo lo posible los errores de otras fuentes para evitar errores en cadena. Como disponemos de un n´mero bastante limitado de barras n u para representar un espectro suficientemente amplio de frecuencias. o Independencia del hardware y la programaci´n nativa de la consola: este punto o quiz´s sea el m´s importante. Los valores de salida deben ser tratados para poder o clasificarlos en los conjuntos de datos que usaremos nosotros a modo de barras.´ 3. pues supone la etapa de aprendizaje m´s dura a priori. La implementaci´n usada en el a o XMMS hace uso de esta propiedad. Si notamos a las frecuencias como f . podemos representar proporcionalmente a dicha medida cada una de las bandas. que debemos adaptar a nuestros intereses. Si hici´ramos una divisi´n lineal. Tengamos en mente que aproximadamente el 80 % de los valores pertenecen al primer 15 % del rango de abscisas. Este valor contabilizado ya supone una medici´n en bruto que nos es util a la hora de o ´ definir un espectro de bandas. Con esto conseguimos comprobar qu´ resultado se a e obtiene en el algoritmo.2. como era l´gico suponer. el sintetizador gr´fico. Iremos contabilizando el n´mero de apariciones u en cada ((conjunto de frecuencia)) para un determinado fragmento de tiempo. ıamos dibujar una altura diferente a una primitiva (en este caso un tri´ngulo).13. en las primeras barras concentrar´ e o ıamos casi todos los valores. antes de entrar en los detalles del procesamiento de c´lculo.

Para ello. 1]. a o o ıa Es decir. 1024]. Primero realiza una ra´ cuadrada para eliminar parte de su condici´n de no linealidad.66 CAP´ ITULO 3. y la duraci´n de las notas. que se ajustar´ a medida o a a que avanza la canci´n. para todo α ∈ [0. DESARROLLO DEL PROYECTO Figura 3. vamos a dotar a nuestro a prototipo con otro elemento que le dotar´ de un complemento visual. Detecci´n de la cadencia de la canci´n o o Antes de implementar el apartado gr´fico en la consola. o 3. tendremos una detecci´n din´mica de la cadencia. para normalizar los valores a un espectro m´s lineal antes de distribuirlos a en bandas haremos exactamente lo mismo que hace el programa XMMS [46]. La finalidad del par´metro τ es fijar la cota superior de a frecuencia que ser´ procesada en la representaci´n gr´fica. para lo cual puede tomarse como base el valor o de una ((redonda)). considerando que cualquier frecuencia contenida en dichas bandas pertenece a un ((conjunto de frecuencia)) Por tanto.2. necesitamos definir unas u ((bandas de frecuencia)). donde queda definido como la relaci´n que existe o entre el transcurso del tiempo medido en sus propias unidades (por ejemplo. Una definici´n de ritmo la o e o o encontramos en El liceo digital [35]. 1] para los valores comprendidos en el rango [0. La cota τ de 1024 que hemos empleado aqu´ no es m´s que un par´metro ı a a obtenido de forma emp´ ırica. siendo δ > N . Esta o subida se detetar´ en relaci´n a un hist´rico de la energ´ calculada anteriormente. Queremos que a nuestra aplicaci´n reaccione tambi´n al ritmo de la canci´n. . e iremos mostrando un efecto visual cada vez que detectemos la subida de intensidad en la canci´n. Un valor de salida de la FFT a o a superior a τ ser´ ignorado. Nosotros a normalizaremos la escala de valores a [0. caer´ en a u ıa un ((conjunto de frecuencia)) Ψδ . Por tanto. le corresponde un ((conjunto de frecuencia)) Ψβ .4.13: Para poder considerar un espectro de frecuencia suficientemente ´mplio a con un n´mero bastante reducido de barras a representar. y luego ız o divide por 256 para mover el dominio de valores a un rango m´s reducido. La ventaja de tener una detecci´n din´mica es la posibilidad de o o a poder distinguir las variaciones en la intensidad de la se˜al a´n cuando la energ´ de n u ıa toda la canci´n ha aumentado o disminu´ o ıdo. ya que siendo N el n´mero de barras disponibles. segundos o sus fracciones). α una salida cualquiera de la FFT tras la normalizaci´n. tal que β = α × N . detectaremos la cadencia de la misma.

Si obtenemos que > η × ξ. ıa o ıa Deseamos registrar un hist´rico de energ´ de aproximadamente un segundo de duo ıa raci´n.5. 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. Sean α y β los buffers de los canales derecho e izquierdo. un buffer de longitud 1024 muestras. desplazamos el buffer E un lugar a la derecha para dejar espacio a la nueva muestra.2. lo que implica que necesitamos 44100/1024 ≈ 43 valores. desechando el valor antiguo. Como hemos dicho.2. ya que aislamos la componente a o media de energ´ ıa. Teniendo una versi´n de prototipo minimizada en la consola. donde η es una constante umbral de sensibilidad. Todo o el desarrollo independiente del hardware de la m´quina se ha acabado. IMPLEMENTACION DEL PROYECTO 67 Gracias a la utilizaci´n de un hist´rico adaptativo con el que ir comparando la evoo o luci´n de la canci´n evitamos la necesidad de definir emp´ o o ıricamente una cota superior de energ´ para la que determinar´ ıa ıamos que se produce un golpe de intensidad. con el consiguiente problema producido por la saturaci´n posible en los pasajes muy en´rgio e cos. Reimplementaci´n del plugin gr´fico o a Antes de comenzar la programaci´n de las unidades vectoriales vamos a migrar el o prototipo a la consola. ya que supon´ demasiadas limitaciones en cuanto a lo ıan . Para ello no tenemos m´s que eliminar toda la parte a˜adida a n para la representaci´n. Tras realizar algunas pruebas para encontrar qu´ programa de ejemplo conten´ una estructura y e ıa unos requisitos m´s parecidos para nuestro prop´sito. Ahora solo debemos comprobar si se produce o no un golpe de ritmo. lo que conlleva o u a unas 44100 muestras por segundo. en concreto el algoritmo m´s simple de los que describe en su art´ a ıculo [42]. calculamos la energ´ local media haciendo ıa ξ= 1 × (E[i])2 43 i=0 43 (3. cada buffer que decodificamos de audio contiene 1024 muestras. Supondremos que la m´sica est´ muestreada en calidad CD. y las cadencias detectadas. o o comenzamos a construir la base sobre la que implementaremos la aplicaci´n final. solo resta comparar con η × ξ. o Cuanto mayor sea η. podemos decir que hemos detectado ıa un golpe de ritmo. Al ser din´mico. descartamos las demos de la VU a o Demo Coding Contest [15]. Por tanto. o Como hemos dicho. Para ello. Emp´ ıricamente se demuestra que un valor η = 1. Nosotros emplearemos un algoritmo de detecci´n de cadencia descrito por Fr´d´ric o e e Patin. En la Figura 3. aplicando las optimizaciones pertinentes.14) Tras calcular ξ. m´s variaci´n de la energ´ se requiere para detectar el cambio a o ıa como ritmo. B´sicamente se trata de calcular la energ´ a ıa del buffer que consideramos como sonido en cada momento.13) Calculamos la energ´ local media ξ con el buffer del hist´rico de energ´ E. Apilamos pues la nueva energ´ ıa en E[0].´ 3. y solo resta la a parte que implica una programaci´n del hardware. podemos calcular la energ´ como ıa i0 = stereo = α + β = k=i0 (α[k]2 + β[k]2 ) (3. evitamos la posible saturaci´n. Este valor ajusta la sensibilidad global del algoritmo a la detecci´n de golpe de ritmo. 3 es acertado en la mayor´ de los casos.14 hemos representado un fragmento de una canci´n o en su representaci´n de onda. o 3.

68 CAP´ ITULO 3. Esta aplicaci´n de ejemplo dibuja un cubo con texturas en sus caras e iluminaci´n. no se adapta a nuestro modelo de aplicaci´n. y no para muestras concretas. que ´ o se ejecutaban unicamente en la VU1. y o o permite controlar el ´ngulo de cada uno de los tres ejes con el mando de control de la a consola. o Por el contrario. Por tanto.14: De una onda (rojo) se puede estimar los golpes de ritmo (verde). Analizaremos a continuaci´n las partes m´s importantes del programa plantilla por o a . Aqu´ heı mos representado todo el buffer de 1024 muestras como golpe de ritmo. a cualquier parte correspondiente a nuestra aplicaci´n. Aqu´ solo vamos a explicar lo que necesitamos para formar lo que o ı se conoce como ((plantilla)) o ((esqueleto)). las demos pertenecientes a la biblioteca libps2dev [13] s´ poseen ı una estructura m´s similar a la que nosotros pretendemos desarrollar. Se prescindir´n de las partes correspondientes al o a prototipo que desarrollamos anteriormente. El programa cargador simplemente se encargaba ´ de cargar las distintas demos en la VU1. Su dise˜o inicial consist´ en disponer de o n ıa un programa en el MIPS. La aplicaci´n de a o demostraci´n demo3d proporciona un grado de interacci´n entre las unidades vectoriao o les y el procesador principal que podremos emplear como base para nuestro programa. cuya unica misi´n era la de ser un cargador de las demos. DESARROLLO DEL PROYECTO Figura 3. Desarrollo de la base para el MIPS En este apartado vamos a describir los elementos necesarios que conforman la configuraci´n de lo que es la consola. ya que calculamos la existencia o no de cadencia para cada uno de ellos. es decir. y se refiere al conjunto de sentencias m´ ınimas que hay que escribir en cada uno de los programas para su correcto funcionamiento. que intercomunicaci´n MIPS ⇔ VU se refiere.

) como a formato (PAL. y crearemos cada uno de los buffers e de pantalla a utilizar. indicando la finalidad de dichas l´ ıneas. (g zbits == 0) ? 0 : PS2 GS ZGREATER. Como sabemos. a e e comenzamos la visualizaci´n gr´fica. Primero confia guramos el sintetizador gr´fico con una serie de par´metros que determinan el modo a a de v´ ıdeo a generar. a // abrimos el GS. 0x3f800000). g ff mode. // pasamos a modo grafico ps2 gs vc graphicsmode(). 1). g resolution. gp−>height. 0x80. NTSC.´ 3. IMPLEMENTACION DEL PROYECTO 69 fragmentos. .rgbaq = PS2 GS SETREG RGBAQ(0x00. 0x3f800000). g psm. Para ello hacemos uso de las llamadas que proporciona la biblioteca libps2dev. Despu´s configuraremos el doublebuffer. . 0x00. release(). lo que hacemos es cargar en memoria el c´digo objeto del programa a e o ejecutar en la unidad vectorial. g out mode.elf.elf".). // reseteamos el GS ps2 gs reset(0.clear1. O DATA PS2MEM). g vpu0 = ps2 vpu open(0). o a // clear back buffer ps2 gs put drawenv(&g db.rgbaq = PS2 GS SETREG RGBAQ(0x00. gp−>width. para continuar cuando la entidad gr´fica est´ lista. Tras ´sto. 0x00. 0x80. g refresh rate).2. la consola es apaz de generar distintos modos de v´ ıdeo. . VU0 y VU1 g fd gs = ps2 gs open(−1). En nuestro caso. tanto a resoluci´n (640x480. g zpsm. if (vfd == NULL) { perror("vpuobj_open"). . . 0x00. g vpu1 = ps2 vpu open(1).clear0. // definimos los dos buffers *( u64 *)&g db. y abrimos el sintetizador gr´fico (GS) y las dos unidades vectoriales (VU0 y VU1). 0x00. limpiamos el buffer y esperamos la sincronizaci´n con o el procesador principal.800x600. Tras ´sto. exit(1).giftag1). dicho fichero se llama basic. } Ahora realizamos una serie de pasos referidos al apartado gr´fico. Una vez definido lo anterior. next2k = ps2 gs set dbuff(&g db. o VGA. que pueden encontrarse en los ficheros fuente o asociados y no requieren de ninguna explicaci´n. g inter. o Lo primero que debemos hacer es abrir cada una de las unidades que vamos a usar. Se omiten las partes de declaraci´n o de variables y semejante tipo de c´digo. // cargamos el programa de la VU1 vfd = vpuobj open("basic. *( u64 *)&g db.

frame++. ps2 gs start display(1). y reanudamos el funcionamiento e del sintetizador gr´fico. ps2 gs wait finish(&g finish). y las unidades vectoriales. y en el c´digo del MIPS la hemos a o importado gracias a la macro IMPORT VPU SYMBOL.) { // detenemos el GS ps2 gs vc lock(). y una vez finalizados definimos el inicio del programa de la VU1 que vamos a ejecutar mandando mediante DMA la informaci´n necesaria. puede que se ejecute o no. Luego ir´ todo el procesamiento de datos que se desea realizar en ıa el MIPS. release). para lo que cerraremos primero el c´digo o objeto del programa de la VU1. Es decir. } El trozo que encontramos a continuaci´n corresponde a la secci´n posterior al bucle o o infinito. por lo que supondremos que dichas instrucciones s´ son ejecutadas salvo comportamiento an´malo del programa. // use ioctl ps2 dma start(ps2 vpu fd(g vpu1). tal y como se puede apreciar en el c´digo fuente completo. y terminaci´n err´nea. Depende de la forma de programaci´n del bucle. ı o o o Solo resta liberar los recursos tomados al inicio. odev = !ps2 gs sync v(0). cambiar el buffer sobre el que se dibuja (debido al uso de double a buffer que hacemos). La variable My dma start o est´ definida en el fichero ensamblador de la VU1. . ps2 gs swap dbuff(&g db. y el sintetizador gr´fico. ps2 gs vc enablevcswitch(acquire. ps2 gs close(). (ps2 dmatag *)My dma start). cada fotograma a o dibujado pasar´ por este bucle. Se limita a detener o el sintetizador gr´fico. vfd. a // bucle infinito for (. Su estructura es muy sencilla. ps2 vpu close(g vpu1). as´ que es en su interior donde debemos procesar la a ı informaci´n que queramos mostrar. Ahora entramos en lo que ser´ el bucle infinito de acci´n. o seg´n la forma de salir del bucle. frame). Aqu´ usaremos siempre que se permite la instrucci´n u ı o break para salir del bucle infinito. a // cerramos los recursos vpuobj close(vfd). ps2 vpu close(g vpu0). ps2 gs vc unlock(). .70 CAP´ ITULO 3. Solo resta incrementar el fotograma en el que nos encontramos o (para que el programa sepa decidir qu´ buffer mostrar). DESARROLLO DEL PROYECTO // wait clear done ps2 gs set finish(&g finish).

resta. la VU0 est´ unida directamente al EE. ya que son capaces de ejecutar dos instrucciones por ciclo de forma simult´nea. ambos cauces no son sim´tricos. Hay algunas instrucciones que solamente se pueden ejecutar en uno de ellos. no todas las a e instrucciones se pueden ejecutar en ambos.15: Arquitectura de las VU dentro del Emotion Engine Como se aprecia en el esquema. a FMAC: realiza suma. El resultado se o ız e almacena en el registro Q. Hay cuatro unidades para realizar eficientemente la operaci´n sobre veco tores de puntos en el plano (x. siendo lo que a se denomina su COP2 (su segundo coprocesador de c´lculo). La otra caracter´ ıstica principal que hace que sean tan diferenciadas en cuanto a uso viene determinada por las conexiones a las unidades circundantes. y. o u . 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.2. as´ como la carencia de una Unidad de Funciones Elementales (EFU) por ı parte de la VU0. aunque las componentes del vector (x. multiplicaci´n y suma-producto sobre n´meros floo u tantes. la memoria a de la unidad VU1 est´ conectada al GIF (el interface hacia el sintetizador gr´fico). y. z.´ 3.16. Sin embargo. IALU: realiza c´mputos sobre los n´meros enteros de 16 bits. Figura 3. Por contra. z. IMPLEMENTACION DEL PROYECTO Introducci´n a las unidades vectoriales o 71 Llega por fin el turno de la unidad vectorial. Como se puede apreciar en la Figura 3. LSU: controla la carga/almacenamiento de la memoria de la VU.15. w). Las unidades vectoriales poseen dos cauces de instrucciones. y a a los registros de la VU1 est´n ((mapeados)) a la memoria de la unidad VU0. FDIV: realiza divisi´n y ra´ cuadrada en aritm´tica flotante. Debe realizarse de 128 en 128 bits. Una visi´n a o m´s detallada de una unidad vectorial puede contemplarse en la Figura 3. w) pueden enmascararse para no ser alteradas. es decir.

0.72 CAP´ ITULO 3. A continuaci´n mostraremos una tabla resumen con o las caracter´ ısticas de cada unidad vectorial. logar´ ıtmicas y trigonom´tricas. solo est´ disponible en la VU1. Podemos pensar en ´l como e cuando programamos porciones de ensamblador empotrado en un c´digo C mediante o la primitiva asm.0[. para que sirva como gu´ para hacerse una ıa idea de las diferencias funcionales entre las unidades vectoriales de las que disponemos. DESARROLLO DEL PROYECTO Figura 3. u RANDU: es el generador de n´meros aleatorios en el intervalo ]1. u EFU: es la unidad de funciones elementales. la unidad VU0 se considera el COP2 del procesador central MIPS. Como se aprecia.16: Arquitectura de las VU en profundidad BRU: es la unidad encargada de controlar los saltos. 2. No hace falta enviar un programa aparte a la unidad vectorial como mostr´bamos en el esqueleto del MIPS. la unidad vectorial VU0 posee un o modo adicional de funcionamiento integrado en el MIPS. Ambas unidades son capaces de cargar un programa en su memoria y comenzar a ejecutarlos de forma independiente. Sin embargo. A este modo de funcionamiento se la conoce como micro modo de operaci´n. Los saltos condicionales se hace comparando uno o dos n´meros enteros. A esta forma de funcionamiento de la VU0 a se la conoce como macro modo. . e a Como hemos dicho. como exponenciales. lo que repercute en un modo de funcionamiento adicional del que el VU1 no es capaz.

o Como Sony es consciente de todo esto. (VI05++) VF16z Cada columna de instrucciones corresponde a una unidad de ejecuci´n.x MULAw. se eno carg´ de programar un preprocesador para la unidad vectorial. Cuando se debe esperar a la finalizaci´n de un cauce o para poder seguir computando. registros especiales: ACC. 16 registros enteros. VF01x. VF16x. VF16y. IMPLEMENTACION DEL PROYECTO Operaci´n o C´digo de opeo raci´n o Conjunto de instrucciones Micro modo (VU0/VU1) Opera como un procesador independiente Instrucciones LIW de 64 bits Instrucciones superiores + inferiores (pueden especificarse simult´neaa mente). VF01y.y MULA. y sabe adem´s que una de las propiedades a necesarias para la difusi´n de su consola es la acogida de los programadores. e o o y es bastante propenso a errores y supone una gran dificultad a la hora de generar mantenible y legible. ya e ıcil que la inserci´n de una instrucci´n en una columna supondr´ tener que modificar la o o ıa otra columna por completo de forma manual para dejarla intacta si no se desea rellenar con una instrucci´n de NOP el hueco nuevo formado.´ 3. VF01. Esto implica la emisi´n de dos instrucciones o o por ciclo.2. I. y convertirlo en un fichero ensamblador con dos cauces de instrucciones en paralelo. Como o vemos. de control de unidades externas (solo la VU1) 127 instrucciones Se puede usar como opci´n (solo o VU1) 32 registros flotantes de 128 bits. Tambi´n es dif´ de editar debido a la naturaleza de los editores. Q.x MSUBw. a´n o u cuando es de cierta complejidad. este m´todo de programaci´n dista mucho de ser c´modo. Q. A continuaci´n mostraremos un ejemplo de la forma de programaci´n de estas o o unidades. Se trata de VCL [31]. VF14w VF16x. 16 registros enteros. optimizando fuertemente el c´digo. EFU (solo la VU1). (VI04++) VF18. extra´ del manual proporcionado por Sony para las unidades vectoriales ıda [30]. registros especiales: ACC. por lo que a la hora de programar se deben especificar concurrentemente ambas instrucciones.y MSUBw. se emplea la instrucci´n NOP para rellenar el cauce que o ha de permanecer ocioso. MULAw. se especifican en parejas. inferiores (solo una parte). VCALLMSR) 90 instrucciones No hay soporte 32 registros flotantes de 128 bits. VF14w VF16y. VF17 LQI LQI LQI LQI RNEXT VF17. (VI04++) VF20. instrucciones COP2 de transferencia (VCALLMS.P} Macro modo Opera como coprocesador del MIPS 73 Instrucciones MIPS COP2 de 32 bits Instrucciones superiores. VF14w ACCy. VF14w ACC. ya que hay que tener en cuenta dos cauces distintos de c´digo al o mismo tiempo. tal y como mostraba la Figura 3.xyzw ACCx. para apreciar la diferencia en complejidad de .16. cuya finalidad es la de procesar un fichero ensamblador secuencial con ciertas directivas especiales. I. Como se puede intuir. R {. que es lo que nosotros o usaremos. A continuaci´n presentamos un extracto de un c´dio o go ensamblador correspondiente a VCL. R y 16 registros de control N´mero total de u instrucciones EFU Registros Generaci´n de c´digo objeto para la VU o o Hemos mencionado que las unidades vectoriales disponen de dos unidades de ejecuci´n. (VI05++) VF19.

Su finalidad no es m´s que la de definir un objeto para el MIPS a 5900. q Como podemos apreciar a simple vista. 0(iRGBAQ out) . store RGBA0 iaddiu iRGBAQ out. Al fichero ensamblador generado para VCL lo mentaremos basic. de a e manera similar a lo que hicimos con el fichero ((plantilla)) del MIPS.74 desarrollo entre ambas formas.dsm. El nombre no es relevante. iRGBAQ out. vTopLeft. vPos. a˜adido a o n la colecci´n de funciones definidas como macros para las operaciones entre vectores y o matrices m´s usuales en el c´lculo 3D. A continuaci´n. vPos vec x mat vTopLeft. y se puede encontrar en cualquier ejemplo. Esto viene en el fichero vumacros. La informaci´n relativa al paquete DMA. y valores determinados en posiciones de memoria de a datos de la VU se rellenan en este fichero. vVert. con su cauce dual y desenrollado de macros y dem´s conversiones pertinentes. que denominaremos cube. 0(iST out) iaddiu iST out.cmd. DESARROLLO DEL PROYECTO sq RGBAval. pero decidimos dejar el original para que sea m´s f´cil relacionarlo si se ojea el c´digo de ejemplo que a a o proporciona Sony. Comenzamos definiendo el tipo de informaci´n a contener. y posteriormente ino clu´ ımos el fichero de macros que proporciona Sony para facilitar la definici´n de conso tantes para rellenar la memoria de datos de forma manual. PerspMat div q. CAP´ ITULO 3. entre los que cabe destacar: My dma start: representa el punto de inicio del programa a ejecutar en la VU1. 9 sq STVecs[0]. o a o Este fichero lo proporciona Sony. que producir´ un fichero a basic. Para generar c´digo objeto en formato legible por la funci´n de la biblioteca o o libps2dev necesitamos enlazarlo usando unas opciones especiales proporcionadas en el fichero vpu. se operar´ de semejante forma para convertirlo a c´digo objeto. Tambi´n se simplifica de ´ o e forma considerable la programaci´n al disponer de definiciones de macros. OffsetVecs[0].h. vVel add vVert. donde incluiremos el fichero generado mediante VCL basic.vsm al procesarlo. vTopLeft[w] mulq vTopLeft. 9 sub vPos. es m´s sencillo seguir el flujo del programa a con un unico cauce de ejecuci´n que con un cauce dual. El c´digo ensamblador escrito para VCL se procesa y origina como salida un fichero o ensamblador de las VU con un programa equivalente al especificado en VCL. ya que todo programa debe contener a una etiqueta que lo identifique.vcl. iST out. definiendo d´nde est´ la memoria de programa y d´nde la memoria de datos. . un juego o de palabras de la tradicional extensi´n para ficheros en ensamblador asm.vsm en la secci´n del c´digo o o relativo al programa. La extensi´n vsm se refiere a Vectorial Assembler. variables globales e o que se exportar´n hacia el MIPS. Es el que us´bamos en el ((esqueleto)) del MIPS. VCL simplifica la programaci´n ensamblador a a o en otro sentido tambi´n. vf00[w]. definimos una lista de s´ o ımbolos globales que usaremos para exportarlos al MIPS. y e a e detecta autom´ticamente qu´ uso de la instrucci´n se est´ usando para a˜adir los a e o a n sufijos pertinentes. Analizaremos las secciones m´s importantes de ´ste fichero. tal y como a o si hubiera sido programado directamente en lugar de empleando VCL. Una vez a obtenido. o Necesitamos un fichero donde definiremos informaci´n necesaria para que la VU o sea capaz de trabajar con ´l. Agrupa las instrucciones en instrucciones m´s gen´ricas.

global .´ 3.global . que no hemos tenido a bien de definir con anterioridad.h" . Representa la matriz de transformaci´n de vista entre el mundo 3D y su proyecci´n asociada o o 2D. entre otros.global . En este caso. cada uno de ellos de longitud N . Hay que tener esto en cuenta cuando se intenta observar la matriz usada. ponderado por una constante e s de escalado. Mis valores1: representan un conjunto de valores que se usar´n a posteriormente para los c´lculos. La macro fwzyx a o sirve para especificar un cuarteto de valores en coma flotante en el orden (w. Como podemos observar atentamente en la sentencia unpack. Mis barras1. b´sicamente es la inclusi´n del c´digo vsm obtenido del programa a o o basic. aparecido en el c´digo de ejemplo. My dma start.include "vumacros. El nombre en realidad es simplemente herencia del original. IMPLEMENTACION DEL PROYECTO 75 Mis valores. Este argumento determina la posici´n que ocupa el valor o inmediatamente asignado dentro de la memoria de datos de la VU. y. Mis barras2: corresponden a dos vectores de valores. La anchura de las barras y la detecci´n de la a o cadencia forman parte de estos valores. o Como puede observarse. Como se o puede observar.global . M´s informaci´n sobre las transformaciones de vista se explican en el ap´ndice a o e de visionado gr´fico.global My My My My Mis Mis Mis Mis dma start matrix cube start dma next valores valores1 barras1 barras2 Seguidamente definimos el inicio del c´digo a ejecutar.data .EndMPG . la primera fila de la matriz (recordemos que una direcci´n de memoria corresponde a un o cuarteto (x.vsm" .global .DmaPackVif 0 .global . z. o a El trozo de c´digo que refleja todo lo anteriormente expuesto es: o .align 0 DMAcnt * MPG 0. es una mera definici´n adicional para My cube start. siendo N el n´mero de barras a dibujar. x).global . * . determinada por la representaci´n gr´fica de la consola. y. Seo guidamente se define lo que s´ es importante en esta secci´n de c´digo: el s´ ı o o ımbolo My matrix. My dma start: . w) de valores) estar´ en la posici´n de memoria 0. z. encapsulado en una trama DMA. Cada valor iu ´simo representa al ((conjunto de frecuencia)) Ψi .2.vcl.EndDmaData La siguiente secci´n comienza precedida del s´ o ımbolo global definido anteriormente como My dma next. Este s´ ımbolo global tampoco ha sido explicado con anterioridad. el a cuarto argumento es un 0.include "basic. .

0. 4. definimos una serie de valores con la macro iwzyx.000000. 0. 0. dividi´ndolo en dos tri´ngulos.EndUnpack . 0x2005c000. 2048. 4.0 . 0. mios Llegamos al final del fichero. 128. 0. cuyo nombre lo dejamos inalterado del original.000000. 128. * iwzyx 0x00000000. cerramos el paquete DMA. * . 0.0. 255.400002 fwzyx 1. V4 32.0. 4. No es que se mande de forma direca a ta. El resultado ser´ equivalente a un rect´ngulo al que se le a ıa a traza la diagonal. 128. y cuatro colores. * Mis valores: fxyzw 4.EndUnpack unpack[r] 4.0.0.400002. 0x00008006 . o a a Solo diremos que definiremos como primitiva gr´fica un par de tri´ngulos que confora a mar´n una cara rectangular.000000.0. Sin embargo. definimos una posici´n en e a e o el mundo que usaremos de referencia. 102. V4 32. 0. lo realmente importante es lo que se est´ definiendo aqu´ Esa secuencia de cuatro cifras enteras representa el paquete GIF a ı.0 .0 fxyzw 170.000000 fwzyx 0.0 fxyzw 255.EndUnpack MSCNT .0. Podemos ver a el s´ ımbolo global My cube start. My cube start unpack 4. Como podemos observar. que se mandar´ al sintetizador gr´fico en la VU1.752483 fwzyx 0.0.000000. pero nuestro programa de la unidad vectorial cargar´ estos valores para fabricar en a tiempo de ejecuci´n un paquete GIF y mand´rselo al GS.000000. 0x00000041.000000.0. Esta macro representa exactamente lo mismo que fwzyx con la salvedad de tratarse esta vez de n´meros u enteros (prefijo i en lugar de f). Tras ´sto. 0. 2048.000000. donde radica la parte m´s interesante. como veremos m´s adelante. 0.000000. My cube start: DMAcnt * unpack[r] 4. 4. 0.0. que emplearemos en el dibujo de la imagen. 4995000.0. 102. 100. Seguir´n al c´digo una o a o serie de definiciones semejantes que obviaremos dada su similitud con este c´digo o aqu´ presentado. 1. −14. 1. estamos definiendo nuestro cuarteto de valores auxiliares en la posici´n de memoria 8. 170. 100000000. ı unpack 4. 200. V4 32. 0 .EndUnpack A estas alturas ya deber´ ıamos estar familiarizados con la definici´n de valores o en zonas de memoria concretas.765776.0. 8. DESARROLLO DEL PROYECTO My dma next: DMAnext *.76 CAP´ ITULO 3. 35.050000.000000 . 0.000000.0 fxyzw 0. Como vemos. 0. — color — fxyzw 255. — position — fxyzw 0. 255.0. 128. Screen Matrix My matrix: fwzyx 0. 0. *. Tras esto.0.0.0. V4 32.

o Figura 3. Ahora comentaremos brevemente qu´ es cada bloque denotado en dicho esquema. a a o e calculando a su vez su valor RGBA.EndDmaData DMAend 77 Una vez comentada la estructura de ficheros necesaria para la generaci´n del o c´digo objeto. Si se desea una informaci´n m´s detallada y exahustiva. Introducci´n al sintetizador gr´fico o a Antes de explicar la programaci´n del sintetizador gr´fico que necesitamos para o a mostrar nuestro gr´fico de barras por pantalla. haremos una breve introducci´n al a o sintetizador gr´fico con la finalidad de entender un poco qu´ conforma y c´mo funciona a e o dicha unidad. y o determina el color final con el que se debe dibujar bas´ndose en la informaci´n a o calculada en el Rasterizing. La Figura 3.17. Memory I/F: es el m´dulo encargado de leer y escribir en la memoria local o del sintetizador gr´fico.18 muestra un esquema de su estructura interna. IMPLEMENTACION DEL PROYECTO .17: Proceso necesario para obtener el c´digo objeto desde el fichero ensamo blador.´ 3.2. podremos comprender los pasos que se muestran en la Figura 3. niebla. valor Z y niebla para cada pixel. La transferencia del buffer y de la informaci´n de dibujado pasan por este interface. Escribe los valores RGBA+Z del pixel a dibujar al final a . Pixel Pipeline: realiza procesos como texturizaci´n. Puede procesar hasta diecis´is pixels concurrentee mente. o Setup/Rasterizing (preprocesamiento): se encarga de generar las formas que se dibujar´n como puntos bas´ndose en la informaci´n recibida sobre los v´rtices. transparencias. remitimos como o a siempre al manual [29]. que o ilustra la generaci´n de un fichero objeto para ser cargado en la unidad vectorial. e para poder identificarlos. Host I/F: es el interface encargado de transferir datos con el procesador.

18: Descomposici´n en bloques del sintetizador gr´fico. DESARROLLO DEL PROYECTO Figura 3. o a .78 CAP´ ITULO 3.

. Rasterizing (DDA): los pixels correspondientes a una primitiva se calculan usando el DDA. Local Memory: se trata de la memoria local del sintetizador gr´fico. y lee los valores RGBA de la imagen representada. Los pasos que se siguen son: Setup (Preprocesamiento): tanto el gradiente como los valores iniciales del algoritmo digital diferencial (DDA) necesarios para dibujar primitivas se calculan bas´ndose en la informaci´n de v´rtices que recibe desde el ((host)). lee de memoria los valores de los pixels del frame o buffer que se usan para las transparencias.9375. Los lados se suavizan cuando las transparencias se o implementan usando este valor alfa. permitiendo un rango de 0 a 4095. tanto horizontal como vertical. PCRTC: muestra el contenido del frame buffer en el formato especificado. Fogging: el valor RGB y el valor de niebla obtenidos del bloque de aplicaci´n de o textura se mezclan en concordancia con el valor de niebla del punto calculado por el DDA. y al RGBA calculado por el DDA. Es decir. De forma concurrente se generan 8 ´ 16 pixels.2. a o La Figura 3. Es distinto al ((standard)) en a bibliotecas y sistemas de representaci´n habituales.´ 3. o Sistema de Coordenadas de Mundo: usa una representaci´n de 16 bits de coma o fija. y un puerto de 512 bits para leer la textura. las texturas y el CLUT (Color Look Up Table o paleta de colores). Si la primia o e tiva gr´fica es un tri´ngulo. que contiene el frame buffer. Hay que tener cuidado con ´sto cuando se quiera visualizar e algo. Z buffer. el valor Z. valor o Z. El valor RGBA. Texture Mapping: la textura se aplican sobre los pixel. la parte de mundo que quedar´ plasmada a en la pantalla es la que corresponde a la ventana definida por este rango. Dispone de un puerto de lectura de 1024 bits y un puerto de escritura de 1024 bits para dibujar y acceder al frame buffer y al Z buffer. Por ejemplo. el punto central de la pantalla ser´ el a punto (2048.19 representa el flujo de dibujado necesario para convertir la informaci´n que recibe del procesador (((host))) en datos representables gr´ficamente por o a pantalla. compuesta a por 320Mbit. El color del pixel se determina aplicando la funci´n de textura al valor RGBA de la textura le´ de o ıdo la memoria. 2048). Sistema de Coordenadas de Dispositivo: el punto de origen se sit´a en la esquina u superior izquierda del rect´ngulo de visualizaci´n. de textura y la niebla para cada pixel se calculan del gradiente obtenido en la etapa de preprocesamiento anterior. Antialiasing: el valor alfa se sustituye por la cobertura de pixel calculada por el DDA (la cobertura del pixel se refiere a la proporci´n de pixel ocupada por el o lado de la primitiva te´rica). y el valor de niebla en las tres aristas y en el scan line se calculan. el valor de a a textura. el gradiente del valor RGBA. lo que puede llegar a crear una o confusi´n si no se ha tenido en cuenta. Un detalle muy a tener en cuenta con el sintetizador gr´fico para evitar problemas a m´s adelante es el sistema de coordenadas que emplea. es decir 12 bits para la parte entera y 4 bits para la parte decimal. IMPLEMENTACION DEL PROYECTO 79 de la operaci´n de dibujado.

a .19: Flujo de datos del sintetizador gr´fico. DESARROLLO DEL PROYECTO Figura 3.80 CAP´ ITULO 3.

prueba de transparencia. que se o realizan una a una.2. de forma encadenada. dibujado con la informaci´n de dos puntos. transparencia destino y comprobaci´n de profundidad).´ 3. Tiene a un hardware suficientemente complejo como para permitir que trabajemos en un nivel de abstracci´n superior a puntos en la pantalla. con una breve descripci´n aclarativa. o e Tri´ngulos encadenados (trianglestrip): a Una sucesi´n de tri´ngulos que comparten un lao a do con el tri´ngulo siguiente. o y leer valores RGBA de memoria para representarlos. Alpha-blending: la mezcla del color RGB de un pixel y el valor RGB del frame en memoria se implementa seg´n el valor alfa del pixel o el valor alfa del frame u en memoria. Mostraremos las distintas opciones que o soporta el sintetizador gr´fico. dibujado con la informaci´n de o un v´rtice. e a . Memory I/F: la lectura/escritura sobre la memoria se realiza a memoria local en el chip. o L´ ıneas encadenadas (linestrip): Sucesi´n de l´ o ıneas que comparten el punto final como inicial de la siguiente. leer valores de pixels al frame buffer desde memoria. o El hardware de la consola permite dibujar primitivas gr´ficas directamente. Se suavizan o truncan los colores si es necesario. a o Punto (point): Un punto suelto. e L´ ınea (line): Una l´ ınea independiente que une dos puntos. La primera necesita informaci´n de dos o puntos. IMPLEMENTACION DEL PROYECTO 81 Pixel Test: pintar un punto o no queda determinado por sus valores XYZ y RGBA. y el resto solo de uno m´s. y el resto o e solo necesita un v´rtice por tri´ngulo. Se realizan cuatro comprobaciones para determinarlo (recorte.Z) en memoria tras una operaci´n de pixel. formado con la ina formaci´n de tres v´rtices. Environment Register: conforman una serie de registros que contienen informaci´n necesaria para el dibujado. a Tri´ngulo (triangle): a Un tri´ngulo independiente. El primer tri´ngulo a a necesita informaci´n de tres v´rtices. Las operaciones principales son: escribir pixels (RGBA. Formatting: se convierte el formato de los valores del pixel al formato usado en el frame buffer.

82 CAP´ ITULO 3. a 2. niebla. Programaci´n del sintetizador gr´fico o a Una vez examinadas por encima las capacidades del sintetizador gr´fico. DESARROLLO DEL PROYECTO Tri´ngulos en abanico (trianglefan): a Sucesi´n de tri´ngulos que comparten un v´rtio a e ce. vamos a a explicar los pasos que hay que realizar para comunicar nuestras intenciones de pintar algo en la pantalla. y enviar la orden al sintetizador gr´fico. Daremos una informaci´n m´s detallada sobre las opciones de cada paso. como propiedades de la misma. o e a Sprite: Rect´ngulo dibujado con solo dos v´rtices.1 Atributo IIP TME FGE ABE AA1 FST CTXT FIX Descripci´n o M´todo de sombreado e Aplicaci´n de Textura o Niebla Transparencia Suavizado Coordenadas de Textura Contexto Interpolaci´n FIX o Opciones Flat/Gouraud S´ ı/No S´ ı/No S´ ı/No S´ ı/No STQ/UV 1/2 S´ ı/No Cuadro 3. texturas. entre los que se o o encuentran tambi´n las coordenadas UV de aplicaci´n de textura. o cualquier combinaci´n de los posibles atributos. se debe definir el tipo de o primitiva y las caracter´ ısticas que tendr´. tambi´n e o a e debemos especificar el n´mero de v´rtices que vamos a definir. Las opciones aparecen en la a Tabla 3. El procedimiento general es bastante sencillo una vez comprendido el procedimiento. Primero debemos decirle al sintetizador gr´fico qu´ vamos a pintar.1: Antes de especificar la lista de informaci´n.2. como si queremos especificar solamente la posici´n de los v´rtices. . Informaci´n de los v´rtices: en este apartado veremos los tipos de registros diso e ponibles para especificar informaci´n variada sobre el v´rtice definido. etc. Despu´s solo resta dar toda la e informaci´n que le hemos dicho que ´ o ıbamos a usar. para a o a comprender las posibilidades. y el resto de tri´ngulos solo necee a sitan la informaci´n de un v´rtice m´s. 1. Esto incluye a e tanto tipo de primitiva (una de la lista anterior). El primer tri´ngulo necesita informaci´n de a o tres v´rtices. dentro de lo que se incluye tanto si queremos antialiasing. ya que es parte de la u e primitiva la cantidad de aristas que estamos dibujando. Los tipos o e de registros quedan recogidos en la Tabla 3. que a e marcan la diagonal del mismo. Adem´s. Configurando el tipo de primitiva y los atributos de representaci´n: primero se o elige el tipo de primitiva y las opciones que tendr´. o si queremos especificar o e posici´n y color.

el dibujado comienza. explicaremos e fragmentos de c´digo. y la cola avanza una posici´n. o e Figura 3. a e Programa de la VU1: basic. para o o entender qu´ hacemos en dicha unidad. escrib´ ıamos algunos datos tales como matrices o las barras en la memoria de datos de la VU1.20: Desplazamiento realizado en la cola de v´rtices como consecuencia de un e vertex kick. o Lo primero que haremos ser´ definir las constantes que referenciar´n a las zonas a a de memoria de datos que usamos en la VU1. La Figura 3.20 muestra una ilustraci´n de lo que supone este proceso.vcl En esta secci´n detallaremos el c´digo que compone el programa de la VU1. Aqu´ definimos ı . Como hemos venido haciendo. relevando detalles significativos del mismo. A este proceso se le conoce como vertex e o kick. o 4.2. IMPLEMENTACION DEL PROYECTO Elemento Coordenadas Coordenadas y coeficientes de niebla Coordenadas Coordenadas y coeficientes de niebla Color y par´metro Q de las coordenadas a de textura Par´metros ST de las coordenadas de a textura Coordenadas UV del texel Coeficiente de niebla Registro XYZ2 XYZF2 XYZ3 XYZF3 RGBAQ ST UV FOG Vertex Kick S´ ı S´ ı S´ ı S´ ı No No No No Drawing Kick S´ ı S´ ı No No No No No No 83 Cuadro 3. Vertex Kick: si los registros usados ten´ la funci´n vertex kick la informaci´n ıan o o concerniente al v´rtice especificada hasta ese momento se sit´a en la cola de e u v´rtices.2: Registros existentes para especificar informaci´n asociada a un v´rtice. Comenzar el dibujado (drawing kick): cuando toda la informaci´n necesaria o est´ en la cola de v´rtices. 3.´ 3. Como ya vimos.

cargamos la matriz de tranformacion geometrica lq Transform[0].dsm. Por tanto.assign 8 kMisValores1 . haciendo m´s legible el a programa que proseguir´ a continuaci´n. Y tras ´sto. Recordao o ´ remos de apartados anteriores. deja que el vcl use todos los registros flotantes . deja que el vcl use todos los registros enteros Inicialmente. kScreenMat3(vi00) . kScreenMat0(vi00) lq Transform[1]. o . Lo que realizamos en la primera secci´n de o c´digo es cargar aquellos valores que definimos (primitiva.84 CAP´ ITULO 3. Destacaremos la instrucci´n xtop.init vf all . cuando comentamos la definici´n del fichero cube.assign 0 kScreenMat1 . comenzamos la secci´n de a e o c´digo. cargamos la matriz de transformaci´n geom´trica de la zona de memoria kScreenMat al vector Transform. v´rtice de referencia y los o e colores).vu −−enter −−endenter .syntax new . direcciones de memoria donde se encuentran los datos a usar kScreenMat0 . a o . DESARROLLO DEL PROYECTO un nombre para referirnos a dichas posiciones de memoria.assign 3 kMisValores0 .assign 512 kBarras2 . el unico).assign 2 kScreenMat3 . que obtiene la direcci´n de la memoria o o donde se encuentra el primer GIF (en nuestro caso. kMisValores0(vi00) lq MiValor2. kScreenMat2(vi00) lq Transform[3]. indicando que queremos darle libertad en el empleo de todos los registros (no necesitamos usar manualmente ninguno impidiendo que lo use para sus fines). iniciamos ´ . o que defin´ ıamos un cuarteto de valores enteros que eran el GIF o especificaci´n de la o primitiva gr´fica que ´ a ıbamos a emplear.assign 819 Ahora especificamos unas primitivas para el preprocesador. donde pasaremos ciertos e par´metros entre el EE y la VU1.assign 9 kBarras1 .assign 1 kScreenMat2 . cargamos las constantes lq MiValor. a .init vi all . kScreenMat1(vi00) lq Transform[2]. Haciendo uso de las constantes definidas al inicio de todo. cargaremos las constantes que necesitaremos emplear posteriormente. kMisValores1(vi00) −−cont Comenzamos la secci´n de c´digo que se ejecuta al inicio una unica vez. o e Tambi´n cargamos las ((constantes)) varias que definimos. y le especificamos tambi´n que e queremos usar la sint´xis ((nueva)) del VCL.

en lugar de tener que hacerlo en ambas. (iColor in++) color2. trans vert[w] mulq floatScreenVec. . para o que el bucle solo tenga que ir desplazando en el contrario. iVert in. En esa posici´n guardamos el GIF mediante la inse o trucci´n de almacenamiento (sq en este caso). . lo que hacemos es desplazar la posici´n de origen a uno de los lados. . vf00[w]. y normalizar seg´n la coordenada W . IMPLEMENTACION DEL PROYECTO 85 unos punteros a dichos atributos para cargarlos posteriormente. 0(iBase) . sq GifTag. Transform div q. el 1. 4 . iaddiu iKick. iaddiu iVert in. multiplicar´ por el inverso. Tal y como rezan los comentarios del o c´digo. decidimos mover el origen a la izquierda (unos 240 pixels). al igual que el entero vi00 contiene valores constantes en ´l. iColor in. nos limitamos posteriormente a cargar la informaci´n que rellenamos en otro o o fichero de datos. lo m´s sencillo para simplificar el bucle futuro a es movernos unicamente en una direcci´n. tras los cuatro colores o que defini´ramos en su momento. carga carga carga carga carga vertice color 1 color 2 color 3 color 4 Prosiguiendo los c´lculos que se realizan una unica vez por fotograma. vf00 contiene el cuarteto e (0. calcula la transformacion de geometria y normaliza por W. En este caso. . Aqu´ se usa la coordenada w. . graba el GIF . 0(iKick) lq lqi lqi lqi lq vert in. y en lugar de dividir por W . Por tanto. 1 . iaddiu iColor in.´ 3. (iColor in++) color3. 1) siempre. ya que dividimos 1 por el valor. y queremos e pintar barras ordenadas en frecuencia. . 0. trans vert. y la variable iKick apunta a la primera direcci´n de memoria posterior al GIF libre. Como podemos observar. Es decir. El proceso consiste en multiplicar la matriz de transformaci´n por el vector que contiene las cooro denadas del punto. (iColor in++) color4. que no se pueden modificar. Con ´ste valor (que resulta ser 1/W ). por lo que pintaremos de izquierda a derecha las barras. . q Como el v´rtice de referencia que usamos es el centro de la pantalla. Estamos calculando ı el inverso. lo que hace un total de 60 barras por canal. nos encona ´ tramos el paso de coordenadas de mundo a coordenadas de ((dispositivo)). ´ o Por tanto. vert in. ya u a que pintaremos cuatro barras por vuelta y canal. 0. en la variable GifTag hemos almacenado el GIF.2. 1 . (iVert in) color. guardando el resultado en floatScreenVec vec x mat trans vert. e normalizamos el resultado obtenido en el producto anterior. . Para ello usamos la macro u vec x mat para hacer P × M. Definimos el n´mero de iteraciones que har´ el bucle en 15. En iBarras e iBarras2 mantendremos el puntero a los datos del canal derecho e izquierdo respectivamente. iBase. es decir. a Recordemos que el registro flotante vf00. START0: xtop iBase lq GifTag. (iColor in) carga el tag GIF puntero al vertice puntero al color puntero a memoria libre para grabar nuestro tag GIF .

Cargamos de cuatro en cuatro valores. de modo que la primera barra se dibujar´ con el valor de barrasOrig. la a segunda con el valor de barrasOrig. 6 . barrasOrig[x] . MiValor2 . por lo tanto. floatScreenVec. kBarras2 // puntero a las barras Comenzamos ahora con el bucle LOOP.86 CAP´ ITULO 3. (iBarras++) lqi barrasOrig2. desplaza el punto 240 a la izquierda para que este en el margen . (iBarras2++) Esta parte del c´digo trata la iniciaci´n de las variables necesarias para calcular o o temas relativos al dibujado de las barras. carga los valores Y de las barras y avanza los punteros lqi barrasOrig. iKick. el indicador de ritmo. sube el origen de la barra segun el beat detection sub. 1 . en lugar de en el centro de la pantalla loi 240. DESARROLLO DEL PROYECTO . I . ı . LOOP: . y as´ sucesivamente. cargamos las barras iaddiu iBarras. kBarras1 // puntero a las barras iaddiu iBarras2.x floatScreenVec. puntero para grabar los RGBAQ iaddiu iXYZF2 out.y MiValor. iKick. vi00.y tenemos el valor o e o detectado de cadencia de la se˜al.x. iBase. o desplazamos el punto de origen hacia arriba para pintar el canal derecho. lo que a implica tres v´rtices con tres colores). vi00. Cargamos el valor de las cuatro primeras barras e de cada canal en las variables barrasOrig y barrasOrig2.y. Valor que usaremos n para producir una separaci´n vertical entre las barras de cada canal. Antes de dibujar las barras. — canal derecho ——————– iaddiu iRGBAQ out. 2 . vamos a dar 15 vueltas (en cada una pintamos 4 barras por canal) iaddiu cuenta. cargamos el valor proporcional de altura que debe tener la barra. apunta a una posicion libre de memoria iaddiu iKick. carga la altura de la barra add. floatScreenVec. obtenido tras el procesamiento del valor de la FFT. Situamos los punteros donde grabaremos la informaci´n de los v´rtices (color y posici´n).y floatScreenVec. 15 .0 subi. vf00. Primero situamos el puntero de zona libre a una zona realmente libre (recordemos que estamos especificando tri´ngulos. Es decir. puntero para grabar los XYZF2 . vi00. En MiValor2.

MiValor2 . Antes de eso. floatScreenVec ftoi4 ScreenVec. iKick. dibujaremos la barra del canal restante antes de pasar a dibujar la siguiente barra. — color — ftoi0 screenCol. 25 sq GifTag. Iniciamos punteros de color y posici´n. floatX1Y1 sq ScreenVec. .2. e nuestra primitiva. manda el GIF al GS y mueve el puntero a una posicion libre xgkick iKick iaddiu iKick. iKick. — crear primitivas — . — crear primitivas — . incrementamos los e respectivos punteros. puntero para grabar los RGBAQ . vertice 1 move floatX1Y1.x. 0(iRGBAQ out) iaddiu iRGBAQ out. 2 . floatScreenVec ftoi4 ScreenVec. desplazamos esta vez hacia abajo seg´n la cadencia determine. barrasOrig2[x] . floatScreenVec. y cargamos el o u valor de esta barra. y los del techo (3. Como se aprecia. 2 y e 6) usan uno.y floatScreenVec. mismo de antes: comenzamos a definir los seis v´rtices que conformar´n el rect´ngulo. que generaran un gradiente. y escribimos el nuevo GIF para definir el canal que resta. graba XYZF2 iaddiu iXYZF2 out. Lo que hacemos es calcular la posici´n de cada v´rtice relativa a la o e posici´n de referencia debidamente desplazada seg´n la cao u dencia anterior. 2 .y MiValor. iXYZF2 out. iKick. vf00. As´ definimos los seis v´rtices que conforman ı. MiValor2 add. como efecto especial para representar la cadencia de la canci´n. tras grabar el valor del v´rtice o color. 0(iKick) . 2 87 Proporcionada la informaci´n relativa a los seis v´rtices que forman nuestra prio e mitiva. deshace la subida para el beat detection add. podemos enviarla a la cola de v´rtices para que sea dibujada. . contenido en barrasOrig2. graba XYZF2 . floatX1Y1 sq ScreenVec.y floatScreenVec. Adelantamos el puntero a o e a una zona libre. 0(iXYZF2 out) . IMPLEMENTACION DEL PROYECTO El dibujo de las primitivas se realiza en esta parte. 4 y 5) usan el otro. A partir de aqu´ volvemos a hacer lo ı. La distribuci´n de los seis v´rtio o e ces se muestra en la figura de la derecha. graba el tag GIF Una vez hemos terminado de pintar la barra de un canal. Los v´rtices de la base (1. puntero para grabar los XYZF2 add.´ 3. iRGBAQ out. 0(iXYZF2 out) . color sq screenCol. La instrucci´n xgkick o o manda la informaci´n de los v´rtices al sintetizador gr´fico. e desharemos el desplazamiento que realizamos para separar las barras verticalmente. 1 iaddiu iXYZF2 out. e a a iaddiu iRGBAQ out. floatScreenVec. Disponemos de dos colores por canal. vertice 1 move floatX1Y1. cada uno de ellos con la correspondiente informaci´n relativa al color.

para pintar la siguiente barra con una separaci´n hasta la anterior. se env´ al sintetizador gr´fico. deja separacion para la siguiente barra add. manda el GIF al GS y mueve el puntero a una posicion libre xgkick iKick isubiu iKick. una vez conclu´ la especiıa ıda ficaci´n de los v´rtices que forman la barra.88 CAP´ ITULO 3. MiValor . cuenta. iRGBAQ out. reiniciamos el programa desde START0. para escribir la informaci´n relativa a las barras del canal derecho o siempre en la misma zona de memoria. LOOP −−cont b START0 . tenemos dibujadas cuatro barras en pantalla. te por la pantalla. graba el tag GIF . 50 sq GifTag.x floatScreenVec. vi00.x = ancho add.x floatScreenVec. iXYZF2 out. queda una menos iaddi cuenta. . 2 De manera similar a lo que ocurr´ en el otro canal. 0(iKick) . deshace la subida para el beat detection sub. y volvemos a escribir el GIF por si se hubiera sobreescrito por el canal izquierdo. En caso contrario. o como hemos hecho entre cada par de barras. MiValor. — color — ftoi0 screenCol. MiValor. floatScreenVec. Si es afirmativo. 0(iRGBAQ out) iaddiu iRGBAQ out. MiValor . floatScreenVec. Movemos o e ıa a el puntero al inicio. 2 .y floatScreenVec. Una vez conclu´ nos desplazamos horizontalmenıdo. color3 sq screenCol.x = ancho Llegado a este punto. y vemos si quedan m´s vueltas que realizar. MiValor2 . Actualizamos el valor del bucle. fin de la vuelta. floatScreenVec. . −1 ibne cuenta. DESARROLLO DEL PROYECTO iaddiu iXYZF2 out. as´ que hemos ı formalizado una vuelta del bucle.END . volvemos a LOOP para comenzar a dibujar a las siguientes cuatro barras. iKick.

y expondremos el c´digo o o equivalente una vez programado para la VU0.1. 4. la herramienta ya comentada para medir el uso de CPU de la que disponemos. De forma similar a como ocurre en un PC compatible x86 con su coprocesador matem´tico.Cap´ ıtulo 4 Optimizaci´n del programa o sobre el hardware En este cap´ ıtulo nos centraremos sobre la distribuci´n de la carga inicial del proo cesador central hacia la unidad vectorial VU0. y que pod´ ser f´cilmente transladadas en su totalidad. solo necesitamos programar en el ensamblador 89 . funcionando como coprocesador para ´l.1. como explicamos en el apartado 3. 4. y o a la posibilidad que ofrece la VU0 para ello. Usando top. aislamos las partes de c´digo que supon´ un uso muy considerable o ıan de CPU. conocedores de que era f´cil distribuir gran parte de la carga pesada del a procesador central a c´lculos en la VU0 ejecut´ndose como coprocesador (en lo que a a definimos como macro modo). Posteriormente. Sin embargo. ıan a Primero haremos una breve introducci´n a la forma empleada para programar el o c´digo para usar la VU0 como unidad de coprocesamiento.5. y de manera autom´tica.1. se ejecutar´n a a en la unidad correspondiente. Uso de la VU0 como ayuda del MIPS Cuando probamos el prototipo del programa descubrimos que la velocidad del MIPS no era suficiente para procesar toda la carga que le hab´ ıamos propuesto. o Ahora es el momento de distribuir parte de la carga asignada al MIPS y su FPU a la VU0. la forma de usar el a repertorio ((expandido)) gracias al coprocesador consiste en invocar a cualquiera de las instrucciones que forman parte del coprocesador. e logrando una integraci´n de c´mputo entre el MIPS y la VU0 dentro del mismo c´digo o o o gracias a la posibilidad de insertar c´digo ensamblador en cualquier programa de C. Es decir.2. la unidad vectorial VU0 tiene la capacidad de trabajar como coprocesador para el EE. Programaci´n in line de la VU0 como preprocesador o Tal y como hemos dicho en secciones anteriores. proseguimos con la programaci´n del apartado gr´fico o a sin prestarle mayor atenci´n entonces. y los detalles a tener en o cuenta cuando usemos esta modalidad de programaci´n. analizaremos o en mayor profundidad las secciones de c´digo a transladar.

Debido a la circunstancia de encontrarnos bajo un o o entorno de desarrollo linux con el compilador gcc de C. Arquitectura de los Computadores II [37] y Arquitecturas Especializadas [43]. productos. se remite a las referencias proporcionadas a en este p´rrafo. m´ximos. sumas. est´bamos suficientemente a familiarizados con el proceso de integraci´n comentado. asignaturas cursadas por ambos. recibido en las asignaturas de Arquitectura de los Computadores I [55]. b. Gracias al conocimiento adquirido sobre programaci´n en ensamblao dor empotrada en un programa de C. existe una p´gina [12] donde re´nen ino a u formaci´n sobre la programaci´n de ensamblador bajo linux. El tipo de instrucciones que provee la VU0 al MIPS al actuar de coprocesador se divide en cuatro categor´ ıas: Instrucciones de transferencia: empleadas para la transferencia de datos entre el EE y la VU0. restas. Este m´todo consiste en emplear la sentencia asm para escribir una pore ci´n de c´digo en ensamblador. Un ejemplo sencillo donde se perciba la utilidad de cada uno de los campos expuestos anteriormente sin crear confusi´n adicional puede tratarse de hacer una asignaci´n o o equivalente a una del tipo a = b en C. solo que realizada en ensamblador dentro de un programa en C. as´ como a las asignaturas mentadas. En dicha p´gina podemos o o a encontrar un enlace a un ´rt´ a ıculo [44] que hace una descripci´n sobre la forma de de o programaci´n ((in line)). m´ a ınimos. ra´ cuadradas. o o realizando una llamada a dicha subrutina. o con micro c´digo. Instrucciones de c´lculo de coprocesador: conforman el repertorio de operaciones a que se pueden realizar con los datos. Aqu´ resumiremos lo esencial para entender el c´digo que usao ı o remos nosotros. divisiones. Valor absoluto. o Una forma de empotrar c´digo ensamblador en el c´digo C es usar el m´todo o o e ((in line)). y optamos directamente por o este m´todo de programaci´n. asm ( " . Quedar´ ıa: int a = 12. As´ se puede mezclar macro c´digo ı. propias del repertorio del MIPS. Les precede la letra V para o u distinguirlas de instrucciones con nombres similares. Instrucciones de salto: eval´an las se˜ales condicionales del MIPS COP2. la sintaxis empleada es la de dicho compilador. Instrucciones de llamadas a microsubrutinas: hacen posible la ejecuci´n de un o programa hecho en micro c´digo desde la forma de ejecuci´n como coprocesador. Si se desea profundizar m´s. a ı La estructura general de la sentencia asm la mostramos a continuaci´n: o asm ( c´digo en ensamblador o : operandos de salida (opcional) : operandos de entrada (opcional) : lista de registros sobreescritos (opcional) ). producto-suma. operaciones l´giıces o cas y generaci´n de n´meros aleatorios entre otras. Podemos enviar de una unidad a otra tanto n´meros flotantes como u enteros.90 ´ CAP´ ITULO 4. Para aquellos que no hayan tenido contacto anterior con e o la programaci´n de ASM y C al mismo tiempo. OPTIMIZACION DEL PROGRAMA SOBRE EL HARDWARE correspondientepara que el programa resultante se ejecute de forma correcta en la unidad vectorial. Se usan u n para preguntar por el estado de la VU1.

de u forma que est´ alineado con una frontera de 128 bits. tmp. siempre desplazando el puntero hacia delante para alinear. %%eax # eax <.1. es decir. o /* * Funcion que alinea un vector de tam componentes flotantes a una * frontera de 128 para evitar un ’bus error’ al enviarlo del EE a la VU */ float * alineaF128 (int tam) { float * tmp. debemos alinear las variables que vayamos a usar para la o VU0. La funci´n resultante la o escribiremos a continuaci´n por si se quiere analizar. "reservado de %p a %p -->".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 c´digo asm */ o ). as´ como al tutorial de Brennan a ı [50] y el Linux Assembly HOWTO [54].oper[1] movl %%eax. recibimos un error en el bus.4. y m´xime teniendo en mente que el repertorio o o a de instrucciones que emplearemos ser´ totalmente distinto. Por tanto. d = (0x10 − ((int)tmp & 0x0F))/sizeof (float). cuya finalidad principal es la de mostrar c´mo se puede interactuar en una mezcla de alto y bajo o nivel con el sistema operativo. if (d < 4) tmp += d. Quien desee o o profundizar m´s puede remitirse a las referencias dadas. . int d. " %p\n". el EE generar´ una excepci´n de error a o en la direcci´n)). aunque el m´ ınimo cambio para alinear el puntero se consiguiera desplaz´ndolo hacia atr´s. a a a esta forma de inserci´n de c´digo ensamblador dentro de programas C. Como bien se puede leer en la documentaci´n. %0 # oper[0] <. tmp). fprintf (stderr. Con lo descrito hasta aqu´ consideramos que se entender´ la mec´nica b´sica de ı. cosa que aqu´ no trataremos debido princiı palmente a que no consideramos necesario desarrollar en toda su extensi´n el potencial o de este tipo de incrustaci´n de c´digo. El funcionamiento b´sio a co es reservar el n´mero suficiente de bits para poder desplazar el inicio del puntero. podea a mos determinar que la cantidad m´xima de bits a desplazar siempre ser´ inferior a 128 a a bits. Haciendo las primeras pruebas para probar a insertar c´digo VU0 en el MIPS o llegamos al principal inconveniente: cuando cargamos algunas variables de la memoria del EE a la de la VU0. tmp+(tam+3)). y en general cualquier operaci´n con la memoria. se realiza a nivel de byte o como m´ ınima unidad. ya que no se trata de una a arquitectura mentada en ninguno de los documentos que hemos propuesto. Por tanto. calculamos la direcci´n de memoria m´s cercana hacia delante o a que es frontera de 128 bits. Si hacemos un algoritmo ((siempre hacia o delante)). fprintf(stderr. reservarmos 128 bits adicionales de memoria. Como el direccionamiento a memoria. Necesitamos que los ultimos cuae ´ tro bits de la direcci´n de memoria sean cero. y desplazamos el puntero a ella. los 4 bits menos significativos no son cero. el problema es simplemente la alineaci´n de las variables: ((si la o o direcci´n efectiva (GPR[base]+offset) no est´ situada en una frontera de 128 bits. USO DE LA VU0 COMO AYUDA DEL MIPS 91 movl %1. es o a decir. Para ello generaremos una funci´n encargada de tal tarea. tmp = (float *) malloc(sizeof (float)*(tam+4)).

o El c´lculo de la FFT por contra. Decodificaci´n de una trama ogg vorbis en PCM. } 4. Procesar las frecuencias en conjuntos de frecuencias. y va almacenando el resultado.2. Por tanto. de manera que su implementaci´n se adapte a las propiedades de c´mputo que provee o o dicha unidad. Calcular la FFT de la se˜al. por lo que debemos convertir nuestro tipo de dato escalar en vectorial para procesarlo. aproximadamente cada una de las cuatro tareas que hemos nombrado son pr´cticamente similares en cuanto ocupaci´n. 4. 3. el proceso de frecuencias o a en conjuntos de frecuencias y la conversi´n de conjuntos de frecuencias a altura. 6. la decodificaci´n no cumple siquiera un flujo a o de operaciones similares sobre una secuencia de datos de entrada. rondando en torno al 20 % a o cada una. Sin embargo. esta tarea de decodificaci´n de ogg vorbis s´ representa una o ı caracter´ ıstica especial que no presentan ninguno de los tres restantes procesos: su estructura es completamente distinta a la requerida para la VU0. Aunque ninguna cumpla el requisito de cu´drupla en el espacio 3D. Nuestro programa no posee ese o tipo de datos. ponderando con un hist´rico. n 5. operaci´n tambi´n conocida o e como ((profiling)). determinamos que las tareas m´s pesadas computacionalmena te conforman la decodificaci´n a PCM. aunque no hay que entender que sea muy pesada con este comentario. que son: 1. toda la arquitectura de c´mputo espec´ o ıfica de la PlayStation2 est´ dise˜ada para operar con vectores de cuatro elementos. lo que supone una optimizaci´n muy baja. la decodificaci´n de la trama ogg vorbis es una de las prino cipales cargas del sistema. reprea n sentaci´n de un punto en un espacio tridimensional. en general. Convertir los conjuntos de frecuencias en un valor de altura para la barra a dibujar. En realidad. o 2. Mantiene para una serie de datos las mismas a operaciones. s´ sigue una estructura de operaci´n amoldable a ı o al c´lculo de las unidades vectoriales. Recordemos que.92 ´ CAP´ ITULO 4. Como dijimos antes. OPTIMIZACION DEL PROGRAMA SOBRE EL HARDWARE return tmp. Mandar el PCM al sintetizador de audio para reproducir el sonido. en caso de producirse. Deshacer el entrelazado de los canales para realizar la FFT. o Ahora debemos seleccionar tareas para migrarlas a la unidad vectorial VU0. Secciones de c´digo a optimizar o Haciendo uso de las herramientas de las que disponemos para hacer an´lisis de a recursos y uso de procesamiento de nuestro programa. o Realizando un estudio del ((peso)) de cada tarea en la ocupaci´n final del procesador o mediante la utilidad top. el c´lculo de la FFT. Calcular la existencia o no de un golpe de cadencia. sino que maneja un tipo de dato completamente escalar. 7. ya que no sigue un flujo f´cilmente trasportable a la unidad vectorial. lo que implica una integridad en la VU0 a bastante limitada. no es un proceso deseable para migrar a la unidad vectorial VU0. Podr´ visualizarse como un procedimiento ıa . El programa principal en el MIPS est´ formado por una serie de a tareas secuenciales.

d = (int)(sqrt(tmp out[1][i+1])*0.0)*N BAR). o 4. Es un proceso con una proyecci´n hacia la VU0 v´lida. m´ltiples datos) sobre un conjunto de valores de entrada. y a ıdo o se requiere una velocidad de c´mputo aceptable para no generar cuellos de botella en o el funcionamiento de dicha aplicaci´n. Procesamiento de frecuencias a conjuntos de frecuencias El c´digo original de procesamiento posterior a la FFT es uno de los cuellos de o botella que presenta nuestra aplicaci´n en el procesador MIPS. i<OUT SIZE−1.1. ya que requiere de inversi´n de bits y distintas conversiones internas o para funcionar. // === (1/(2^8)/1024)*N BAR = (1/(2^8)/1024)*64 = 0. Sin embargo.2. y hay que tener en cuenta que el c´digo de los mismos ni siquiera o est´ optimizado. o a El c´lculo de los conjuntos de frecuencias se basa en realizar un peque˜o n´mero de a n u operaciones de gran complejidad computacional sobre cada uno de los valores obtenidos por la FFT. Tambi´n repercute el hecho a ıa e de que la implementaci´n de la FFT es m´s compleja y posee un cauce menos lineal o a que paralelizar. la o u PCM en este caso concreto. nuestros algoritmos de clasificaci´n o o en conjuntos de frecuencias y procesamiento de los conjuntos de frecuencias no han sido optimizados ni si quiera para una arquitectura gen´rica. SECCIONES DE CODIGO A OPTIMIZAR 93 SIMD (una instrucci´n. simplificamos todos los c´mputos de escalado en una o constante para evitar operaciones innecesarias. 1024 el valor umbral hasta el que recogeremos las frecuencias en bandas de frecuencias. Nos queda para cada canal un producto . } Como podemos observar. sin ramificaciones condicionales o incondicionales siquiera. optimizar uno cualquiera de los otros ıa dos procesos supondr´ la misma mejora como m´ a ınimo. Por contra. //d = (int) (((dest[0][i])/1024. El procesamiento de los conjuntos de frecuencias realiza una serie de operaciones ponderadas con un hist´rico para cada conjunto. est´ extra´ de una aplicaci´n real. y presentan al menos la e misma complejidad computacional que el c´lculo de la FFT optimizado. aunque optimizar la FFT supondr´ una mejora notable. para cada uno de los valores de salida que proporciona la FFT en cada canal. i++) { //dest[0][i] = ((int)sqrt(tmp out[0][i+1]))>>8. simplificando el flujo de operaci´n a un simple flujo o de c´mputo. barras[0][d]++. por lo que se har´ una doble mejora. Tambi´n presenta una clara estructura SIMD. N BAR el n´mero de a u conjuntos de frecuencia disponibles.´ 4. el otro par de procesos no requieren procesamientos internos aparte del computacional. Siendo OUT SIZE la longitud del vector de salida de la FFT m´s uno. y siendo barras el vector que representa los conjuntos de frecuencia. e incrementar el conjunto de frecuencia Ψλ en uno. calcular la banda de frecuencia λ.00024414 d = (int)(sqrt(tmp out[0][i+1])*0.2. El c´lculo que se realiza o a es.00024414). El algoritmo que empleamos en la FFT se supone optimizado para una arquitectura general. podemos escribir el algoritmo como sigue: for (i=0. ya que la complejidad computacional es semejante. convirti´ndose a e ambos procesos en una de las principales ocupaciones de la CPU. Por tanto.00024414). barras[1][d]++. Es claramente o un proceso SIMD. ya que como hemos comentado. y su proyecci´n en la VU0 e o es bastante inmediata.

ız o lo que supone reducir en una cuarta parte el n´mero de iteraciones.y vf7y. debemos tener en cuenta que la carga est´ repartida entre el a procesador MIPS y la FPU a la hora de realizar las operaciones de c´mputo que. Debido a la mayor velocidad y capacidad de c´mputo de la unidad vectorial. vf5w vwaitq vaddq. minimizando e la latencia asociada a la transferencia. Q vsqrt Q. debido unicamente a la impo´ sibilidad de realizarlas en paralelo. vf2y. vf4x vwaitq vaddq. Calcularemos los o dos canales tambi´n. 0x00( %2) vsqrt Q. Q vsqrt Q. vf2y. La mec´nica que seguiremos ser´ calcular las a a cuatro ra´ ıces cuadradas primero de forma secuencial. vf2x. o bien la unidad vectorial VU0. vf4y vwaitq vaddq.w vf6w. y luego multiplicaremos el registro resultado por la constante. ya que su unidad aritm´tica ız o e se limita a operaciones con n´meros enteros.x vf7x. optamos sin dudarlo por una implementaci´n ´ o ıntegra en la VU0 del procedimiento. 0x00( %5) # entrada 1 lqc2 vf5. Tras obtener el resultado de las cuatro ra´ a ıces cuadradas.00024414 # graba # carga entrada1 # sqrt # sqrt # sqrt . vf2x.94 ´ CAP´ ITULO 4. Como la unidad vectorial nos o permite realizar operaciones de cuatro en cuatro valores (no es el caso de la divisi´n ni o de la ra´ cuadrada). Q vsqrt Q. El procesaız ız dor MIPS no dispone de ra´ cuadrada como instrucci´n. calcularemos el post procesamiento de cuatro valores por iteraci´n. La instrucci´n VSQRT calcula la ra´ cuadrada de un n´mero flotante en 7 ciclos. como o sabemos. en o ız u contraposici´n de los 31 ciclos que tarda el COP1. ya que es una de las pocas operaciones que solo operan con un valor de forma simult´nea. las juntaremos en un registro. vf6.x vf6x. vf5x vwaitq vaddq. as´ como las mayores ventajas de procesamiento elaboo ı rado y paralelo que supone poder operar de cuatro en cuatro valores simultaneamente. 0x00( %0) # entrada 2 lqc2 vf4. Q vmul vf6. El problema reside principalmente en la ra´ cuadrada. vf1 sqc2 vf6. 0x00( %3) vsqrt Q. vf4z # carga 0.00024414 # carga vector 0 # carga entrada1 # sqrt # sqrt # sqrt # sqrt # resultados * 0. asm volatile (" lqc2 vf1. OPTIMIZACION DEL PROGRAMA SOBRE EL HARDWARE y una ra´ cuadrada.z vf6z.y vf6y. vf5z vwaitq vaddq. Por tanto. Hemos comprobado que la velocidad del COP1 (la FPU del MIPS) no es suficiente para realizar todo el n´mero de operaciones que u debe completar en un tiempo determinado. vf5y vwaitq vaddq. con la ganancia u de ciclos inherentes a los posibles fallos de predicci´n de saltos. aunque nos refiramos o e constantemente al MIPS. Q vsqrt Q. son pr´cticamente en su totalidad con n´meros flotantes. vf2w. vf2z. a u La ra´ cuadrada como instrucci´n la proporciona el coprocesador matem´tico ız o a COP1. 0x00( %4) lqc2 vf2. Q vsqrt Q. Para ello se a˜adi´ la FPU. para evitar tener que cargar la constante dos veces. encargada de u n o realizar todos los c´mputos con aritm´ticas flotantes.

lo que hace necesaria la secuencializaci´n del c´lculo de las ra´ o a ıces. la multiplicaci´n opera cuatro n´meros al mismo tiempo. Q Q. 0x00( %1) # graba "r" "r" "r" "r" "r" "r" (salidaASM). vf7. vf1 # resultados * 0. (c00ASM)). adem´s de que. ı u Aunque puede que a simple vista no se perciba. Figura 4. vf2w. Es una l´stima que o u a la instrucci´n de c´lculo de la ra´ cuadrada solo pueda operar con un valor de o a ız entrada a la vez. (alfaASM). como ız a a a se indica.1 muestra el flujo de datos y operaciones que realiza cada una de las implementaciones a lo largo del tiempo. (b) el flujo de datos perteneciente a la implementaci´n en la VU0. as´ como el n´mero de veces que debe realizarla. Q vf7. La Figura 4.00024414 vf7. (salida2ASM). (entrada2ASM).2.1: Flujo de datos que sigue la implementaci´n del clasificador de frecuencias o en conjuntos de frecuencias: (a) en el MIPS. como se comprueba en el diagrama del flujo. o .w vmul sqc2 " : : 95 vf7z. SECCIONES DE CODIGO A OPTIMIZAR vwaitq vaddq. hay que recordar que la instrucci´n de o la ra´ cuadrada en la VU0 es mucho m´s r´pida que la del MIPS. (entradaASM).z vsqrt vwaitq vaddq. vf2z.´ 4. vf4w # sqrt vf7w.

se satura el valor a un l´ ımite m´ximo. 0x00( %2) vmula.9 + barras[0][j]*alfa. campo a campo. . para cada una de las barras a mostrar. Las unidades vectoriales disponen de una instrucci´n de producto y suma a la vez. vf3 # max (actual.9 + barras*alfa lqc2 vf5. Procesamiento de los conjuntos de frecuencias Otra parte del c´digo que requiere gran procesamiento de c´lculo conforma la o a 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. vf4. Como hemos comentado. No es m´s a que la interpolaci´n entre el valor actual calculado y el valor anterior. que situaremos seg´n la altura m´xima posible que queramos darle a la barra. a u a La saturaci´n es necesaria para asegurarnos unos l´ o ımites en cuanto a valores que recibe el procedimiento de dibujar la barra. vf6. (entradaASM). realizamos una interpolaci´n entre el valor anterior y o el presente. (alfaASM). Tras calcular el valor actual. asm volatile lqc2 lqc2 lqc2 (" vf1. El c´digo en C que conforman o estas operaciones se muestra a continuaci´n: o // sin usar la VU0 Mis barras1[j−1]=ytamH[0][j]= ytamH[0][j]*0. vf5. La saturaci´n con el l´ o o ımite la haremos empleando las instrucciones de m´ximo y m´ a ınimo que ofrecen. El canal izquierdo es id´ntico salvo e el uso de la instrucci´n vmin en lugar de vmax para la cota de l´ o ımite. para realizar una o transici´n suave entre ambos y evitar posibles parpadeos al cambiar el dibujo de la o barra de forma muy brusca. que permiten rellenar un registro con el valor m´ximo de dos registros.2. 0x00( %4) # carga alfa vf3. Esta operaci´n la calcularemos una o o vez por canal. Mis barras2[j−1]=ytamH[1][j]= ytamH[1][j]*0. if (Mis barras1[j−1] < −LIMITE) Mis barras1[j−1] = −LIMITE. OPTIMIZACION DEL PROGRAMA SOBRE EL HARDWARE 4. vf1 vmax sqc2 " : : "r" "r" "r" "r" "r" "r" vf6. 0x00( %5) # tope # # # # carga barras barras*alfa carga ytamH ytamH*0. (topeASM)). ya que al situar los v´rtices fuera del ´rea de e a dibujo puede provocar errores en la visualizaci´n. cada uno de ellos ponderados por una constante. vf2 lqc2 vf4. 0x00( %0) (salidaASM).9 + barras[1][j]*alfa2. que emplearemos para realizar o el segundo producto y la interpolaci´n en un paso. tope) vf6.9 vf2. if (Mis barras2[j−1] > LIMITE) Mis barras2[j−1] = LIMITE.2. A continuaci´n a o pondremos el procedimiento para el canal derecho. 0x00( %3) # carga 0.96 ´ CAP´ ITULO 4. 0x00( %1) vmadd.xyzw vf6. (c90ASM).xyzw ACC. (ytamASM).

a no teniendo necesidad de detener el paralelismo de cuatro en cuatro datos en todo el flujo. Para ello. Al contrario de lo que ocurr´ en el procedimiento analizado en la secci´n ıa o 4.2: Flujo de datos que sigue la implementaci´n del procesamiento de conjuntos o de frecuencias: (a) en el MIPS. evitando la comprobaci´n valor a o por valor. Gracias a la compatibilidad para cuatro operandos u a simult´neos de las instrucciones de m´ximo y m´ a a ınimo. donde f es la fracci´n de c´digo que se puede mejorar. Figura 4. ANALISIS DE LA GANANCIA OBTENIDA 97 Como se aprecia en la Figura 4.2. y hacer un n´mero menor operaciones adem´s. y conseguimos adem´s reducir o a una operaci´n gracias a la ya mencionada operaci´n de producto-suma que ofrece la o o unidad vectorial. ya que operamos de cuatro en cuatro valores. y a la aceleraci´n de la o o o . obtenemos la expresi´n o a o (4. podemos realizar la saturaci´n o para los cuatro valores calculados simult´neamente.3.´ 4. tal como hemos visto en las asignatura de Arquitectura de los Computadores I [55]. vamos a intentar aplicar la Ley de Amdahl. en esta ocasi´n todas las operaciones o ız o que necesitamos realizar soportan cuatro operandos simult´neos sobre los que operar. Esto nos permite trabajar de cuatro en cuatro valores.1).1 debido a la operaci´n de ra´ cuadrada.2. 4.3. Si expresamos la Ley 1 como una formulaci´n matem´tica. An´lisis de la ganancia obtenida a Vamos a intentar calcular la ganancia que hemos obtenido con la optimizaci´n o realizada. (b) el flujo de datos perteneciente a la implementaci´n o en la VU0. Ley 1 (Amdahl) La mejora obtenida en el rendimiento de un sistema inform´tico al utilizar alg´n m´dulo o componente de ejecuci´n m´s r´pido a u o o a a esta limitada por la fracci´n de tiempo que se puede utilizar ese m´dulo o o o componente. se consigue un flujo m´s paralelo de ejecua ci´n.

y la ganancia m´xima te´rica. . y se obtendr´ la o a o a mejora que supone el uso de la VU0 frente al MIPS+FPU. tanto con u o la implementaci´n para el MIPS+FPU como para la VU0. ´ CAP´ ITULO 4.98 mejora. Para ello debemos calcular primero a o la aceleraci´n que produce el uso de la unidad vectorial VU0 en lugar de la FPU. intentando o minimizar la sobrecarga de las transiciones de DMA. Para calcular la aceleraci´n. que realizar´ un o o a n´mero considerable de veces los procedimientos sujetos de optimizaci´n. o procederemos a realizar una estimaci´n basada en el tiempo de c´lculo empleado para o a realizar las secciones optimizadas. memorias y fallos en la posible predicci´n de saltos. El n´mero de veces que o u se repite la operaci´n de c´lculo ha de ser suficientemente grande como para poder o a considerar que tiende al l´ ımite te´rico de su capacidad de procesamiento. Se calcular´ el tiempo de ejecuci´n de ambas. Dicha estimaci´n la realizamos en base a la siguiente o suposici´n: el tiempo necesario para realizar los c´lculos sujetos de optimizaci´n ya o a o mentados es el mismo est´n formando parte del todo de la aplicaci´n o bien se ejecuten e o como procedimientos independientes aislados del mismo. OPTIMIZACION DEL PROGRAMA SOBRE EL HARDWARE Ganancia = rendimiento con mejora T sin mejora 1 = = rendimiento sin mejora T con mejora (1 − f ) + f a (4. haremos un programa de diagn´stico.1) Intentaremos aplicar dicha formulaci´n para obtener la fracci´n de c´digo que o o o hemos paralelizado. o Dada la ausencia de herramientas de monitorizaci´n para las unidades vectoriales.

Cap´ ıtulo 5 Formato Ogg Vorbis En este cap´ ıtulo detallamos de forma exhaustiva el formato de codificaci´n vorbis. con tasa variable o de bits en la compresi´n (VBR).1. o as´ como los pasos necesarios para su decodificaci´n.1: Componentes del decodificador de Ogg Vorbis 99 . o El n´cleo principal de funcionamiento en la reproducci´n es la Transformada Disu o creta Modificada del Coseno (MDCT). considerando stereo. Est´n dise˜ados para poder ser truncados y que su a n a n decodificaci´n sea posible.1. 5. ni m´ximo ni un tama˜o esperado. puede consultarse un resumen [39] sobre o o la compresi´n. Los paquetes de datos que conforman el fichero no tienen tama˜o m´ n ınimo. o Aqu´ nos centraremos unicamente en la decodificaci´n del formato. Los componentes del decodificador se muestran en la Figura 5. cuadraf´nico y similares. y las partes de las que se compone ı o el formato de fichero en el que va encapsulado. y desde 1 hasta 255 canales digitales. El formato vorbis es tan flexible que no provee protecci´n de ninguna clase frente o a errores. Vorbis puede iniciar la decodificaci´n de cualquier paquete en cuanto el decoo dificador haya sido iniciado con las cabeceras de configuraci´n que especifica las proo piedades de la onda a producir. La capa de transporte que se encarga de detectar los fallos o es en nuestro caso ogg. Introducci´n al formato o El formato ogg vorbis puede codificar desde 8kHz a 192kHz. Figura 5. Para una breve ı ´ o introducci´n a la codificaci´n de Ogg Vorbis.

y cada floor puede elegir un codebook cualquiera cuando est´ codifio a cando/decodificando. Funcionamiento general del decodificador Configuraci´n del decodificador o Lo primero que debemos hacer. pero se prefiere siempre el tipo a 1. la codificaci´n entr´pica final se provee en codebooks externos y o o cada residuo se puede elegir de entre todos los codebooks disponibles codebooks: son abstracciones que realizan la decodificaci´n entr´pica y opcionalo o mente. Puede ser de o dos tipos: • Floor 0 usa una representaci´n LSP (Line Spectrum Pair) con amplitud en o decibelios y la frecuencia en la escala Bark (la escala de Bark va desde 1 a 24 Barks. en Vorbis I). FORMATO OGG VORBIS mode: consiste en la configuraci´n del tama˜o del frame. se usa el valor entero decodificado como ´ ındice en una tabla de vectores de salida. Se codifica usando vectores cuantizados conforme uno de los tres algoritmos espec´ ıficos de codificaci´n/decodificaci´n. necesarios en orden. Ambos tipos son sem´nticamente equivalentes. correspondientes a las 24 primeras bandas cr´ ıticas del o´ humano.2. numerados de 0 a 2. a Los valores codificados/decodificados por un floor se compactan mediante una codificaci´n entr´pica para ahorrar espacio. ıdo La escala se define en t´rminos de frecuencia en Hz entre el n´mero de e u Bark) • Floor 1 representa la curva como una representaci´n lineal a trozos intero polada de la amplitud en decibelios en una escala de frecuencia lineal. en lugar de emplear uno de rango completo. para . y el n´mero de mapping. Los detalles del o o algoritmo de empaquetamiento los especifica el residue en concreto. Es la representaci´n a baja resoo o luci´n del espectro de audio para el canal dado en el frame actual.1. La codificaci´n entr´pica es una absu o o tracci´n. el sexto canal ser´ solo el bajo. Vorbis usa tres paquetes de cabecera. usando para ello las tramas de cabecera. por lo que para este canal se usar´ un a a floor que solo codifica bajos. a o a 5. Una configuraci´n normalmente se o o o refiere a m´ltiples codebooks de la lista. ıa floor: uno de los pilares de la decodificaci´n. que especifica la configuraci´n a usar para u o la decodificaci´n y s´ o ıntesis de los paquetes de bajo nivel mapping: contiene una descripci´n de los canales y una lista de ’submapas’ sobre o canales para la codificaci´n decodificaci´n en grupo. debido a que es m´s estable entre frames y es considerado tambi´n computaa e cionalmente m´s sencillo que el tipo 0. es configurar el decodificador. la MDCT. el tipo de ventana o n (siempre 0 en Vorbis I).1. si es un audio en o formato 5.2. 5.100 donde: CAP´ ITULO 5. residue: es el detalle de la onda de audio una vez que se le ha restado el floor. Al igual que en los floor. Por ejemplo. el tipo de transformada (siempre 0. devolviendo dicho conjunto de valores. Los submapas indican el o o floor y el residue apropiado para la decodificaci´n. El codificador entr´pico empleado o en el Vorbis I es un ´rbol binario representado en c´digo Huffman est´ndar. lo que ser´ un gasto innecesario.

La relaci´n se a a o . Aunque n ser´ preferible hacer uso de la informaci´n redundante que utiliza vorbis. a a Una vez pasados los tres primeros. Los paquetes de cabecera son: Identification Header: contiene la identificaci´n de que es una trama vorbis. por lo que si llega uno de tipo cabecera. ya que como hemos dicho o antes. puede ser el autor. y el n´mero de canales u Comment Header: contiene la informaci´n de texto sobre la trama. Tal y ıa ıas como necesita la MDCT.5. que solapa ventanas. sin necesidad de leer el siguiente. y el tama˜o se n define por canal. el emparejamiento de canales puede hacer u que los vectores de residues obtenidos tras la decodificaci´n no se correspondan o directamente a los canales especificados. Vorbis usa la MDCT. Hay que tener en cuenta que cada canal se gestiona independiente.2. En Vorbis I puede ser cualquier potencia de dos entre 64 y 8192. como es la o informaci´n sobre el codificador. Setup Header: contiene informaci´n extensiva sobre la configuraci´n del COo o DEC.. FUNCIONAMIENTO GENERAL DEL DECODIFICADOR 101 la configuraci´n. La Figura 5. se pueden definir varios modos de decodificaci´n. El cuarto indica que es de audio. algunos vectores corresponder´n a magnitud o a ´ngulo. Como se puede apreciar. evitando la mayor´ de las anomal´ en las fronteras de los bloques. t´ ıtulo. album. ya que a o en las ventanas grandes guarda dos bits que especifican la forma de la ventana anterior y siguiente.2. todo paquete posterior a estos tres de cabecera.2 muestra un ejemplo de estos tipos de solapamiento. las ventanas se solapan un 50 % con la salida del bloque anterior. es un o paquete de audio. ser´ ignorado ese paquete. Para conocer que la siguiente ventana es peque˜a. Esto permite poder decodificar la ventana en ese mismo punto. o la frecuencia de muestreo. La informaci´n relativa a la MDCT se puede encontrar en un documento [48] de o la European Signal Processing Conference. Decodificaci´n de los residue: aunque el n´mero de vectores de residues debe o u ser igual que el n´mero de canales. Decodificaci´n de la forma de la ventana (solo ventanlas grandes): el frame o puede ser de uno de los dos tama˜os especificados durante la configuraci´n del n o CODEC. para mezclar un frame con el sieguiente.. En Vorbis I. Esto permite tambi´n alcanzar un mayor e grado de paralelismo. Cuando se emplea emparejamiento de canales. el resto deben ser siempre de tipo audio. y los campos asociados a la trama en s´ como o ı. Es un entero que se usa o como ´ ındice en la tabla de modos directamente. Pasos de la decodificaci´n o Los pasos a seguir en general son: Decodificaci´n del tipo de paquete: Vorbis I usa cuatro tipos de paquetes. a Decodificaci´n del modo: especifica el modo a usar. la actual.2. y un paquete con otro tipo deber´ ser ignorado. as´ como los codebooks VQ y Huffman necesarios para decodificar ı 5. n se puede tener el tama˜o de la ventana anterior. o Los primeros tres son los descritos antes. y la siguiente. Cualquier otro tipo est´ reservado. ambas ondas han de ser sim´tricas respecto al punto de e solapamiento entre los bloques.

o La codificaci´n de los vectores de residues se hace en el orden de los submapas. convertir la representaci´n polar en cartesiana. y puede cambiar de frame a frame o debido a la posibilidad de elecci´n de uno de los modos en cada frame. o ´ Tanto el floor de tipo 0 como el de tipo 1 generan un vector de salida de rango lineal/dominio lineal que ha de ser multiplicado escalarmente con el residuo espectral de rango lineal/dominio espectral. y que el producto directo ser´ suficiente para a una resoluci´n aceptable de espectro porque funciona casi siempre con ficheros o generados por el codificador de Xiph. En los floors en cambio se codifica en orden de los canales de audio. Puede ser cuando el floor se decodifica del paquete. Es la misma para o todas las parejas. y el espectro de audio debe representar un m´ ınimo de 120dB(∼ 21 bits con signo). Los floors pueden ser de ∼ 140dB (∼ 24 bits). o el vector resultante contiene el detalle espectral de cada uno de los canales de salida. especifica en la cabecera de configuraci´n. El emparejamiento se deshace en el orden y con los vectores especificados en la configuraci´n del mapping actual. produciendo el espectro de audio final de cada canal.2: Tipo de solapamiento entre ventanas consecutivas. FORMATO OGG VORBIS Figura 5. combinando la generaci´n y el producto escalar en un unico paso. Un error com´n es considerar que una representaci´n de punto fijo de 32 bits es u o suficiente para el floor y el residue. Calculando el producto escalar floor/residue: este paso es bastante abierto. o desde el 0 hasta el n − 1. el decodificador multiplica ambos vectores elemento a elemento. o se puede generar tras el paso anterior y aplicado directamente al residuo espectral obtenido. incluso cuando la salida es . Tras deshacerlo. Generando la curva de floor: se puede generar esta curva en el momento que el decodificador desee.102 CAP´ ITULO 5. Para cada canal de salida. Deshaciendo el emparejamiento de canales: el emparejamiento se realiza a parejas de vectores de residuos.

los datos situados entre las partes centrales de ambos frames es la onda PCM definitiva que ha de ser devuelta. tal como se ha explicado en el paso anterior. Si son de distinto n tama˜o. Por tanto. Cach´ del frame actual: el decodificador debe almacenar la parte derecha del e frame actual para solaparlo con el siguiente frame.3. modulaci´n por codificaci´n o o de pulsos).1.3. Si ambas eran de igual tama˜o. En la Figura ?? se puede apreciar la parte que se solapa. Devolviendo el audio final: como hemos dicho. cabecera de comentarios y cabecera de configuraci´n. de forma que el punto 3 de n 4 la ventana anterior est´ alineado con el punto 1 de la ventana actual. Se necesitan las tres o o . un audio PCM (Pulse Code Modulation. Para ello se emplea la inversa de la transformada discreta modificada del coseno presentada en el documento [48] mencionado con anterioridad.3. ya que n u falta solaparla con los frames de su alrededor empleando la ventana adecuada antes de que la MDCT pueda ser considerada ortogonal. ya que se usa para iniciar el decodificador. No se devuelve nada del primer frame. la parte de audio decodificada por completo es la parte contenida entre los centros de las ventanas solapadas. Para los residuos deben poder variar entre 0 y 140dB si el floor vale −140dB para alcanzar la escala completa. el producto escalar entre el floor y el residue ser´ un producto de 24 × 48 bits. Por tanto. u 5.´ ´ 5. 5. Un rango de 280dB es aproximadamente ∼ 48 bits con signo. o Transformada inversa del espectro: debemos aplicar una conversi´n para deo volver la se˜al espectral obtenida en una se˜al de dominio temporal nuevamente. ya que a´n no se ha enviado e u ning´n dato. En ese momento. Hay que tener en cuenta que la PCM resultante no es la se˜al final a´n. 5. por lo que se usar´ un tipo de dato a a de al menos 64 bits o una representaci´n de coma flotante. Decodificaci´n de la cabecera y configuraci´n del decodio o ficador Una trama Vorbis comienza con tres paquetes de cabecera: cabecera de identificaci´n. y entre −140 y 0dB si el floor vale 140dB.2. La cantidad devuelta n ha de ser siempre window blocksize(previous window) + window blocksize(current window) 4 4 desde el centro de la ventana anterior hasta el centro de la ventana actual. Configuraci´n del codec y decodificaci´n del pao o quete Introducci´n o Este documento es una gu´ para la decodificacion bit a bit del formato Vorbis I. se devuelve medio bloque. CONFIGURACION DEL CODEC Y DECODIFICACION DEL PAQUETE 103 de 16 bits. el offset del PCM es 0. ıa Se asume un conocimiento general del funcionamiento del formato Ogg Vorbis I. Superposici´n/adici´n de los datos: la salida del paso anterior se solapa y se o o a˜ade con la parte derecha de la ventana anterior. n n es decir. Despu´s del frame inicial. seg´n se e u 4 ve en el dibujo. los residuos deben oscilar entre −140 y 140dB si queremos ser capaces de alcanzar siempre la escala completa.3. no todo lo que se devuelve es parte solapada.

Esta cabecera se decodifica: 1. especialmente se puede considerar in´til en flujos VBR (variable bit rate). ’r’. Los campos u son de inter´s cuando son mayores de de cero. 2048. 0x69. Tanto el campo [audio channels] como el campo [audio rate] tienen que ser mayores de cero. 1024. FORMATO OGG VORBIS para decodificar seg´n lo acordado. [blocksize 1] ← 2uint4 9. Los campos de bitrate se usan solo como gu´ El campo [nominal bitrate] ıas. [bitrate lower ← int32 7. o o Cabecera de identificaci´n o La cabecera de identificaci´n es una cabecera corta de pocos campos empleados o para determinar que la trama es definitivamente un Vorbis. 0x73 (los caracteres ‘v’. Una condici´n de fin-de-paquete durante la decou o dificaci´n del primer o tercer paquete de cabecera hace la trama indecodificable. Si no se cumple alguna de estas condiciones. la secuencia 0x76. y proporcionar informaci´n o externa relevante sobre la trama de audio. [audio sample rate] ← uint32 4. 0x62. ’o’. [packet type] ← uint8 2. 0x6f. [blocksize 0] ← 2uint4 8. 128. Los valores finales permitidos para los blocksize son 64. Hay que tener en cuenta que [blocksize 0 tiene que ser menor o igual que [blocksize 1]. 4096 y 8192 en Vorbis I. [bitrate maximum] ← int32 5. e Si los tres campos est´n al mismo valor. 256. En la o decodificaci´n de la cabecera de comentarios produce un error no fatal. indica que o bien es una tasa constante a de bits por segundo. ’s’) La decodificaci´n contin´a seg´n el tipo de paquete.104 CAP´ ITULO 5. [bitrate nominal] ← int32 6. ’i’. El bit de [framing flag] tiene que ser distinto de cero. la de comentarios es la tipo 3 y la de configuraci´n es la tipo 5 (todos son o impares porque los paquetes con el bit a 0 son los paquetes de audio). o bien los l´ ımites est´n muy pr´ximos a una de tasa fija. comentario y configuraci´n. a o teniendo poco margen de detalle . o Decodificaci´n com´n de las cabeceras o u Cada paquete de cabecera comienza con los mismos campos: 1. 512. [vorbis version] ← uint32 2. 0x72. ’b’. [framing flag] ← 1 bit [vorbis version] debe ser ’0’ para ser compatible con este documento. Los paquetes de cabecera deben llegar en el orden: identificaci´n. La cabecera de identificaci´n o u u o es el tipo 1. [audio channels] ← uint8 3. el resultado es una trama indecodificable.

Si alguno no es cero. [vorbis floor count] ← uint6 +1 2. CONFIGURACION DEL CODEC Y DECODIFICACION DEL PAQUETE 105 Valores superiores o inferiores implican una trama VBR que obedece la limitaci´n o establecida Si no se ha asignado ning´n valor indica que el codificador no se molest´ en u o especular Cabecera de comentarios Es la encargada de proporcionar la informaci´n sobre la trama codificada en Vorbis. (tipo > 1) ⇒ la trama es indecodificable: CONDICION DE ERROR . estilo de m´sica. leer [vorbis time count] valores de 16 bits. las listas de las configuraci´nes de codebook. Finaliza con un bit de frame a ’1’. u 1. compositor. Grabar la configuraci´n de cada uno en orden. t´ u ıtulo de la canci´n van en esta o cabecera. para cada uno de los [vorbis floor count] floor: a) lee el tipo del floor b) [vorbis floor types][i] ← uint16 c) si (tipo = 0) ⇒ decodifica la configuraci´n del floor seg´n el tipo 0 y graba o u la configuraci´n en [vorbis floor configurations][i] o si no. Transformaci´n tiempo-dominio Est´n de relleno en Vorbis I. las configuraciones de los floor. o o en un vector de configuraciones [vorbis codebook configurations]. o o separada de ´sta. pues no es relevante para decodificar el sonido de la trama. e Cabecera de configuraci´n o EL codec de Vorbis es configurable en extremo: La cabecera de configuraci´n o contiene la informaci´n crucial de la configuraci´n del codec. o Floors Vorbis usa dos tipos de floors. [vorbis time count] ← uint6 +1 2. que deben ser cero. los o a valores deben leerse para mantener el sincronismo de la trama. si (tipo = 1) ⇒ decodifica la configuraci´n del floor seg´n el tipo 1 o u y graba la configuraci´n en [vorbis floor configurations][i] o ´ si no. necesaria para la deo o codificaci´n. en orden. configuraciones de los residuos. es una condici´n de error y la trama es indecodificable. La Decodificaci´n de la o o cabecera procede de la siguiente forma: Codebooks El proceso de configuraci´n relativa a los codebooks es el mostrado a o continuaci´n: o 1. 1. No obstante. o Campos como el autor. [vorbis codebook count] ← uint8 +1 2. Decodificar [vorbis codebook count] codebooks en orden tal y como se describe en la secci´n de codebooks. configuraci´n del mapeado de canales y de la confio guraci´n de los modos. la decodificaci´n de la cabecera est´ constitu´ o a ıda de forma que es capaz de decodificar seg´n el tipo apropiado. Contiene. Los detalles de decodificaci´n de esta cabecera van reflejados en otra secci´n. las o o configuraciones de la transformada tiempo-dominio.3.´ ´ 5.

e 1. la trama es indecodificable e) lee 2 bits. [vorbis mapping count] ← uint6 +1 2. respectivamente.106 CAP´ ITULO 5. [vorbis residue count] ← uint6 +1 2. con los mapeados de canales PCM impl´ ´ ıcitos. 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. FORMATO OGG VORBIS Residuos Vorbis usa tres tipos de residuos. a a Si ambos son iguales o el de magnitud o ´ngulo es mayor que a [audio channels]−1. si es distinto de cero. la trama es indecodificable 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)) ⇒ condici´n de o error: trama indecodificable g ) para cada submapa [j] de los [vorbis mapping submaps]. lee el n´mero de floor y residuos a usar para decodificarlo: u • lee y descarta 8 bits (la configuraci´n tiempo-dominio no usada) o . la decodificaci´n de sus cabeceras es o id´ntica. y gr´bala en [vorbis residue configurations][i] a ´ si no. 1. (tipo = 0) ⇒ a) bandera booleana ← 1 bit b) si est´ activa ⇒ [vorbis mapping submaps] ← uint4 +1 a si no est´ activa ⇒ [vorbis mapping submaps] ← 1 a c) bandera booleana ← 1 bit d) si est´ activa ⇒ se usa mapeado de canales por polos cuadrados: a • [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 representar´ la maga nitud y el canal que representar´ el ´ngulo. 1. ´ 2) ⇒ decodifica la configuraci´n de residuos seg´n el o o u tipo. Vorbis I usa o un tipo unico de mapeado. (tipo > 2) ⇒ la trama es indecodificable: CONDICION DE ERROR Mapeado Los mapeados se usan para configurar pipelines espec´ ıficos para la codificaci´n multicanal de audio con varias aplicaciones de mapeado de canal. para cada [i] de los [vorbis mapping count] mapeados: leer el tipo: un uint16 (no hay raz´n para almacenarlo) o si (tipo = 0) ⇒ trama indecodificable si no.

lee 1 bit como bandera de frame. • [vorbis mapping submap residue][j] ← uint8 • verifica que el n´mero de residuo no es mayor que el m´ximo de u a los configurados para la trama. selecci´n y configuraci´n de ventana {´sta se usar´ luego en la MDCT inversa}: o o e a . comprobar que sea 0 (audio) 2. todos los paquetes de una trama Vorbis I son de audio. Si (bandera no activa) ⇒ error en el frame. f ) [vorbis mode configurations][i] ← esta configuraci´n o 3. modo y ventana o 1. El decodificador debe ignorar el paquete y no intentar decodificarlo a audio.3. CONFIGURACION DEL CODEC Y DECODIFICACION DEL PAQUETE 107 • [vorbis mapping submap floor][j] ← uint8 • verifica que el n´mero de floor no es mayor que el m´ximo de los u a configurados para la trama. la decodificaci´n de la cabecera de o configuraci´n se ha completado. 4. Si lo es. la trama es indecodificable. [mode number] ← ilog([vorbis mode count]-1) 3. 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. Decodificaci´n y s´ o ıntesis de paquetes de audio Tras los tres paquetes de cabecera. si ([vorbis mode blockflag] no activa) ⇒ [n] ← [blocksize 0] si no. ([vorbis mode blockflag] activa) ⇒ [n] ← [blocksize 1] 4. [vorbis mode mapping] no debe ser mayor que el m´xia mo de los mapping en uso. Lo primero que hay que hacer con un paquete de audio es comprobar que sea del tipo de audio. Si lo es. o 5.´ ´ 5.3. la trama es indecodificable h) [vorbis mapping configurations][i] ← esta configuraci´n de mao peado Modos 1. un paquete de un tipo distinto de audio cuando se espera un paquete de audio es signo de corrupci´n de trama o de una trama que no sigue las o especificaciones. [vorbis mode count] ← uint6 +1 2. Cualquier valor ilegal convierte a la trama en indecodificable. Decodificaci´n del tipo de paquete. [packet type] ← 1 bit.3. trama indecodificable Trase leer las descripciones de los modos.

. La generaci´n de la ventana es como se indica a continuaci´n: o o 1. [left window start] 3. . [window center] ← [n]/2 2. ([previous window flag] activa) ⇒ la mitad izquierda de la ventana es de tama˜o normal n 4) si ([next window flag] no activa) ⇒ la mitad derecha de la ventana es una mezcla de ventana larga y corta si no. 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.108 CAP´ ITULO 5. ([vorbis mode blockflag] no activa) {ventana corta} ⇒ la ventana solapada siempre ser´ corta a x Las ventanas de Vorbis usasn siempre la misma curva envolvente y = sin(2πsin2 ( n )). para [i] en el intervalo [left window start].5 )) π 2 .[left window start]−1 ←0 6...[left window end]-1 ⇒ window ventana[i] ← sin(2πsin2 ( [i]−[left[left n]∗start]+0. ventana0. FORMATO OGG VORBIS 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. 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. pero un solapamiento de ventanas de distintos tama˜os pueden afectar a la forma final n de la curva. ([next window flag] activa) ⇒ la mitad derecha de la ventana es de tama˜o normal n si no.

Decodificaci´n del floor o Asumimos desde ahora que la decodificaci´n usa el modo [mode number] del veco tor de configuraci´n [vorbis mode configurations] y el mapeado [vorbis mode mapping] o tomado del vector de configuraciones de mapeado [vorbis mapping configurations].. ventana[right window start]. el emparejamiento de canales puede producir una mezcla de un vector nulo y otro no nulo para producir dos vectores no nulos. guarda la informaci´n decodificada del canal para la s´ o ıntesis posterior 5. si ([vorbis floor types][floor number] = 0) ⇒ decodifica el floor para el canal [i] seg´n el algoritmo del floor 0 u si no.5 + π )) [right n]∗ π 2 2 9. Las curvas floor se decodifican una por una. y saltando la fase de suma/solapamiento. [submap number] ← [vorbis mapping mux][i] 2. Si ocurre pasado este punto. . .. Si algunos vectores se usan y a o otros no. El vector de residuos de ese vector no est´ codificado en la trama. para [i] en el intervalo [right window start].´ ´ 5. evitando una complicaci´n. si (floor decodificado = ’no usado’) ⇒ [no residue][i] ← verdad si no. si ([vorbis floor types][floor number] = 1) ⇒ decodifica el floor para el canal [i] seg´n el algoritmo del floor 1 u 4.[right window start]−1 109 ←1 8.[vorbis mapping coupling steps]−1 ⇒ 1. (floor decodificado = ’no usado’) ⇒ [no residue][i] ← falso Una condici´n de fin-de-paquete durante la decodificaci´n deber´ resultar en una decoo o ıa dificaci´n de todo ceros en los canales de salida.[n]−1 ←0 Una condici´n de fin-de-paquete hasta este momento deber´ ser considerado un o ıa error y descartar el paquete entero de la trama. para cada floor [i] de [vorbis mapping mux] ⇒ 1. . para cada [i] en el intervalo 0 . si (([no residue] de [vorbis mapping magnitude][i] [no residue] de [vorbis mapping angle][i] ) = falso) ⇒ ambos tienen que ponerse a falso . CONFIGURACION DEL CODEC Y DECODIFICACION DEL PAQUETE 7. . [floor number] ← [vorbis submap floor][submap number] 3. ventana[left window end].. lo que indica que ese vector final ser´ un vector lleno e a de ceros (lo que implica un floor de cero).[right window end]-1 ⇒ ventana[i] ← sin(2πsin2 ( [i]−[right window start]+0.. se puede considerar un hecho posible. o Propagaci´n de los vectores no nulos o Un resultado posible de la decodificaci´n del floor es que un vector espec´ o ıfico est´ marcado como ’no usado’. en el orden de los canales.3.

FORMATO OGG VORBIS A diferencia de los floors. La longitud decodifie cada correcta por vector es [n]/2 6. [ch] ← 0 2.[audio channels] ⇒ • si ([vorbis mapping mux][j] = [i]) ⇒ a) el vector de residuos para el canal [j] se iguala al vector de residuos decodificados [ch] b) [ch]++ Emparejamiento inverso para cada [i] en el intervalo [vorbis mapping coupling steps]-1.110 Decodificador de residuos CAP´ ITULO 5. . los residuos u se decodifican en orden de submapas. . para cada canal [j] en orden en el intervalo 0 . [ch] ← 0 7. 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. [residue number] ← [vorbis mapping submap residue][i] 4. [angle vector] ← [vorbis mapping angle][i] 3. para cada [i] 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. . 0 ⇒ 1. .[vorbis mapping submaps]-1 ⇒ 1. seg´n u el tipo [residue type]. para cada [j] en orden en el intervalo 0 . decodificar los [ch] vectores usando el residuo [residue number]. [residue type] ← [vorbis residues types][residue number] 5. ([M] > 0) ⇒ ◦ si ([A] > 0) ⇒ a) [new M] ← [M] . . pasando tambi´n el vector [do not decode flag] e para indicar qu´ vectores no deben ser decodificados. . . ([no residue][j] = falso) ⇒ [do not decode flag][channels in bundle] ← no activo • [ch]++ 3. que se decodifican seg´n el orden del canal. [magnitude vector] ← [vorbis mapping magnitude][i] 2.

pon los valores [M] de [magnitude vector] a [new M] 5.ps. tenemos que sintetizar la curva floor del floor decodificado. y la multiplicaci´n directa de ambos es suficiente para un o nivel de detalle del espectro aceptable en todos los casos porque parece funcionar con el codificador de referencia de Xiph. consistente en la parte solapada unicamente. . Hay que mentar un aspecto de este producto escalar. La parte solapada obtenida del solapao miento del frame anterior y del actual son los datos finalizados que deben ser devueltos por el decodificador. CONFIGURACION DEL CODEC Y DECODIFICACION DEL PAQUETE b) [new A] ← [M]+[A] si no. los vectores resultantes son los espectros de longitud [n]/2 de cada canal. o 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 est´ alineada con el punto e 1/4 de la actual (tal y como se ilustr´ al inicio). un audio PCM. ([A] > 0) ⇒ a) [new A] ← [M] b) [new M] ← [M]-[A] 4. Cuando se ´ solapa una ventana corta y otra larga. 2 No se devuelve datos del primer frame. se usa para iniciar el motor de decodificaci´n. MDCT inversa Convierte nuevamente el vector espectral de cada canal al dominio de tiempo.´ ´ 5. Hay que tener en cuenta que la longitud del vector para el c´lculo a del floor es de [n]/2. cosa que no supone un da˜o a la ortogonalidad de la transformaci´n. un error frecuente en una implementaci´n de punto fijo es asumir que una representaci´n de 32 bits de punto o o fijo para floor y residuos. el desplazamiento de la salida de PCM es 0 (ya que a´n no o u se han devuelto dato alguno). Estos datos desde el centro de la ventana anterior hasta el centro de la actual.3. debemos multiplicar cada elemento de la curva de floor por cada elemento del vector de residuos de dicho canal. Simn o plemente hay que prestar atenci´n a la porci´n devuelta. En caso de tener ventanas del mismo tama˜o.com/resource/docs/ o a ps/eusipco_corrected. Para cada canal. hasta el centro de la ventana actual (elemento 2 windowzise − 1 inclusive). mediante la inversa de la Transformada Discreta Modificada del Coseno (MDCT). pon los valores [A] de [ang vector] a [new A] Producto escalar 111 Para cada canal. El resultado es el producto escalar de los vectores de floor y residuos de cada canal. la cantidad de datos a devolver o o es: window blocksize(previous window) + window blocksize(current window) desde el centro de la 4 4 ventana anterior (elemento windowsize ).iocon. La ventana usada por la MDCT es la ventana que se determin´ anteriormente. Tras el primer frame. la cantidad de data a n devolver es de medio bloque. seg´n u el tipo de paquete. parte de los datos devueltos no est´n realmente a solapados. La informaci´n m´s detallada aparece en www.

tambi´n coo e nocido como LSF por Line Spectral Frecuency) para codificar una curva envolvente de espectro de forma precisa como la frecuencia de respuesta del filtro LSP. central. FORMATO OGG VORBIS El formato Vorbis I solo especifica un tipo de mapeado de canales. Decodificaci´n de la cabecera o La cabecera dispone de los siguientes campos en el mismo orden que se mostrar´ a a continuaci´n. trasero izquierdo. con orden: izquierdo. el e mapeado de canales est´ impl´ a ıcitamente definido como sigue para las aplicaciones estandar de audio: un canal: la trama es monof´nica o dos canales: la trama es est´reo. frontal central. frontal derecho. . float.1. derecho cuatro canales: la trama es envolvente cuadraf´nico.112 Orden de canales de salida CAP´ ITULO 5. y se indicar´ si es necesario un procesamiento o condici´n adicional. . con orden: izquierdo. Se puede convertir de una a otra sin problema. . frontal derecho. ). Futuros mapeados de canales (como el de tres y cuatro canales Ambisonicos) har´n uso de otro tipo de mapeado distinto del 0. LFE (efectos de baja frecuencia) m´s de seis canales: la aplicaci´n define el uso de cada canal y su orden a o Las aplicaciones que usen Vorbis para prop´sito espec´ o ıfico pueden definir el mapeado de canales como prefieran. Formato Floor 0 La configuraic´n de este decodificador consiste en un campo de seis enteros y o una lista de codebooks VQ para codificar/decodificar los coeficientes del filtro LSP empleado en cada frame. o a [floor0 order]: uint8 . o a o Los tipos de datos se expresar´n con una u si es sin signo (unsigned). Floor 0: configuraci´n y decodificaci´n o o Introducci´n o Este tipo de floor usa una representaci´n LSP (Line Spectral Pair.2. En ´l.1. seguido del a identificador del tipo de dato (int. a 5. con orden: frontal izquiero do. Es una representaci´n equivalente al tradicional filtro de respuesta infinita de todos los polos o usada en codificaci´n lineal predictiva. trasero derecho cinco canales: la trama es envolvente de cinco canales. Si es un vector o array se expresar´ debidamente. derecho e tres canales: la trama es 1d-envolvente. trasero izquierdo. 5. frontal central.4. y expresando su longitud en bits a continuaci´n. con orden: frontal izquierdo. frontal derecho. o 5.4.4. con orden: frontal izquierdo. trasero derecho seis canales: la trama es envolvente 5. trasero derecho. trasero izquierdo.

[floor0 rate].4. si ([booknumber] > mayor n´mero de decodificaci´n del codebook)) ⇒ u o paquete indecodificable 4. [coefficients] es vector vac´ de 0 elementos ıo 2. si (longitud de [coefficients] < [floor0 order]) ⇒ continuar por el paso 4 9. [floor0 amplitude offset] o [floor0 number of books] son menores de 0. [floor0 bark map size]. a o Muchas de las etapas siguientes de decodificaci´n no se realizan para un canal o no usado. [lastval] = 0 5. a˜ade el valor escalar last a cada escalar de vector [temp vector] n 7. y entonces calcular la curva floor. FLOOR 0: CONFIGURACION Y DECODIFICACION [floor0 rate]: uint16 [floor0 bark map size]: uint16 [floor0 amplitude bits]: uint6 [floor0 amplitude offset]: uint8 [floor0 number of books]: uint4 y a˜adir 1 al valor n 113 si [floor0 order]. que se define como la respuesta en frecuencia del filtro LSP decodificado. la trama no se puede decodificar array [floor0 book list]: lista de [floor0 number of books] uint8 Una situaci´n de fin-de-trama en alguno de estos bits convierte a la trama en o indecodificable. Decodificaci´n del paquete o Para generar la curva floor0 de un paquete hay primero que decodificar la amplitud de la curva y los floor0 order coeficientes LSP de la trama. fin Ahora veremos algunas propiedades de la decodificaci´n: o Un valor [amplitude] de 0 har´ que se devuelva un c´digo indicando que ´ste a o e canal no se usa en este frame (la salida del canal ser´ una sucesi´n de ceros). La decodificaci´n del paquete se hace de la siguiente forma: o [amplitude]: uint de [floor0 amplitude bits] bits si ([amplitude] > 0) ⇒ 1.´ ´ 5. si alg´n elemento del array [floor0 book list] es mayor a u que el m´ximo codebook de esa trama es una condici´n de error y hace tambi´n a o e indecodificable a la trama. [booknumber] ← leer un uint de ilog ([floor0 number of books]) bits 3. [floor0 amplitude bits]. Adem´s. . vector [temp vector] ← leer vector de la trama usando [booknumber] como n´mero del codebook en el contexto VQ u 6. concatena [temp vector] al final del vector [coefficients] 8.

114

CAP´ ITULO 5. FORMATO OGG VORBIS Si se encuentra una condici´n de fin-de-paquete durante la decodificaci´n, simo o plemente se marcar´ el canal como no usado, al igual que en el caso anterior. a El n´mero del book usado para decodificar se podr´ haber guardado en flujo u ıa de datos en ilog([floor0 number of books]-1) bits, pero la especificci´n o anterior es correcta, y los valores mayores que el book m´ximo posible est´n a a reservados. El n´mero de elementos le´ u ıdos 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 floor que est´ siendo decodificado tiene a 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 condici´n de o error, y hay que tener cuidado de no permitir un desbordamiento del buffer en la decodificaci´n. Los valores extra no se usan y pueden ser ignorados o descartados. o

C´lculo de la curva a Dada un entero [amplitude] y un vector [coefficients] de la decodificaci´n de un paquete, y [floor0 order], [floor0 rate], [floor0 bark map size], o [floor0 amplitude bits] y [floor0 amplitude offset] de la configuraci´n del o decodificador, y un vector de salida de tama˜o [n] especificado en el proceso de den codificaci´n, calcularemos un vector de floors como salida. o Si [amplitude] es cero, devolveremos un vector de [n] elementos con el valor escalar 0. En caso contrario, supondremos las siguientes definiciones para el vector a sintetizar: bark(x) = 13,1atan(,00074x) + 2,24atan(,0000000158x2 ) + ,0001x   [floor0 bark map size] − 1,   bark( [floor0 rate] · i [floor0 bark map size] )· 2 · [n] bark(,5 · [floor0 rate])

mapi = m´ ınimo for i = 0 . . . [n] − 1   

´ 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 c´lculo a de la curva LSP de salida [output] en una escala logar´ ıtmica (dB) de amplitud. 1. [i] ⇒ 0 2. si ([coefficients] es impar) ⇒ calcular [p] y [q] seg´n: u
[floor0 order]−3 2

p = (1 − cos (ω))
j=0

2

4(cos([coefficients]2j+1 ) − cos(ω))2

[floor0 order]−2 2

q = ,25
j=0

4(cos([coefficients]2j ) − cos(ω))2

´ ´ 5.5. FLOOR 1: CONFIGURACION Y DECODIFICACION 3. sino ([coefficients] es par) ⇒ calcular [p] y [q] seg´n: u (1 − cos(ω)) p= 2
[floor0 order]−2 2

115

4(cos([coefficients]2j+1 ) − cos(ω))2
j=0

(1 + cos(ω)) q= 2

[floor0 order]−2 2

4(cos([coefficients]2j ) − cos(ω))2
j=0

4. calcular [linear floor value] de acuerdo con:

e
5.5.
5.5.1.

[amplitude] ∗ floor0 amplitude offset √ (2[floor0 amplitude bits] − 1) · 2 p + q

Floor 1: configuraci´n y decodificaci´n o o
Introducci´n o

Este m´todo usa una representaci´n de funci´n a trozos lineales para codificar una e o o curva envolvente del espectro. La representaci´n dibuja esta curva de forma mec´nica o a en un eje lineal de frecuencia y un eje logar´ ıtmico (en dB) de amplitud. El algoritmo empleado para representarla es similar al algoritmo de Bresenham.

5.5.2.
Modelo

Formato Floor 1

La curva espectral queda representada como una serie de segmentos de l´ ınea. La s´ ıntesis construye una curva floor usando predicci´n iterativa en un proceso aproximao damente equivalente a la siguente descripci´n simplificada: o el primer segmento (caso base) es una l´ ınea 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 floor espectral a calcular. el paso de inducci´n elige un punto x new en un segmento l´gico existente y o o produce una y new en ese punto, para el valor y en x new, y la diferencia decodificada del paquete del flujo de datos. el c´lculo del floor produce dos nuevos segmentos de l´ a ınea, 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´n cambio al valor de la amplitud en u x new, de forma que refinamientos posteriores tambi´n usar´n x new como valor e a del extremo. el paso de inducci´n se repite, usando una lista de valores de x especificada en o la cabecera del codec en la iniciaci´n del floor 1. El c´lculo se completa en el o a ultimo valor de la lista de valores para x. ´

116

CAP´ ITULO 5. FORMATO OGG VORBIS

Ahora veremos un ejemplo gr´fico para entender con mayor facilidad los puntos a anteriores. Supongamos una configuraci´n del floor con [n] = 128. La lista de valores elegidos o de X en orden incremental es 0, 16, 32, 48, 64, 80, 96, 112 y 128. Los valores de los intervalos van en el orden siguiente: 0, 128, 64, 32, 96, 16, 48, 80 y 112. Para estos valores, los valores Y que se han decodificado de un paquete han sido 110, 20, −5, −45, 0, −25, −10, 30 y −10. Hacemos el floor de la siguiente forma, primero empezamos pintando la primera l´ ınea, y calcularemos el valor de new Y para la primera coordenada X del vector, teniendo en cuenta el valor de Y que decodificamos del paquete, como se ilustra en la Figura 5.3

Figura 5.3: Reconstrucci´n del floor con dos puntos, y c´lculo de la diferencia en Y o a con respecto a la estimaci´n inicial. o Ahora dibujaremos las nuevas l´ ıneas para reflejar la correci´n de new Y, y repetio remos el paso para los valores de X de 32 y 96, como vemos en la Figura 5.4.

Figura 5.4: Realizamos la correcci´n de la Y anterior y calculamos las nuevas para 32 o y 96. Aunque el valor de new Y para la coordenada 96 no ha cambiado de valor, se seguir´ usando como el extremo de los refinamientos asociados a esa parte de la curva. a El siguiente paso ser´ continuar con los subintervalos producidos, ilustrado con la ıa Figura 5.5. Se contin´a de la misma forma hasta completar todas las coordenadas del vector u de valores para X, representado en la Figura 5.6:

5. El o a a algoritmo real parte el c´lculo de los valores de Y y el trazado de la curva en dos pasos a con modificaciones sobre el algoritmo anterior. como se ver´ m´s adelante. para eliminar la acumulaci´n del error o producido por el redondeo/truncado de enteros. Decodificacion de la cabecera En la cabecera del paquete se almacena una lista de los valores X del floor en formato entre (usado en orden de lista durante la decodificaci´n del paquete y la o s´ ıntesis). tenemos la reconstrucci´n de la o curva original. Esta lista se parte en dos trozos.6: Cuando todos los valores se han calculado. o Una clase de partici´n consiste en un ancho de representaci´n del vector (el n´mero o o u de valores Y que la partici´n codifica a la vez).3.5.´ ´ 5. Se usa un algoritmo m´s eficiente con un comportamiento de redondeo a entero a cuidadosamente definido para la decodificaci´n real. El e o mecanismo de principal/sublcase est´ pensado para ser usado como una representaci´n a o . un valor de subclase que representa o el n´mero de books entr´picos alternativos que puede usar la clase de partici´n para u o o representar los valores Y. cada uno de los cuales se asigna a una clase de partici´n. 5. corrigiendo cuando es necesario. Las posiciones 0 y [n] de X son impl´ o ıcitas y no pertenecen a ninguna partici´n expl´ o ıcita o clase de partici´n. la lista de [subclass] books y un book principal usado para codificar qu´ books fueron elegidos para la representaci´n de un paquete dado. Figura 5.5: Proseguimos refinando la curva con los valores asociados. FLOOR 1: CONFIGURACION Y DECODIFICACION 117 Figura 5.

[floor1 partitions] − 1 itera [j] en el intervalo 0 . vector [floor1 X list][0] ← 0 9. [rangebits] ← uint4 8. . . [maximum class] = max([floor1 partition class list]) 5. . e . itera [i] en el intervalo 0 .118 CAP´ ITULO 5. [maximum class] = 0 3. o 1. [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 . FORMATO OGG VORBIS flexible en cascada. . . itera [i] en el intervalo 0 . vector [floor1 X list][1] ← 2[rangebits] 10. . fin Una condici´n de fin de paquete mientras se est´ leyendo en cualquier parte duo a rante la configuraci´n del floor 1 hace que la trama sea indecodificable. itera [i] en el intervalo 0 . . [floor1 partitions] − 1 [floor1 partition class list][i] ← uint4 4. Adem´s. Los pasos para obtener la informaci´n asociada de cabecera del paquete se indican o a continuaci´n. 2[floor1 class subclasses][i] −1 • array [floor1 subclass books][i]. [floor1 class dimensions][i] − 1 • vector [floor1 X list]([j]+[floor1 como entero sin signo values]) ← leer [rangebits] bits floor1 values] = [floor1 values] + [floor1 class dimensions][i] 12. la o a existencia de un valor del vector [floor1 class masterbooks] o del vector [floor1 subclass books] superior al ´ ındice m´ximo del codebook configurado paa ra esa trama es una condici´n de error que convierte a la trama en indecodificable o tambi´n. .[j] ← uint8 −1 6. mientras se mantiene el uso de los codebooks solo en un contexto escalar. [floor1 multiplier] ← uint2 +1 7. . . [floor1 partitions] ← uint5 2. [floor1 values] ← 1 11.

[nonzero] ← 1 bit como booleano Si [nonzero] no est´ activado. . itera [i] en el intervalo 0 . FLOOR 1: CONFIGURACION Y DECODIFICACION 119 5. Decodificaci´n del paquete o La decodificaci´n comienza comprobando el flag [nonzero]: o 1.4.[cval] [csub]) si ([book] < 0) ⇒ • [floor1 Y]([j]+[offset]) ← lee del paquete usando el codebook [book] en contexto escalar si no. Si se alcanza un fin-de-paquete en alguna de las operaciones de lectura anteriores. Suponiendo que [nonzero] est´ activado. indica que este canal no contiene energ´ de audio a ıa en ese frame. . la decodificaci´n del floor devolver´ un estado de ’no o a usada’ como si el bit [nonzero] no hubiera estado activo al inicio de la decodificaci´n. [floor1 Y][0] ← leer ilog([range]-1) bits como entero sin signo 3.´ ´ 5. o El vector [floor1 Y] contiene los valores de la decodificaci´n del paquete necesarios o para la sintetizaci´n de la floor1. . [book] < 0 ⇒ • [floor1 Y]([j]+[offset]) ← 0 h) [offset] ← [offset] + [cdim] 6. (Devolver un estado de ’no usado’ es distinto de decodificar un floor en el que todos los puntos est´n situados en a la amplitud m´ ınima. 64}([floor1 multiplier]−1) 2. La decodificaci´n inmediatamente devuelve un estado indicando que esta o curva floor (y por tanto este canal) no se usa en el frame. o . la decodificaci´n es: a o 1. 86. . [offset] ← 2 5. [floor1 partitions] − 1 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 . 128. [range] ← {256.5.5. fin Una condici´n fin-de-paquete durante la decodificaci´n de la curva deber´ ser o o ıa considerada una ocurrencia puntual. [floor1 Y][1] ← leer ilog([range]-1) bits como entero sin signo 4. que suele ser aproximadamente −140dB). [cdim] − 1 [book] ← [floor1 subclass books]([class].

. C´lculo de la curva a El c´lculo de la curva se divide de forma l´gica en dos pasos.120 CAP´ ITULO 5. [range] ← {256. [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. o 1. FORMATO OGG VORBIS 5. 86.5. [i]) c) [predicted] ← render point ([floor1 X list][low [floor1 X list][high neighbor offset] . [i]) b) [high neighbor offset] ← high neighbor([floor1 X list]. . estos puntos se saltan de forma condicional durante el c´lculo final del paso segundo. o S´ ıntesis de los valores de amplitud Desenvolver los valores (siempre mayores o iguales a 0) del paquete a valores de diferencias +/-. [floor1 Y][high neighbor offset] . ([val] < [room]) ⇒ • si ([val] es impar) ⇒ neighbor offset] . [floor1 Y][low neighbor offset] . ([hiroom] > [lowroom]) ⇒ ◦ [floor1 final Y][i] ← [predicted] − ([val] − [lowroom]) − 1 si no. La no implementaci´n de un algoritmo estrictamente equivalente puede resultar en o graves errores de decodificaci´n. El primer paso obtiene a o las amplitudes Y finales de la codificaci´n. . se advierte a los implementadores que siguan la especificaci´n fielmeno te. [floor1 values] − 1 a) [low neighbor offset] ← low neighbor([floor1 X list]. [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. Aunque los valores con diferencias de cero se usan en la predicci´n iterativa para calcular los valores finales de o Y. El segundo paso traza las l´ ıneas de curvas. a Saltar los valores de diferencia cero permite un ajuste m´s preciso de la curva. 128. y ahora se aplica la predicci´n lineal. usando los valores diferencia tomados del o flujo de datos. a Aunque algunos aspectos del algoritmo siguiente pueden parecer optimizaciones inconsecuentes.5. itera [i] en el intervalo 2 . 64}([floor1 multiplier]−1) 2.

cambiar su valor por el de [floor1 inverse dB static table][v] 6. ([val] = 0) ⇒ • [floor1 step2 flag][i] ← no activada • [floor1 final Y][i] ← [predicted] 3. [floor1 X list]’. . ordenamos los valores de [floor1 X list] y aplicamos la misma permutaci´n a los elementos de los otros dos vectores. [floor1 step2 flag][1] ← activada 5. as´ como de los valores de [floor1 multiplier] ı y [floor1 values]. [floor1 final Y][1] ← [floor1 Y][1] 7. La s´ ıntesis de la curva del floor 1 hace uso de los vectores [floor1 X list]. [floor1 final Y][0] ← [floor1 Y][0] 6.[hx]. FLOOR 1: CONFIGURACION Y DECODIFICACION ◦ [floor1 final Y][i] ← [predicted] − (([val] − 1) /Z 2) si no. para que o se siga correspondiendo elemento a elemento de forma correcta. Por tanto. o [floor1 final Y] y [floor1 step2 flag] en tres vectores nuevos.5.´ ´ 5. [floor1 final Y]’ y [floor1 step2 flag]’ de acuerdo a los valores ordenados de forma ascendente en [floor1 X list]. [floor1 step2 flag][0] ← activada 4.[hy].[floor]) c) si ([hx] > [n]) ⇒ truncar [floor] a [n] elementos 5.[floor]) [lx] ← [hx] [ly] ← [hy] b) si ([hx] < [n]) ⇒ render line([hx]. [hx] ← 0 2. [lx] ← 0 3.[n].[hy]. itera [i] en el intervalo 1 . La decodificaci´n comienza ordenando los elementos de los vectores [floor1 X list]. . Tras esto. fin . [floor1 values] − 1 a) si ([floor1 step2 flag] activa ) ⇒ [hy] ← [floor1 final Y][i] ∗ [floor1 multiplier] [hx] ← [floor1 X list][i] render line([lx]. ([val] es par) ⇒ ◦ [floor1 final Y][i] ← [predicted] + ([val] /Z 2) si no. calcular la curva final es solo un paso: 1.[ly]. fin S´ ıntesis de la curva 121 La s´ ıntesis de la curva devuelve un vector [floor] de longitud [n] (donde [n] viene dada desde el proceso de decodificaci´n que llama a la decodificaci´n del o o floor). [floor1 final Y y [floor1 step2 flag]. [ly] ← [floor1 final Y][0] ∗ [floor1 multiplier] 4. para cada elemento [v] del vector [floor].[hy].

Puede representar lineas espectrales. tal y como aparece en la imagen de abajo. As´ cada valor del residuo a ı.6. La estructura de codificaci´n de alto nivel. Configuracion y decodificacion de los residuos Introducci´n o Un vector de residuos representa el grano fino del espectro de audio de un canal en un frame de audio despu´s de que el codificador elimine la curva floor y realice el e emparejamiento de canales. y reconstruye los vectores durante la decodificaci´n. el c´digo de clasficaci´n codifica o o o dos n´meros de clasificaci´n. u o Los valores en un vector de residuos pueden codificarse en bloque de una sola pasada por el vector de residuos. usando m´s de un codebook VQ. el o n n´mero total de trozos codificados es [residue partition size] ∗ch.122 CAP´ ITULO 5. Los elementos de tipo entero que conforman cada trozo de una clasificaci´n se construyen como un escalar que representa el n´mero de clasio u ficaci´n en ese trozo. Si tenemos un vector de longitud n. un tama˜o de o n partici´n de residue partition size. 1. 5. supondremos o e un [residue partition size] de 8. pero dise˜os m´s eficientes de codebook aconn a sejan que cada vector se codifique como la suma aditiva de varias pasadas por el vector de residuos. clasificando cada uno. As´ como ı los vectores de residuos se codifican en particiones agrupadas para incrementar la eficiencia de la codificaci´n. Hay que destacar u que la divisi´n entera trunca. o Vorbis hace uso de tres tipos diferentes de codificaci´n (numeradas como 0. Un conjunto de vectores de residudos codificados tienen todos la misma longitud. Cada partici´n de cada vector tiene un n´mero de clasificaci´n que especifica cu´l o u o a de los codebooks VQ configurados se emplear´ para decodificar la partici´n. En el ejemplo de abajo. o . Para el ejemplo que veremos despu´s. es de la siguiente o forma: Cada vector se divide en multiples trozos de igual tama˜o. El u valor de clasificaci´n asociado con una partici´n es el mismo en cada pasada. a o Represente a lo que represente. ilustrada en la Figura 5. Formato de residuos El formato de residuos particiona cada vector del vector empaquetado en trozos. FORMATO OGG VORBIS 5. magnitudes espectrales.1. aunque en los procesos de m´s alto nivel empleados para clasificar y codificar a el vector del residuo es el mismo en las tres variantes.7. fases espectrales o h´ ıbridos cuando se mezcla con el emparejamiento de canales. y 2) de o la misma abstracci´n de codificaci´n de vector. el vector de clasificaci´n tambi´n est´ divido o o e a en fragmentos. de acuerdo a la n configuraci´n especificada. la abstracci´n de residuo codifica el vector de o residuos en el paquete de vorbis.6. acumula de forma potencial valores de m´ltiples pasadas del decodificador. o o 5. El particionamiento y la intercalaci´n var´ seg´n el n´mero de codificaci´n del o ıa u u o residuo.2. codificando la clasificaci´n de los trozos y finalmente codificando o los trozos mismo usando la clasificaci´n VQ espec´ o ıfica definida para cada clasificaci´n o elegida. La sem´ntica del vector no influye en la abstracci´n de residuo. y un total de ch vectores de residuos. Los a o n´meros de clasificaci´n de cada partici´n pueden imaginarse como si formara u o o un vector por ellos mismos. por o o lo que la clave de clasificaci´n se codifica solo en la primera pasada.6.

CONFIGURACION Y DECODIFICACION DE LOS RESIDUOS 123 Figura 5. .7: Empaquetamiento de los residuos.6.5.

los residuos de tipo 1 y tipo 2 son equivalentes. Representa los escalares de las particiones en orden. Un ejemplo sencillo que ilustra r´pidamente este tipo de residuo se muestra en la Figura 5. La dimensi´n o del codebook no necesita ser la misma en m´ltiples pasadas. asumiremos un tama˜o de partici´n de 8. 4.124 Residuo 0 CAP´ ITULO 5. y se procede de la siguiente e forma: . FORMATO OGG VORBIS El residuo 0 y el 1 solo difieren en la forma en la que los valores de una partici´n o de residuos se intercalan en la codificaci´n de la partici´n (lo que en la figura anterior o o eran las cajas de color marr´n y cyan). Decodificaci´n de los residuos o Decodificaci´n de la cabecera o La cabecera de los tres tipos de residuos es id´ntica.6. 2 y 1: n u n residuos: 0 1 2 3 4 5 6 7 codebook8 : 0 1 2 3 4 5 6 7 codebook4 : 0 1 2 3 4 5 6 7 codebook2 : 0 1 2 3 4 5 6 7 codebook1 : 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. para ser codificado seg´n n o u un residuo de tipo 0 usando codebook de tama˜os 8.3. De todas formas. aunque el o u n tama˜o del codebook pueda variar de pasada a pasada. n o u o Como ejemplo. La decodificaci´n es o o como en el tipo 1. solo se necesita que el u tama˜o de la partici´n sea un m´ltiplo exacto de la dimensi´n del codebook. o La codificaci´n 0 de residuos intercala las codificaciones VQ seg´n la dimensi´n o u o del codebook usdo para codificar una partici´n en una pasada espec´ o ıfica. En el ejemplo asumiremos un n vector de tama˜o 8. tal y como ocurr´ con el residuo 0. el tama˜o ıa n de la partici´n tiene que ser un m´ltiplo entero del tama˜o del codebook. 4. los ch vectores de u entrada se convierten en un unico vector de longitud ch∗n con todos sus elementos ´ intercalados. En lugar de codificar las m´ltiples pasadas en el vector como hace el tipo 1. 2 y 1: n residuos: 0 1 2 3 4 5 6 7 codebook8 : 0 1 2 3 4 5 6 7 codebook4 : 0 2 4 6 1 3 5 7 codebook2 : 0 4 1 5 2 6 3 7 codebook1 : 0 1 2 3 4 5 6 7 Residuo 1 Este tipo de residuo no intercala las codificaciones VQ.8: a 5. codificado seg´n el residuo 1 usando tama˜os de 8. pero con la intercalaci´n invertida. La codificaci´n procede entonces como en el tipo 1. Si se est´ operando en un unico o a ´ vector para comenzar.

Implementa algo parecido a un filtro paso bana da. [residue end] ← uint24 3. CONFIGURACION Y DECODIFICACION DE LOS RESIDUOS 125 Figura 5. . a o ´ o Despu´s leemos un patr´n de mapa de bits que especifica qu´ c´digo de clases de e o e o partici´n se usa en cada pasada. Los valores anteriores y posteriores de los vectores desempaquetados se ponen a cero. . [residue begin] ← uint24 2.[residue classifications]−1 ⇒ a) [high bits] ← 0 b) [low bits] ← uint3 . o 1. El n´mero de dimensi´n del book [residue classbook] deo u o termina cu´ntos valores de clasificaci´n se agrupan en una unica clave de clasificaci´n. [residue classbook] ← uint8 [residue begin] y [residue end] seleccionan la sub-porci´n espec´ o ıfica de cada vector que est´ realmente codificado.5. y u o [residue classbook] es el n´mero de codebook que se han usado para codificar las u claves de clasificaci´n. [residue partition size] ← uint24 +1 4. Destacar que para los residuos de tipo 2. [residue classifications] es el n´mero de posibles clasificaciones a los que una partici´n puede pertenecer. [residue partition size] es tal y como se ha explicado antes.6. estos valores as´ como el [residue partition size] se refieren al vecı tor intercalado y no a cada uno de los vectores individuales antes de intercalarlos. [residue classifications] ← uint6 +1 5. orientado a la codificaci´n. o o 1.8: Codificaci´n y decodificaci´n de un residuo de tipo 2. itera [i] en el intervalo 0 . haciendo que el vector empieze en [residue begin] o y termine en [residue end] de forma efectiva.

o 1. se proporciona desde el nivel de decodificaci´n superior. leemos en una lista de n´meros de book cada uno correspondiente a u un bit espec´ ıfico activado en el bitmap. De o todas formas. o o seg´n la descripci´n ofrecida anteriormente. . Reservar en memoria y poner a cero todos los vectores que se devolver´n a . de decodificaci´n com´n a los tres formatos. Si el n´mero de pasadas es 3 y el vector n´mero 1 est´ marcado para u u a no decodificarse. FORMATO OGG VORBIS c) [bitflag] ← 1 bit como booleano d) si ([bitflag] es activo ) ⇒ [high bits] ← uint5 e) [residue cascade][i] ← [high bits]∗8+[low bits] 2. itera [i] 0 . Iteramos los posibles codebook de clasificaci´n o y el n´mero m´ximo posible de etapas de codificacion (8 en Vorbis I. [n to read] ← [residue end] − [residue begin] 3. incluso los vectores que no se van a decodificar se reservan en memoria y se inician a cero. [classvals per codeword] ← [codebook dimensions] del codebook [residue classbook] 2. El formato de tipo 2 se puede hacer fuera o del proceso de decodificaci´n del formato 1. y el vector de valores bandera indica si alguno de esos vectores no se tiene que decodificar. restringido al ser u a de 8 bits los elementos del bitmap): 1. fin Una condici´n fin-de-paquete en alg´n punto de la cabecera hace la trama indeo u codificable. . o u Adem´s de la informaci´n de la configuraci´n. . notado por [ch]. [partitions to read] ← [n to read] / [residue partiton size] El proceso de decodificaci´n sigue los pasos que especificaremos a continuaci´n. Estos valores son utiles conceptualmente para clarificar el proceso de decodifica´ ci´n: o 1. Adem´s. 7 ⇒ • si ([residue cascade][i] bit[j] est´ activo ) ⇒ a ◦ [residue books][i][j] ← uint8 si no. As´ primero describiremos la estructura o ı. e Decodificaci´n del paquete o La decodificaci´n de los paquetes de tipo de residuos 0 y 1 es id´ntico excepto o e para el intercalado espec´ ıfico de la partici´n.[residue classifications]−1 ⇒ itera [j] 0 . el proceso de decodificaci´n de a o o o residuos hace tantas pasadas como el n´mero de vectores que conforman el conjunto u del submapa. el decodificador ignora el vector 1 en el bucle de decodificaci´n. cualquier n´mero en el codebook mayor que el m´ximo codebook a u a numerado configurado en esa trama tambi´n la convierte en indecodificable. ([residue cascade][i] bit[j] no est´ activo ) ⇒ a ◦ [residue books][i][j] ← no usado 2. Asumimos que el n´mero de vectores u o u codificados.126 CAP´ ITULO 5. . fin Para terminar.

Asumiremos que: a o [n] ← [residue partition size] [v] ← vector de residuos [offset] ← posici´n de inicio de lectura de [v] o 1.[ch]−1 ⇒ si 1) 2) 3) ([j] = no-decodificar ) ⇒ [vqclass] ← [classifications][j]. .[step]−1 ⇒ a) [entry temp] ← lee vector desde el paquete usando el codebook actual en el contexto VQ . [step] ← [n] / [codebook dimensions] 2.5.[pass] si ( [vqbook] = no-usado ) ⇒ • decodifica la partici´n en el vector [j] de salida.([partition count]+[classword count]) [vqbook] ← [residue books][vqclass]. . . . Espec´ ıfico para el formato 0 El formato de tipo 0 decodifica la particion exactamente como se describi´ en la o secci´n de dicho t´ o ıtulo. .[ch]−1 ⇒ • [temp] ← lee del paquete usando el codebook [residue classbook] como elemento • itera [k] en el intervalo [classvals per codeword] − 1 . fin Una condici´n de fin-de-paquete durante la decodificaci´n se considera un suceso o o puntual. .6. . comenzando en o 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. itera [pass] en el intervalo 0 . 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 . . El decodificador devolver´ el vector resultante de la decodificaci´n hasta ese a o momento. . CONFIGURACION Y DECODIFICACION DE LOS RESIDUOS 2. itera [i] en el intervalo 0 . . Un pseudoc´digo posible para ese algoritmo podr´ ser el que o ıa se escribir´ a continuaci´n. 7 ⇒ a) [partition count] ← 0 b) si ([pass] = 0) ⇒ 127 itera [j] en el intervalo 0 .

. FORMATO OGG VORBIS b) itera [j] en el intervalo 0 . usaremos el algoritmo ya descrito para su decodificaci´n. si ([i] < [n]) ⇒ ir al paso 2 5. fin Espec´ ıfico para el formato 2 El formato 2 se puede convertir al formato 1 mediante una serie de pasos. Decodificaremos usando el formato 1 un vector [v] de ch∗n Desharemos la intercalaci´n del vector [v] en ch vectores independientes notados o por salida [k].[codebook dimensions]−1 ⇒ [v]([offset]+[i]+[j]∗[step]) ← [v]([offset]+[i]+[j]∗[step]) + [entry temp][j] 3. fin El formato 2 no maneja la bandera no-decodificar de forma diferente del tipo 0 ´ 1.[n]−1 ⇒ itera [j] en el intervalo 0 . . Una vez convertido al tipo 1. si todos los vectores se marcan a no-decodificar. . Sin embargo. . a . no se realiza decodificaci´n o o alguna.ch−1.128 CAP´ ITULO 5. realizados en orden. o 1. . con que uno de ellos est´ marcado para ser decodificado. itera [i] en el intervalo 0 . Asumiremos que: [n] ← [residue partition size] [v] ← vector de residuos [offset] ← posici´n de inicio de lectura de [v] o Un pseudoc´digo posible para ese algoritmo podr´ ser el que se escribir´ a cono ıa a tinuaci´n: o 1. fin Espec´ ıfico para el formato 1 El formato de tipo 1 decodifica la particion exactamente como se describi´ en la o secci´n de dicho t´ o ıtulo. [entry temp] ← lee vector desde el paquete usando el codebook actual en el contexto VQ 3. 3. siendo k un ´ ındice entre 0 . todos e los vectores ser´n decodificados. .[ch]−1 ⇒ • salida [j][i] ← [t]([i]∗[ch]+[j]) 2. . seg´n el algoritmo mostrado u a continuaci´n o 1. itera [j] en el intervalo 0 . Asumimos que se van a decodificar ch vectores de n elementos 2. [i] ← 0 2. . . .[codebook dimensions]−1 ⇒ [v]([offset]+[i]) ← [v]([offset]+[i]) + [entry temp][j] [i]++ 4.

[return value] ← 0 2. [sign] ← [x] 0x1fffff. si ([mantissa] = 0) ⇒ [mantissa] ← -[mantissa] 5.7. hemos hecho referencia a ciero tas funciones que. o 1.7. devuelve [mantissa] ∗(2[exponent]−788 ) lookup1 values (codebook entries. [mantissa] ← [x] 2. fin float32 unpack (x) Su finalidad es traducir la representaci´n binaria de un valor flotante empaquetado o que usa un codebook en la representaci´n de flotante que emplea el decodificador. [exponent] ← ([x] 4. 5.1. u n El valor que devuelve la funci´n se define como “el mayor valor entero para el cu´l o a [return value][codebook dimensions] ≤ [codebook entries]”. resultado sin signo 3. son totalmente o independientes de ´stos y no conllevan m´s que c´lculos generales. o Aqu´ se implementa para un float32 nativo a la arquitectura del host.7. y [v]n o < [v][x] . Los valores de esta lista est´n permutados para construir la a tabla de b´squeda de tama˜o codebook entries] de vectores VQ. FUNCIONES AUXILIARES DE LA IMPLEMENTACION 129 5. Los valores de x menores de cero devuelven cero por definici´n.´ 5. ı 1. low neighbor (v. resultado sin signo 0x80000000. si ([x] = 0) ⇒ [return value]++ [x] 1 repetir paso 2 3. codebook dimensions) Se usa para calcular la longitud correcta de un ´ ındice de la tabla de lookup de tipo 1 para un codebook VQ. La intenci´n de e a a o este texto es determinar qu´ hace cada una de las funciones referenciadas en distintas e partes del documento. x) Devuelve la posici´n n del mayor elemento de [v] para el que n < [x]. ilog (x) ´ Esta funci´n devuelve el bit activo m´s significativo del complemento a dos del o a valor x. resultado sin signo 0x7fe00000) 21. Funciones auxiliares de la implementaci´n o Introducci´n o Cuando hemos explicado los distintos algoritmos que implementan el c´lculo de a elementos necesarios para la decodificaci´n de la onda. si bien aparecen en los procesos de decodificaci´n.

sin calcular los valores sobre la l´ ınea. [off] ← [err] /Z [adx] 0 6. [off] ← [err] /Z [adx] 6. 1.130 high neighbor (v. X) Esta funci´n calcula el valor Y en la ordenada X perteneciente a la l´ o ınea definida con la pareja de puntos (x0. si ([dy] < 0) ⇒ [sy] ← [base] −1 si no. y1. y0. x1. x1. Esta funci´n usa un algoritmo entero para o solucionar el valor del punto de forma directa. y0. a 1. no teniendo u relevancia en otro ´mbito. y1. x) CAP´ ITULO 5. [ady] ← |[dy]| 4. ([dy] ≥ 0) ⇒ [sy] ← [base] +1 7. si ([dy] < 0) ⇒ [Y] ← [y0] − [off] si no. [adx] ← [x1] − [x0] 3. [err] ← [ady] ∗ ([X] − [x0] 5. [dy] ← [y1] − [y0] 2. (x1. [err] ← [ady] ∗ ([X] − [x0]) 5. fin render line (x0. y [v]n o > [v][x] render point (x0. Es importante aqu´ que la divisi´n enteır ı o ra redondee hacia cero tanto los n´meros negativos como los positivos. [ady] ← |[dy]| 4. [adx] ← [x1] − [x0] 3.y1).y0). [dy] ← [y1] − [y0] 2. FORMATO OGG VORBIS Devuelve la posici´n n del menor elemento de [v] para el que n < [x]. ⇒ [Y] ← [y0] + [off] 7. [ady] ← [ady] − [base] ∗ [adx] . v) La decodificaci´n de floor tipo 1 usa este algoritmo de dibujado de l´ o ıneas entero para constru´ una curva contigua a trozos.

([err] < [adx]) ⇒ [y] ← [y] + [base] 10.´ 5. . [v] [x] ← [y] 9.[x1]−1 ⇒ a) [err] ← [err] + [ady] b) si ([err] ≥ [adx]) ⇒ [err] ← [err] − [adx] [y] ← [y] + [sy] si no. itera [x] en el intervalo [x0]+1 . FUNCIONES AUXILIARES DE LA IMPLEMENTACION 8.7. [v] [x] ← [y] 11. fin 131 . .

FORMATO OGG VORBIS .132 CAP´ ITULO 5.

determinaremos toda la geometr´ como un punto en el espacio tridio ıa mensional. Si desea m´s informaci´n sobre representaci´n. y = y + dy (6. Principios de la Inform´tica Gr´fica a a Aqu´ explicaremos las operaciones necesarias para realizar la transformaci´n de un ı o mundo 3D continuo a una imagen 2D que representa la proyecci´n de la escena dada o mediante una c´mara definida. as´ como una breve descripci´n de las trasnformacioa ı o nes geom´tricas b´sicas. definiremos los siguientes vectores columna o P = x y . pero como ıa 133 . Supongamos que tenemos un segmento de recta que queremos trasladar.Cap´ ıtulo 6 Ap´ndices e 6. y) a nuevas posiciones simplemente a˜adiendo la cantidad a transladar a las coordenadas del punto.P = x y . moverlo dx unidades en el eje x y dy unidades en el eje y hasta el punto P (x . Habr´ que trasladar todos los puntos que conforman la recta. ya que la transformaci´n de una geometr´ m´s compleja se realiza punto o ıa a a punto. y ). ya que el tridimensional es una extensi´n de ´ste.1. Para cada punto n P (x.1.1) Para simplificar la expresi´n. y la forma de representarlo para su c´mputo. puede consultar documentaci´n especializada [22].1. Describiremos las transformaciones geom´tricas o e e b´sicas que usaremos. 6. a o Podemos trasladar puntos en el plano (x. iluminaci´n y e a a o o o trasnformaciones. todo se limita a trasladar los v´rtices que o e conforman una figura.T = dx dy (6. simplificaci´n. o Comenzaremos viendo c´mo se transforma en el espacio 3D una geometr´ Por o ıa.3) Como mencionamos en la introducci´n.1) o P =P +T (6.2) Ahora podemos reescribir la expresi´n (6. Transformaciones en 2D Primero estudiaremos las transformaciones en un espacio bidimensional. podemos escribirlo como x = x + dx . y).

Puede impactar ver tripletas de coordenadas para representar un punto bidimensional. desde el eje x al eje y. teniendo mismo punto representado por (x/W. y). Si W = 0. como se puede apreciar. basta trasladar los puntos que forman el segmento a para trasladar el segmento completo.5) donde R es la matriz de rotaci´n de la ecuaci´n (6. La restricci´n es que. Al estar formados por una tripleta de valores. que resulta ser el punto de intersecci´n de dicha recta con el plano definido por la ecuaci´n W = 1 en o o el espacio (x. la ecuaci´n de traslaci´n (6. cada punto puede tener varias representaciones de u tripletas en coordenadas homog´neas. tenemos un punto en el infinito. la expresi´n (6. La rotaci´n sobre un ´ngulo θ desde el origen se define matem´ticamente como o a a x = xcos · θ − ysen · θ. Si expresamos los ı.5).1) se o o reescribe en forma matricial como       x 1 0 dx x  y  =  0 1 dy  ·  y  (6.134 ´ CAP´ ITULO 6.7) 1 0 0 1 1 Si consideramos la matriz de traslaci´n empleada como T . 0) es inv´lida. cada punto se representa por una tripleta (x. y . podemos dividir el resto de coordenadas por ´l. y. y. pero la explicaci´n es sencilla. W ). W ) y (x . Coordenadas homogeneas Hemos obtenido la expresi´n para trasladar y rotar puntos en un espacio bidio mensional. a Si W = 0.7) como o P =T ·P (6.1.4) En forma matricial. e tripleta que contiene las coordenadas cartesianas del punto homogeneo. 1). e En coordenadas homog´neas.6) Lo recomendable ser´ poder combinar de forma consistente las transformaciones ıa entre s´ para lo cu´l necesitamos tratarlas de forma semejante. y por tanto no ocuparemos aqu´ su traı tamiento. Definimos que (x. como se observa en la Figura 6. y. (6. por lo que la tripleta (0. y. y/W. Por tanto. a puntos en coordenadas homog´neas. En lue n gar de disponer de parejas de puntos (x. 0. W ). Si homogeneizamos el punto. pero nos encontramos ante la situaci´n de que no realizan las mismas o operaciones.4) se puede expresar como o x y = cosθ senθ −senθ cosθ · x y o bien P = R · P . podemos reescribir la o expresi´n (6. ya que no entra dentro de nuestros intereses. al menos una de las coordee o nadas de la tripleta debe ser distinta de cero. Tenemos que P = T + P. P =R·P (6. El conjunto de tripletas que representan al mismo o punto conforma una recta en el espacio tridimensional. a˜adimos una tercera coordenada al punto. ambas pueden tratarse como multiplicaciones. obtendremos un punto (x. W ) corresponden al mismo punto si una es m´ltiplo de la otra. Los ´ngulos positivos se miden o o a en sentido contrario a las agujas del reloj. APENDICES podemos comprobar f´cilmente. y = ysen · θ + ycos · θ (6. 1).8) .

Los unicos pasos que hay que dar son: ´ 1.10) −senθ cosθ 0    0 x 0 · y  1 1 (6.5) se escriben ahora como o    x cosθ  y  =  senθ 1 0 Sea cosθ R(θ) =  senθ 0  −senθ cosθ 0  0 0  1 (6. basta aplicar una unica ´ transformaci´n. en lugar de estar o limitados a rotar desde el origen.1.1: El espacio de coordenadas XY W . W ) proyectado en ´l. La idea o ´ de componer las operaciones es la de simplificar c´lculos. 2.9) Sustituyendo en la ecuaci´n (6. Realizar una trasladaci´n que convierta a P1 en el origen o Rotar los puntos deseados seg´n los ´ngulos deseados u a Deshacer la traslaci´n realizada en el punto primero o (6.´ ´ 6. y1 ) como punto sobre el que realizar la rotaci´n. o o Combinando la traslaci´n con la rotaci´n podemos salvar la limitaci´n que hemos o o o impuesto en la rotaci´n: podemos girar desde un punto P1 arbitrario. al conjunto de puntos. Y. 3. e Las ecuaciones de rotaci´n (6. ya que en lugar de aplicar a varias transformaciones consecutivas a un conjunto de puntos.11) Si definimos el punto P 1(x1 . con el plano W = 1 y el punto P (X. o podemos definir la secuencia de pasos ilustrados como .9) lo definido en (6. PRINCIPIOS DE LA INFORMATICA GRAFICA 135 Figura 6. la transformaci´n resultante.10) tenemos o P = R(θ) · P Composici´n de transformaciones 2D o La finalidad de la composici´n es poder combinar las distintas transformaciones o de forma c´moda y util para poder obtener los resultados que se deseen.

0) no es v´lida.2. De igual forma. 0. Figura 6.2: Sistema de coordenadas de la mano derecha. usaremos una cu´drupla (x. las transformaciones en el e espacio tridimensional se representar´n por matrices 4×4. −y1 ) =  1  0 0   0 x1 cosθ 1 y1  ·  senθ 0 1 0  cosθ  senθ 0 −senθ cosθ 0 −senθ cosθ 0    0 1 0 −x1 0  ·  0 1 −y1  = 1 0 0 1 (6. de forma a o similar a lo dado en espacio 2D. Igual que suced´ con las tripletas ıa en el espacio bidimensional. y es el que se muestra en a la Figura 6. dy . La representaci´n cartesiana es (x/W. y. 1).136 ´ CAP´ ITULO 6. pero teniendo en cuenta que 1  0 T (dx . z/W.2. las transformaciones en 2D se representaban por matrices 3 × 3 usando coordenadas homog´neas.8). 0. y1 ) · R(θ) · T (−x1 . z. La traslaci´n en el espacio tridimensional es una simple extensi´n de todo lo o o descrito en el espacio bidimensional. Normalmente el sistema de coordenadas empleado en espacios matem´ticos 3D es el llamado de la mano derecha. sin ser dicho m´ltiplo el cero. y/W. en lugar de a ıa representar un punto por una tripleta (x. debido al uso de coordenadas a homogeneas para representar un punto de un espacio tridimensional. y.1. Transformaciones en 3D Como hemos visto. igual que suced´ en el espacio bidimensional. dz ) =   0 0  0 1 0 0  0 dx 0 dy   1 dz  0 1 (6. z). W ) para a representar un punto en coordenadas homogeneas.12)  x1 (1 − cosθ) + y1 senθ y1 (1 − cosθ) − x1 senθ  1 6. De la misma forma. representan al mismo punto aquellas cuadr´plas que eran u m´ltiplo una de otra. APENDICES T (x1 . la cu´drupla u u a (0. Por tanto. aportando una coordenada m´s. Por ello.13) La rotaci´n definida en el espacio bidimensional corresponde a la rotaci´n sobre o o . es f´cil comprobar que la expresi´n que a o rige la traslaci´n en coordenadas homogeneas expresada en forma matricial es similar o a la planteada en (6.

a .16) La composici´n de traslaci´n y rotaci´n generar´ una matriz cuya matriz superior o o o a izquierda de 3×3 proporciona la rotaci´n. o ´ o Por tanto.15)  0 senθ cosθ 0  0 0 0 1 cosθ  0 Ry (θ) =   −senθ 0  0 senθ 1 0 0 cosθ 0 0  0 0   0  1 (6. Por tanto. En el contexto al que nos referimos nosotros.14) De forma sencilla se puede obtener la expresi´n asociada a la rotaci´n respecto a o o los dos ejes restantes.3: Tipos de proyecciones: paralela. o Figura 6. conservando ´ngulos y distancias. la proyecci´n se realiza desde puntos pertenecientes a un sistema o de coordenadas de dimensi´n n. La Figura 6.3 representa los o dos tipos de proyecci´n. y persa pectiva. simplmente haremos proyecciones desde un espacio 3D a uno 2D.1. nosotros nos limitaremos a trazar rayos desde los puntos del espacio 3D. que es  cosθ −senθ  senθ cosθ Rz (θ) =   0 0 0 0 137 0 0 1 0  0 0   0  1 (6. conservando solo ´ngulos.´ ´ 6.1. PRINCIPIOS DE LA INFORMATICA GRAFICA el eje z en el espacio tridimensional. y la ultima columna proporciona la traslaci´n. Proyecciones de visualizaci´n o Normalmente. esta matriz ser´ de la forma a   r11 r12 r13 tx  r r22 r23 ty   M =  21 (6.3. y calcular los puntos de intersecci´n con un o plano arbitrario al que llamaremos plano de proyecci´n.17)  r31 r32 r33 tz  0 0 0 1 6. a puntos de un sistema de coordenadas de dimensi´n o o menor que n. que son   1 0 0 0  0 cosθ −senθ 0   Rx (θ) =  (6.

19) y simplificando. o Para los c´lculos sucesivos. W ) en P (x. es decir. consiso a o a tente en proyectar cada punto con un proyector paralelo al eje i-´simo en un plano de e visualizaci´n contenedor de los otros dos ejes. o Figura 6. Proyecci´n de perspectiva o Todos los proyectores convergen en un punto llamado centro de proyecci´n (COP).18) Usando coordenadas homog´neas podemos reescribir la expresi´n (6. Por ejemplo. APENDICES La proyecci´n paralela m´s difundida es la llamada proyecci´n ortogr´fica. a o Usando semejanza de tri´ngulos podemos decir que a x = x . podemos escribir que e     X x  Y   y      (6. convertir el punto P (x. 0. tal y como muestra la Figura 6.22) por W para obtener las coordenadas cartesianas o equivalentes.18) como e o     X x  Y   y      (6.4. y. W ).19)  Z  = Mper ·  z  W 1 siendo Mper 1  0 =  0 0  0 0 1 0 0 1 0 1/d  0 0   0  0 (6.21)  Z = z  W z/d Si dividimos la expresi´n (6.138 Proyecci´n paralela o ´ CAP´ ITULO 6. y.20) en (6. obtenemos . supondremos que el plano de proyecci´n es perpendicular a o al eje Z.20) Sustituyendo t´rminos de (6.4: C´lculo de la proyecci´n en perspectiva P del punto P . a una distancia d del centro de proyecci´n. z/d y = y z/d (6. la proyecci´n ortogr´fica o o a del eje Z en el plano XY consiste en anular la coordenada z. z.

o En la Figura 6. que dependa o no de Pz . y c´mo la proyecci´n de dos objetos distintos con o o distinto tipo de proyecci´n puede resultar id´ntica. y objetos reales que producen o o dicha proyecci´n. o . cumpliendo la restricci´n que fijamos con respecto a z. o e Figura 6.5 podemos ver el resultado pr´ctico de esta transformaci´n de P a o en P .22) Por tanto.1.22) obtenemos la relaci´n entre el punto proyectado P y el punto o original P . en (6. PRINCIPIOS DE LA INFORMATICA GRAFICA   x x z/d  y   y    z/d  z = d 1 1      139 (6.´ ´ 6.5: Proyecci´n perspectiva y proyecci´n paralela.

140

´ CAP´ ITULO 6. APENDICES

´ CAP´ ITULO 6. APENDICES

Glosario
A
AC-3 El sistema de codificaci´n usado por Dolby Digital. Ambos t´rmino, AC-3 o e y Dolby Digital, se suelen usar indistintamente, p´g. 58. a

B
BIOS Acr´nimo de Basic Input/Output System, se refiere al software que se o ejecuta al inicio, que permite controlar pantalla, teclado, unidades de disco, comunicaci´n serie y dem´s, sin acceder a ning´n programa del o a u disco duro. Normalmente se encuentra en la ROM de la placa., p´g. 51. a

C
codec De ((coder/decoder)) (codificador/descodificador), tecnolog´ que permite ıa la compresi´n y decompresi´n de datos. Pueden implementarse tanto en o o software como en hardware, o en una combinaci´n de ambos., p´g. 54. o a

compilador cruzado Se usa este t´rmino para referirse a un compilador que genera e c´digo objeto de una m´quina distinta de la que ejecuta el compilador. o a Sirve para generar el c´digo objeto de una arquitectura desde otra distinta o en la que se encuentran todas las herramientas de desarrollo., p´g. 5. a

D
doublebuffer T´rmino referido al uso de dos buffers para la representaci´n visual e o 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 buffers, y se muestra el reci´n dibujado mientras se comienza a dibujar e en el anteriormente mostrado. Esta t´cnica evita el parpadeo propio de e la escena dibujada, ya que evita que se aprecie el dibujado progresivo de la misma., p´g. 69. a DTS Acr´nimo de Digital Theatre Sound, se trata de un formato que hace que o las pistas de audio se aproximen m´s a la grabaci´n original que otras a o pistas comprimidas. En conjunci´n con el beneficio multidismensional de o la tecnolog´ de sonido envolvente, la calidad del audio de las pistas ıa y m´sicas en formato DTS mejoran dram´ticamente el contenido. M´s u a a informaci´n en su web: http://www.dtsonline.com/, p´g. 58. o a I

com/).microchip. 1. a Acr´nimo de Reduced Instruction Set Computer.. p´g. a RISC S SIMD Acr´nimo de Single-Instruction Stream Multiple-Data Stream. (http: //www. o . La idea b´sica consiste en procesar un conjunto de datos de a forma simultanea.. o a P PIC Microcontrolador fabricado por Microchip (http://www.com/). y sin barra. a free-lance M MIPS Acr´nimo de Microprocessor without Interlocked Pipeline Stages. es un o procesador RISC desarrollado por la MIPS Computer Systems Inc. Est´ compuesta por puertas o tablas de consulta en RAM. a mod-chip O OpenGL OpenGL es el principal entorno de desarrollo gr´fico 2D y 3D portable.II GLOSARIO F FPGA Acr´nimo de Field Programable Gate Array..org/. p´g. 6.. 66. o a flip-flops y cableado de interconexi´n programable.. se refiere o a un tipo de arquitectura esencial en el mundo del c´lculo paralelo de los a ordenadores. se trata de una malla de o puertas en la que la red l´gica puede programarse en el dispositivo tras o su creaci´n. aprovechando que se ha de realizar la misma operaci´n. es un microprocesador o dise˜ado para realizar un n´mero reducido de tipos de instrucciones para n u poder operar a una velocidad mayor. 6. 1. p´g. a No est´ sujeto a ning´n sistema operativo y refleja el pensamiento y a u talento de desarrolladores software de diferentes trasfondos gr´ficos. o a Se dice de la persona que trabaja por su cuenta. p´g.. M´s a a informaci´n en su web: http://www. p´g.opengl. dada la simplicidad de la circuiter´ ıa necesaria. a Nombre com´n con el que se conoce a los circuitos que se implantan en u las consolas para alterar la funcionalidad de la misma. Su silencio asociado es una barra horizontal que ((cuelga)) de la segunda linea del pentagrama. 1. a R redonda es una nota que tiene una duracion de cuatro tiempos. 64. Su simbolo es un ovalo sin llenar. p´g.mips. 1. de ahi su nombre. p´g. haciendo creaciones propias sin formar parte de la plantilla de ninguna empresa. normalmente usados como peque˜as unidades de procesamiento en cirn cuitos simples de control. o o o p´g. como puede ser el bloqueo de c´digo de regi´n o el bloqueo por protecci´n anti-copia.

1. El poder de esta arquitectura o a se puede contemplar cuando el n´mero de procesadores coincide con el u n´mero de elementos a procesar. p´g.. a X x86 Se refiere a cualquier procesador de la familia Intel 80x86. Con a ((streaming)). 56. describe una arquitectura de o procesamiento en la que el compilador o el preprocesador dividen la instrucci´n de programa en operaciones b´sicas que pueden ser realizadas o a por el procesador en paralelo. a . p´g. 93. de forma cont´ ınua. Incluso cuando a el tama˜o de un vector es mayor al n´mero de procesadores disponibles. p´g.. como Cyrix o AMD. ya que muchos usuarios no tienen a´n un acceso lo suficientemente r´pido como pau a ra poder acceder a ficheros multimedia grandes de forma r´pida. a streaming T´cnica para transferir datos de manera que pueden ser procesados cone forme llegan. n u la ganancia comparada con el algoritmo secuencia es enorme. el cliente puede comenzar su reproducci´n antes de recibir o el fichero completo. La tecnolog´ de ((streaming)) est´n ıa a tomando relevancia debido al crecimiento de internet. p´g. la suma y multiplicaci´n u o de los elementos se puede realizar de forma simult´nea. 1... En ese caso. a V VLIW Acr´nimo de Very Long Instruction Word.GLOSARIO III La habilidad de procesar vectores y matrices en tiempo m´ ınimo ha creado una demanda muy importante en ´reas como predicci´n metereol´gica o a o o investigaci´n de las radiaciones de c´ncer. o a cualquier procesador compatible.

IV GLOSARIO .

Tago et al. com/sog. P´gina de la Comunidad Linux de la PS2. Horoaki Murakami. http://playstation2-linux. V .com.xmms. http://cvs. playstation2-linux.h. [17] N. [12] Karsten Scheibler y Jonathan Leto Dragan Stancevic’s.com/projects/ps2stuff/.net/. a [8] Proyecto ps2stuff. [2] Ars Technica.com.net all your game development needs. [5] GameDev. http://gamedev. http: a //playstation2-linux. Linux Assembly! http: //linuxassembly. [3] Compilador Vector EE.linux. Atsushi Kunimatsu. cgi/xmms/xmms/fft. Masaaki Oka.com/projects/vudemocontest/. [13] Sony Computer Entertaintment. http://www. [14] Sony Computer Entertaintment. [15] Sony Computer Entertaintment.ps2reality.c. The PC Enthusiast’s resource.org/cvsweb. http://cvs. http://www. /usr/docu/Playstation2/libps2dev/.com/. [4] The Enterprise Linux Resource. http://www.com.org/.Bibliograf´ ıa [1] 4Front Technologies. Vector Unit Architecture for emotion systhesis. Implementaci´n de la FFT usada en el XMMS.com/. o xmms. Importance of CAD tools and methodologies in high speed CPU desing.opensound. [7] P´gina oficial de Sony para PlayStation. http://es.org/cvsweb. Clock desing of 300 MHz 128 bit 2-Way superscalar microprocessor. [6] Lista de monitores con los que funciona la PS2.cgi/xmms/xmms/fft. http://www. Toshinori Sato. http:// [16] H.codeplay. [11] Richard Boulton.arstechnica. Kojima et al. Nobuhiro Ide. [9] PS2RealityCompilador Vector EE. http://www.net. VU Demo Coding Contest.com/. [10] Sony Computer Ent. Biblioteca de desarrollo de la ps2 bajo linux. http://playstation2-linux. Yukio Endo. Masakasu Suzuoki.php.playstation.

com/projects/vcl/. o Asignatura de Arquitectura de Computadores II.pdf. [32] Inc.ugr. a [24] MIPS Technologies Inc. Playstation 2 Game Programming Part 1. EE Core User’s Manual. Linux (for Playstation2) VCL Preprocesor.com/.com/ o u tercero/musica3/lamusic3. [27] Sony Computer Entertainment Inc.cc.es/planes/ingenieria/quinto/arquitectura_ de_computadores_ii. [34] Fernado Rodr´ ıguez Le´n. http://playstation2-linux. o a [35] El liceo digital.com/ coding-on-playstation2. 1997. http://ps2dev. http://playstation2-linux. 2001.ugr. EE Overview.org Foundation. 2001. van Dam. Integrated Device Technology. [26] Sony Computer Entertainment Inc.vorbis. Computer Graphics: Principles and Practice. http://www. . Volume I: Introduction to the MIPS32 Architecture. [38] Sony Computer Ent. [23] Xiph.rogers. Kamei et al. Masakasu Suzuoki. Masaaki Oka.phtml. 1996.hr/~unreal/theredbook/. [21] Sarah Ewen. [20] T. El est´ndar MPEG.VI BIBLIOGRAF´ IA [18] N. http://fly. http://www. P´gina oficial de Ogg Vorbis. http://gamedev. 2001.liceodigital. http://members. Kojima et al. [30] Sony Computer Entertainment Inc.net/ reference/programming/features/ps2gp1/. http://www-etsi2.php. [22] Feiner y Hughes Foley. Addison Wesley. [25] Sony Computer Entertainment Inc. 2002. VU User’s Manual. 2002. http://atc. IDT MIPS Microprocessor Family Software Reference Manual. GS User’s Manual. [31] Sony Computer Entertainment Inc. Fernandez Baldomero y Antonio Francisco Diaz Garcia Mancia Anguita L´pez. OpenGL Programming Guide. MIPS32. 2001.htm. AddisonWesley Publishing Company. EE User’s Manual. 2001.com/jenova0/MIPS. 300 Mhz Desing methodology of VU for emotion synthesis. Repeater insertion method and its application to the 300 MHz 128 bit 2-Way superscalar microprocessor. [19] Oobles et al. EE Core Instruction Set Manual. Coding for the Playstation2. [29] Sony Computer Entertainment Inc. Introducci´n a la M´sica. [36] Rob Louie. [33] Tom Davis y Mason Woo Jackie Neider. PS2DEV network. [28] Sony Computer Entertainment Inc.org/.fer. [37] Francisco J.es/~jesus. Document number: MD00082. 1993. Designing and programming the Emotion Engine. Architecture for Programmers. 2001.

Linux Multimedia Guide. P´gina oficila de Naplink. cornell.edu/nr/bookcpdf. O’Reilly.ps. Edler Th. Saul A.html. reference/articles/article1952.com/djgpp/doc/brennan/brennan_att_inline_djgpp.xmms. [40] Napalm. u a de la consola Sony PlayStation2 como herramienta de Docencia de Aquitectura de Computadores.iocon. http://www.com/ catalog/multilinux/. [44] Bharata B.html?dwzone=linux.org/HOWTO/Assembly-HOWTO/. Formato de compresi´n de audio Ogg Voro bis. Asignatura de Arquitecturas Especializadas. 1996.ugr.linux.com/desktops/04/08/09/1513255.es/~jesus/asignaturas/aci/.com/ developerworks/linux/library/l-ia.gamedev.es/~jesus/asignaturas/ae/.html. delorie. http://www. [49] Jeff Tranter. Macia Anguita y Alberto Prieto.1.asp.es/~jesus/asignaturas/ae/descargas/trabajos/ 2002-2003/vorbis. P´gina oficial de XMMS. Brennan’s Guide to Inline Assembly.utexas. Sporer. http: //desktops. http://atc. [46] XMMS Team. [48] Kh. a [47] 4Front Technologies. [45] Paul Smith. 2001. 2002. [50] Brennan Underwood. http://www-106. [42] Fr´d´ric Patin.library. Numerical Recipes in C. http://www. Julio Ortega. OSS Programmer’s guide v1.ugr. a [41] University of Texas at Austin. The use of multirate filter banks for coding of high quality digital audio. http: u a n //atc. [56] Matteo Frigo y Steven G.opensound.fftw. [54] Konstantin Boldyshev y Francois-Rene Rideau.is-a-geek. http://naplink. Linux Assembly HOWTO. [53] Rafael Garc´ Jes´s Gonz´lez. Uso ıa.htm. Brandenburg y B.net/ vututs/index.shtml?tid=25.org/.com/resource/docs/ ps/eusipco_corrected. http: //www. [51] Christian Vincenot.BIBLIOGRAF´ IA VII [39] Roberto Francisco Arroyo Moreno. com/pguide/oss. http://paulsmith. http://www.net/ [43] Jes´s Gonz´lez Pe˜alver. http://www. http://atc. Asignatura de Arquitectura de u a n Computadores I. Inline assembly for x86 in Linux.pdf.edu/cofa/music/voice/texassings/ soundstuff. Fast Fourier Transform in the West.Press. Rao.org/. [52] Teukolsky William T. The Art of Scientific Computing. [55] Julio Ortega Lopera y Jes´s Gonz´lez Pe˜alver. Flannery William H. Johnson.pdf. http://www.ugr. e e Beat Detection Algorithms. http: //www. VU microcoding tutorials.html.com/. 1996. Vetterling y Brian P.ibm. What do we need to know about the physics of singing? http://www.tldp. An introduction to Linux sound systems and APIs. http://www.napalm-x. 1992. .oreilly.