La carrera de los bits y los megahercios, sexta parte

Volviendo la vista atrás: la Dreamcast

¿Alguno creía que me iba a olvidar de la Dreamcast, y de todos los que me habíais pedido este artículo? Para nada. Lo que sucede es que he estado muy liado trabajando, estudiando, y terminando la beta del Kid Icarus: Erico. Pero he sacado tiempo, y he estado currando en este artículo un par de semanas, así que aquí tenéis. Espero que lo disfrutéis. Va en la línea de los anteriores, bastante técnico, aunque mucho más fácil de leer que el anterior. Los que me han leído ya saben que será un poco denso, pero muy instructivo 🙂

Un diseño clásico bien hecho: la CPU

Después de haber expuesto la arquitectura de las nuevas consolas, Xbox 360 y Playstation 3, vamos a remontar un poco, hasta una arquitectura más clásica, aunque no por ello menos interesante. La Dreamcast no tiene una CPU de varios cores, ni una GPU con shaders unificados, ni memoria GDDR o XDR, ni tampoco es más rápida que una Playstation 2, y no obstante, es bien conocido el gran potencial que atesoraba, y su lastimoso destino. Para la época en la que vió la luz, la Dreamcast era una consola con un rendimiento fabuloso. Y desde mi punto de vista, es un sistema bien diseñado (con una excepción que afecta al apartado de seguridad, y que comentaré más adelante). La CPU de la Dreamcast es un SH4 de Hitachi, funcionando a 200 MHz, con una caché L1 modesta de 24 Kb, una cantidad bastante adecuada para un sistema de estas caracteristicas. El chip está fabricado en tecnología de 0,25 micras, o 250 nm, que en comparación con los 90nm de las CPUs de la Xbox 360 o la Playstation 3, es un poco anticuada, pero muy normal en aquel momento. Recuerdo que cuanto más pequeña sea la tecnología, o escala de integración, más dispositivos se pueden meter en un mismo chip, con un menor consumo y generación de calor, y un mayor rendimiento económico. El SH4 ofrecía a la Dreamcast una capacidad de procesamiento bastante elevada a bajo coste y consumo, y Hitachi no tenía problemas en aquel momento para fabricar una gran cantidad de estos chips. SEGA ya había empleado procesadores de la serie SH de Hitachi, más antiguos y menos potentes, como el SH1 y el SH2, en otras de sus máquinas, como el 32X o la Saturn. Por tanto, estaba familiarizada con esa arquitectura. Es como la Wii, que usa una CPU casi idéntica a la de la Gamecube, un PowerPC en este caso, seguramente con un mismo repertorio de instrucciones, que permite aprovechar gran parte de la experiencia ganada durante los años de desarrollo del anterior sistema. Lo mismo pasó con la SNES, que usa una CPU capaz incluso de correr código de la CPU de la NES (aunque no los juegos, pero por otros motivos, relacionados con el chip gráfico y el mapa de memoria). En definitiva, el SH4 suponía un importante avance frente a anteriores CPU de la serie SH, que eran conocidos por los programadores e ingenieros de SEGA, y la hacía muy recomendable. Además, la elección de esta CPU permitía no tener que usar grandes sistemas de ventilación, debido a su bajo consumo, cercano al watio y medio. Era suficiente con cubrir el chip con un disipador metálico, no siendo necesario un ventilador para su correcto funcionamiento. Esto permitía construir una consola más pequeña, más silenciosa y más barata, y favoreció el gran diseño exterior que acabó teniendo. No obstante, como todos sabéis, la consola lleva un ventilador pequeño, que sirve para acondicionar el interior, y forzar el movimiento de aire, y evitar que se caliente el sistema. Esta medida fue necesaria por el compacto diseño de la Dreamcast, en el que apenas queda un hueco en su interior, y los componentes están muy juntos. En otros sistemas con una caja mas amplia, seguramente no habría sido necesario. La Dreamcast fue así una de las primeras consolas en prestar especial atención a la refrigeración. Era ya conocido que algunas Playstation dejaban de funcionar por exceso de calor, ya que ninguno de sus chips llevaba disipador alguno, ni la caja tenía ventilador. En comparación con consolas posteriores, no tiene un elevado rendimiento en coma flotante, pero es muy respetable para los juegos que se esperaba hacer para ella. El SH4, a 200 MHZ, permitiría alcanzar la cifra teórica de 1400 MFLOPS (1400 millones de operaciones en coma flotante por segundo). A esta cifra, habría que sumar los cálculos llevados a cabo en su procesador gráfico. En el caso más optimista, dudo que una Dreamcast llegase a la tercera parte de la capacidad de cálculo de una Playstation 2. No obstante, la CPU de la Dreamcast no es, estrictamente hablando, mucho más lenta que la de la PS2, un R5900 a 300 MHZ, que según fuentes se movería entre los 300 y los 400 millones de instrucciones por segundo. El SH4 parece ser capaz de ejecutar hasta 360 millones de instrucciones cada segundo. Luego, en cuestión de potencia bruta, la CPU de la Dreamcast y la PS2 están en un nivel similar. Tienen incluso la misma cantidad de caché L1, y el mismo número de capas de metalización. Ambas son superscalares, capaces de lanzar la ejecución de 2 instrucciones simultáneamente. Lo que hace a la PS2 superior, es que la CPU está apoyada por varios coprocesadores específicos que aumentan muchísimo su rendimiento en coma flotante. Por eso, la máquina de Sony es capaz de alcanzar los 6400 MFLOPS, sobrepasando claramente a la Dreamcast, pero en cuanto a instrucciones por segundo, andan muy parejas, y eso, teniendo en cuenta que el SH4 funciona a 50% menos MHZ, nos indica cuan adecuada fue su elección como procesador central. El SH4 está hecho con 3,2 millones de transistores a 0,25 micras, mientras que el Emotion Engine de la PS2 supera los 10 millones, con una escala de integración de 0.18 micras, y un consumo 10 veces mayor. Y la gran mayoría de estos transistores extras están dedicados a aumentar el rendimiento de cálculo en coma flotante. Por tanto, obviamente, no podemos compararlos. Pero queda claro que el SH4 hace un papel muy bueno, y es un chip muy eficiente y con excelente relación calidad\precio. Probablemente una de las mejores opciones posibles. MÁS SOBRE LA ARQUITECTURA DE LA CPU Una cosa muy interesante del SH4 es que emplea instrucciones de 16 bits. Es decir, cada instrucción ocupa 16 bits en la memoria. En el caso de la PS2, las instrucciones son de 32 bits. Cuantos más bits, más complejo puede ser el conjunto de instrucciones de la máquina, y más posibilidades de hacer que su programación sea más potente, en términos de complejidad. Pero un punto a favor de la Dreamcast es que como sus instrucciones ocupan la mitad, su caché de instrucciones puede almacenar el doble de instrucciones, y los programas ocupan menos en memoria RAM y en el disco. Otros aspecto fundamentales en una CPU son el rango de números con los que puede trabajar, y la precisión con la que puede representar un número decimal. Como el SH4 tiene una ALU (unidad aritmético-lógica, encargada de realizar las operaciones) de 32 bits, ésta puede manejar números enteros entre 0 y 4.294.967.296, en aritmética sin signo, o entre -2.147.483.648 y 2.147.483.647, con signo. En cuanto a la precisión en coma flotante, soporta precisión de 32 y de 64 bits. Cuanto mayor número a de bits se empleen, más preciso será el número. Por ejemplo, si queremos representar el valor 3,5672, tenemos que 3,57 es menos preciso que 3,5671. ¿Correcto? En efecto, es un aspecto importante e la representación de entornos tridimensionales. Y en este campo, el SH4 cumple a la perfección, pues hoy en día se siguen empleando la precisión de 32 y de 64 bits, que da valores muy cercanos a los reales en la gran mayoría de casos, y que, por cierto, se suele llamar precisión ‘single’ (32 bits) y ‘double’ (64 bits).

VISIÓN GENERAL DE LA DREAMCAST

ESQUEMA GENERAL.

En la Dreamcast todos los dispositivos van conectado a un chip, que hace de centro de comunicaciones, y que contiene también al procesador gráfico, como sucede en el caso de la Gamecube o en la Xbox. En los anteriores artículos, denominé Northbridge al chip que interconecta los componentes más rápidos del sistema, siguiendo la nomenclatura de las placas base de los ordenadores. En éstas existen 2 principales centros de comunicaciones. El otro, se suele llamar Southbridge, y conecta dispositivos más lentos, como discos duros, tarjeta de red, USB, teclado o la BIOS, al Northbridge. El Southbridge es necesario, porque permite gestionar las transferencias de elementos menos veloces, y no entorpecer las comunicaciones de alta velocidad de la CPU, la memoria y la tarjeta gráfica. En la Xbox, Xbox 360, Playstation 1, 2 y 3, por ejemplo, existen estos 2 centros de comunicación. Pero en la Dreamcast sólo hay un centro de comunicaciones, integrado en el mismo chip que el procesador gráfico, el PowerVR2. A este chip lo vamos a llamar CIPS (circuito integrado de propósito específico). Lo bueno de la Dreamcast es que al contrario que en otros casos, la CPU y el chip gráfico pueden acceder directamente a la memoria RAM. Los tres dispositivos están conectados por un bus de 64 bits que funciona a 100MHz, permitiendo un ancho de banda de 800 MB/s. 100MHz * 64 / 8 = 800 MB/s Este ancho de banda era bastante elevado en aquel momento, a pesar de que poco después, la memoria RAM de la Playstation 2 podía transferir a una velocidad ligeramente superior, de 1200 MB/s para el chip gráfico, y de 2400 MB/s para la CPU. Un hecho que aumenta el rendimiento de la consola, es que la memoria de video dispone de un bus dedicado, accesible únicamente por el PowerVR2, que permite mantener una comunicación de otros 800 MB/s entre ellos. Para otros dispositivos más lentos, también conectados al CIPS, existe un canal más estrecho, de 16 bits, funcionando a 25 MHz, que ofrece un ancho de banda de 50 MB/s, y por el que fluirán los datos del sonido, el puerto de expansión (por ejemplo, el modem) y la señal de video. Los puertos de mandos, y por tanto el canal de información de las teclas, las tarjetas de memoria y las VMU, tienen otra conexión dedicada al CIPS. Al igual que ocurre con el CIPS, que alberga tanto el chip gráfico, como el centro de comunicaciones, el chip de sonido de la Dreamcast está compuesto por un procesador ARM7 y un DSP (procesador digital de señal) Yamaha. Funciona a 45 MHZ, y es capaz de manejar 64 canales de sonido ADPCM, y su compresión en tiempo real. ADPCM es un algoritmo más avanzado que el PCM (modulación por impulsos codificados, o Pulse Code Modulation), empleado para digitalizar señales analógicas, y que emplea un mecanismo de compresión, que elimina información redundante y predice las variaciones de la señal, permitiendo así compactar el espacio necesario para almacenarlo. Esta compresión es destructiva, en el sentido de que se pierde un poco de calidad, que no puede recuperarse, pero que teniendo en cuenta el importante ahorro en espacio que permite obtener, es un mecanismo muy interesante. El ARM7 permite realizar la compresión y descompresión ADPCM en tiempo real, de forma que el resto del sistema no sufre penalización ni retardos por el hecho de emplear esta compresión. Por cierto, el ARM7 se emplea como CPU en la Game Boy Advance, y como coprocesador en la DS. Es un procesador bastante popular, que en la Dreamcast es dedicado al audio. El procesador de audio dispone de 2 MB de memoria, que funciona a 66 MHZ, y es un poco más lenta que la RAM y VRAM de la consola, que son de 100 MHZ. Este diseño es inteligente, porque el audio no genera un caudal de datos muy grande, en comparación al que se necesaita mover por la CPU y el procesador gráfico. A parte de ir un poco más despacio, la memoria de audio de la Dreamcast usa un bus de sólo 16 bits, ofreciendo un ancho de banda de 132 MB/s. 66 MHz * 16 / 8 = 132 MB/s Los buses más estrechos, o de menos bits, permiten abaratar costes y simplificar el diseño, a costa de reducir el ancho de banda.

	Dreamcast	Playstation 2
Ancho de banda CPU-RAM	0,8 Gb/s	1,3 Gb/s
Ancho de banda GPU-RAM	0,8 Gb/s	3,6 Gb/s
Ancho de banda CPU-GPU	0,8 Gb/s	1,3 Gb/s

NORTHBRIDGE Y SOUTHBRIDGE EN LOS PC Para aclarar un poco más el concepto de «centro de comunicaciones» en las arquitecturas hardware, voy a hacerlo visualmente. Si nos fijamos en la siguiente imagen, vemos una placa base de un ordenador por la parte de abajo. Los componentes están por la otra cara, pero lo que me interesa mostrar ahora es otra cosa. En blanco, el lugar donde está la CPU. En rojo, el northbridge. En amarillo, el southbridge. En fucsia, el bus gráfico de alta velocidad (en este caso, AGP). En azul, la memoria RAM. En naranja, los buses de expansión (para conectar periféricos internos). En verde, las conexiones de los discos duros y CD/DVD. Aqui bajo vemos las conexiones. El northbridge conecta la CPU, la RAM y el bus gráfico (canal rojo), además de comunicarse con el southbridge (en azul). El southbridge conecta los buses de expansión, y las unidades de disco duro y CD/DVD al northbridge, pero sin molestar a la CPU, la RAM y el chip gráfico. Digo que no les molestan, porque en un PC actual, las comunicaciones por el northbridge, por el llamado FSB (Front-Side-Bus, o bus principal), podrían típicamente hacerse a 1066MHz, dando anchos de banda de más de 8Gb/s. Mientras que los nuevos discos duros SATA-II se comunican como mucho a 300MB/s, y los buses de expansión PCI pongamos 133Mb/s y los PCI-e (x1) a 500Mb/s cada uno. Y normalmente no se alcanzarán estas velocidades, por diversos motivos. Así que el southbridge va mandando las cosas al northbridge y éste se encarga de gestionar las comunicaciones para que dispositivos lentos no entorpezcan a la CPU, el chip gráfico y la memoria RAM, que casi siempre estarán funcionando cerca del máximo rendimiento. Aprovechar para aclarar que aunque se diga que los discos duros SATA son de 300Mb/s, eso se refiere ¡a la máxima velocidad a la que pueden comnicarse! ¡Pero no a la velocidad que leen la información del disco! Normalmente no pasará de 20Mb/s… y eso en la mayoría de los casos ya es bastante… así que de poco sirve poder mandar cosas a 300 si las lees a 20… no? Otra cosa que me gustaría explicar, sobre porqué el southbridge es necesario, es que no sólo es un tema de velocidad. Se podría diseñar un sistema con un sólo centro de comunicaciones, como en la Dreamcast, y que éste adaptara las velocidades y se asegurara que los lentos no interfieran en las comunicaciones rápidas. Pero hay otros motivos que hacen que sea preferible dividir esta tarea en dos chips. Muy brevemente, los dispositivos «lentos» suelen ser dispostivios de I/O (entrada/salida) que se encargan de comunicarse con el exterior, y por su naturaleza, muchas veces tendrán que permanecer a la espera de que suceda ciertos evento (el dispositivo esté listo para leer o escribir, el DVD termine de acelerar el disco, la cabeza lectora del disco duro encuentre el cilindro correcto, el usuario tecleé, etc..) y durante ese tiempo de inactividad, el impacto sobre un dispositivo ultra rápido como una CPU es devastador. En cambio, las cosas que van conectadas al northbridge, la CPU, la RAM y el chip gráfico, casi siempre van a ir a toda pastilla, y no van a dar a basto en procesar y transferir la avalancha de datos que requiere cualquier aplicación medianemtne exigente. En fin, no se me ocurre ahora mismo como explicarlo de forma más simple, así que es lo que hay 😉 EL APARTADO GRÁFICO La fase de transformación En la Dreamcast, la tarea de transformación de geometría, es decir, los cálculos de las posiciones de los polígonos, es llevada a cabo en la CPU, como sucede en la Playstation 2, por ejemplo, aunque desde la Xbox, es algo que suele recaer en la GPU. Como ya expliqué en anteriores entregas, la fase de transformación requiere un alto número de operaciones en coma flotante. El SH4 dispone de una unidad especial de aritmética en coma flotante, con un rendimiento teórico máximo de 1400 MFLOPS, que en su época suponía una importante mejora frente a los sistemas existentes.Voy a explicar brevemente cómo funciona la unidad de coma flotante del SH4, que amasa y mueve los polígonos que vemos en los juegos de Dreamcast. Se trata de un circuito capaz de realizar 4 multiplicaciones en paralelo en un sólo ciclo de reloj, y luego sumar el resultado de las 4 multiplicaciones en el siguiente ciclo. Esta operación combinada de multiplicación/suma es muy importante en el campo del procesamiento de señales, gráficos, etc. y recibe el nombre de FMAC (ya comentada en el artículo sobre la Playstation 2). Sin duda, puede parecer extraña a alguién sin conocimiento, que seguramente pensaría que es más lógico disponer de multiplicadores y sumadores independientes. La clave del diseño es que las operaciones de producto vectorial con matrices requieren precisamente de operaciones FMAC. Y los polígonos están definidos como matrices. Luego, como en su procesamiento se requieren muchas operaciones FMAC, parece ya razonable construir un circuito que ejecute estas operaciones a una alta velocidad. Y el SH4 de la Dreamcast dispone de una de estas unidades. Cada FMAC de 8 operandos implica 7 operaciones (4 multiplicaciones de 2 números, y 3 sumas de 4 números). La unidad de coma flotante del SH4 es capaz de hacerlas en 3 ciclos (uno para las multiplicaciones, otro para la suma y otro para la escritura del resultado). Pero como su arquitectura está segmentada, después de las multiplicaciones, mientras se hacen las sumas, otro conjunto de números pueden pasar a la etapa de multiplicaciones. De esta manera, cada ciclo puede empezar una nueva FMAC de 8 operandos. Y como la unidad funciona a 200 MHZ, obtenemos los 1400 MFLOPS.< 200MHZ * 7 = 1400 MFLOPS Y ahora queda clara la idea de que estas 1400 millones de operaciones en coma flotante por segundo sólo son alcanzables si todas ellas son FMAC. Si sólo se quieren hacer multiplicaciones de 2 números, el rendimiento bajaría a 200 MFLOPS en esta unidad, según mis cálculos. Lo mismo que si sólo se hicieran sumas. Y si queremos hacer sumas de 2 multiplicaciones, conseguiríamos 600 MFLOPS. Pero estos casos no son los que más nos interesan, pues la mayor carga de trabajo en coma flotante viene de tareas intensivas en FMACs, donde el SH4 se vuelve un turbocompresor. Sólo es cuestión de saber aprovecharse de esto. Ahora un pequeño matiz. El Emotion Engine de la Playstation 2 dispone de 10 unidades FMAC de 2 operandos cada una. Es decir, cada una se encarga de una multiplicación y una suma, y son menos potentes que la unidad de la Dreamcast, que trabaja con 8 operandos. Se podría ver como que 4 FMACs de la Playstation 2 equivalen a la unidad en coma flotante del SH4. Pero aún así, el alto número de FMACs en la consola de Sony, y una velocidad 100 MHZ superior, la lleva a unos 6000 MFLOPS. Y hay que sumar otros 200 MFLOPS extras en operaciones de división, para las que dispone de unidades FDIV especiales, que no existen en la Dreamcast. No obstante eso no quiere decir que la Dreamcast sea mala. Simplemente que en ese aspecto, la Playstation 2 era una mala bestia. El rendimiento que ofrece la Dreamcast es más que suficiente para hacer juegos con un aspecto gráfico muy agradable, con efectos muy chulos, y dejar competamente atrás a sus consolas contemporaneas, la Play, la Saturn y la N64. Durante la fase de transformación, se calcula la posición de los vértices de los polígonos dentro de un modelo matemático, la iluminación de los vértices, su perspectiva desde el punto de vista de la cámara, la proyección sobre una imagen 2D, que pueda ser representada en una pantalla, y la eliminación de las zonas no visibles en el campo de visión. Todos estos procesos requieren muchos cálculos. En la Dreamcast se lleva a cabo por la CPU, su SH4 a 200 MHZ, que aunque más lento que un Pentium III a 400 MHZ, podría igualar su rendimiento en coma flotante. La fase de transformación e iluminación en los sistemas actuales es llevada a cabo en el chip gráfico, que suele llamarse GPU (Unidad de Procesamiento Gráfico). Esto pemite aliviar en gran medida la carga de la CPU, para que pueda dedicarse a otras tareas. Las primeras videoconsolas en emplear una GPU fueron la Xbox (NV2A) y la Gamecube (Hollywood). La primera GPU de la historia fue la tarjeta gráfica Geforce 256 de NVIDIA, para PC. La Dreamcast y la Playstation 2 no disponen de GPU, pues su procesador gráfico no es capaz de realizar la transformación e iluminación, y sólo se ocupan del renderizado. La fase de renderizado El chip gráfico de la Dreamcast, el PowerVR2, que funciona a 100 MHZ, se encarga del renderizado. Esta fase consiste en construir triangulos a partir de los vértices, rasterizar la escena, es decir, rellenar los triangulos con píxels, convirtiendo así la escena en un conjunto de píxels, determinar qué partes de la escena son visibles y cuales no, por haber sido ocultadas por otros objetos, y posteriormente texturizar y aplicar otros efectos a los píxels, para finalmente calcular sus atributos finales. Es entonces cuando el chip los almacena en el buffer de video, para ser enviados a la pantalla cuando sea necesario. El PowerVR2 parece tener una tasa de relleno de entre 100 y 300 MPixels/s. Esta cifra indica el máximo número de pixels que puede generar y dibujar cada segundo. Y no es un valor muy alto si lo comparamos con la Gamecube (más de 600 MPíxels/s), la Xbox (alrededor de 1000 MPíxels/s) o la Playstation 2, con su máximo teórico de 1200 MPíxels/s con una sóla textura aplicada, que no obstante está limitada por otros factores, que impiden alcanzar esta talla de relleno. Para poder aprovechar la tasa de relleno al máximo, se debe haber calculado previamente todos los anteriores pasos de transformación y renderización. Si el sistema no da a basto calculando la geometría de la escena, dificilmente podrá generar y dibujar píxels que no hayan sido ya procesados. Por eso, no hay que pensar que la Dreamcast es poco potente por tener una tasa media de relleno de 200 MPíxels/s. En realidad, es un valor suficiente para mover más de tres millones de polígonos por segundo. Y no por tener una tasa de relleno de 1200 MPíxels/s se va a poder mover más polígonos, si las etapas previas no son suficientemente rápidas como para suministrar al rasterizador con un buen caudal de datos. La Playstation 2 muy dificilmente puede llegar a aprovechar su alta tasa de relleno, porque su chip gráfico es simplemente escepcional en este apartado, mientras que no lo es tanto en otros, que limitan su aprovechamiento total. Por ejemplo, el PowerVR2 soporta por hardware efectos de transparencia, niebla, etc..., mientras que el Graphic Synthesizer de la Playstation 2 no, y por tanto la consola debe hacer todo esto por software, lo cual merma en gran medida su alto rendimiento teórico sobre papel. Ni de coña esperéis que mueva en un juego real los 66 millones de polígonos que anunciaba Sony, ni la de muchas otras estimaciones menos absurdas. Parece ser que un valor de entre 5 y 15 millones de polígonos por segundo es algo más real. La capacidad de la Dreamcast, por su parte, parece moverse en torno a los 3 millones de polígonos por segundo. La Gamecube parece rondar entre los 6 y los 12, y la Xbox más que cualquiera de estas, pero seguramente no mucho más. Para acabar, cabe mencionar que el VR2 utiliza un sistema llamado "tile rendering" para renderizar la escena. Si has leido mi anterior artículo (y lo recuerdas, que es otra, jeje), o conoces el modo en el que la Xbox 360 renderiza la imagen cuando no cabe en el buffer de su eDRAM, te interesará y te sonara esto. No entraré en detalles, pero el tile rendering se basa en ir renderizando la imagen por partes. Es como si se dividiera la pantalla en una cuadricula, y se fuera generando la imagen en una cuadricula, y una vez esa estuviera acabada, se pasara a otra cuadrícula. Los beneficios de esta técnica son múltiples, pues permite, por ejemplo, hacer un mejor uso de los buffer de vídeo, pues se trabaja sobre un menor area, y una menor cantidad de información a la vez. Es como aprobar una asignatura por parciales, en lugar de presentárse a un exámen final. Puedes preparar más fácilmente cada una de las partes, pues no tienes que preocuparte por lo que no cae en cada parcial, pudiendo dejarlo fuera de tu "buffer mental". Obviamente esta técnica requiere añadir una cierta complejidad al diseño del chip gráfico, y que yo sepa, sólo la Dreamcast y Xbox 360 emplean técnicas de tile rendering. Pero a mis 24 años voy estando mayor, y a lo mejor me falla la memoria (el buffer o la caché, vete a saber). MEMORIA DE VIDEO El último aspecto importante relativo al rendimiento de la arquitectura es la memoria de video, o VRAM. Si has leído mis últimos artículos (en especial los últimos 3), tendrás ya una idea tanto de la importancia de este tema, como de cómo realiazar un análisis básico del diseño. De momento, recuerdo que la memoria de video es usada para almacenar la información requerida por el chip gráfico, donde cabe destacar los datos de los polígonos, las texturas y los buffer. El buffer es siempre algo importante a considerar. Se trata de una zona de memoria donde se guarda la representación de la pantalla hasta el momento adecuado para mandarlo al televisor. Puede parecer una tonteria a alguién sin conocimientos en este area, pero para los rápidos circuitos electrónicos, el periodo entre 2 refrescos de la imagen de un televisor es una eternidad. La Dreamcast suele usar una resolución de 640x480 con color de 16 bits, lo que quiere decir que la imagen está constituída por 307200 píxels (640 de largo, por 480 de alto) y cada píxel requiere de 16 bits para especificar su color. El tamaño del buffer para este tipo de imagen es de 600 Kb: (640 * 480 * 16) / 8 Además, a veces se usa doble buffer, u otros buffers como el buffer Z, que contiene información sobre la profundidad de los objetos desde el punto de vista de la cámara. 2 buffers de 16 bits ocuparían 1,2 Mb de los 8 Mb disponibles en la Dreamcast, o un 15%. Que no está nada mal. Ahora vamos a hacer una estimación sobre el posible tamaño de los polígonos en la VRAM. Venga. Supongamos que se están moviendo unos 3 millones de polígonos. A una tasade refresco de 60 Hz (estándar NTSC), esto querría decir que hay unos 50,000 polígonos en la escena. Voy a suponer que la información requerida para almacenar cada polígono consiste en 3 números de 32 bits para cada vértice ( posición X, Y y Z), para cada uno de los 3 vértices de un triángulo. Esto quiere decir que serían necesarios unos 36 bytes por polígono. En total, 50,000 * 36 = 1,8 Mb. Suponiendo este hipotético caso de 2 buffers de 16 bits y 3 millones de polígonos por segundo, 3 Mb de la memoria de vídeo estarían ya ocupados, restando 5 Mb para texturas. Esta cifra no es muy elevada, pero no está nada mal, teniendo en cuenta que la rápida eDRAM de la Playstation 2 apenas dispone de 2 Mb para texturas, siendo el resto es almacenada en la memoria RAM. Cabe aclarar que 2 Mb de texturas para un juego mínamente decente es una miseria muy miserable. Lo que quería decir es que realmente la memoria de vídeo de la Dreamcast es suficiente para el propósito, aunque como ocurre el 100% de las veces, un poco más de VRAM se agradecería. Pero es como el dinero. Un poco más siempre es bienvenido en este mundo movido por dinero. E igualmente, en un mundo movido por la imagen, un poco más de VRAM es algo muy bueno. Pero muy caro también. Y como ese mundo de imagen es para un mundo donde el dinero manda, pues ya está bien de reflexiones que no vienen a cuento ;P. A esto hay que añadir que la Dreamcast emplea un sistema de compresión de texturas llamado VQ (vector quantization), que se vende como capaz de comprimir texturas a un 20% de su tamaño original, como media. Y ojito que la Play2 NO usa ningún sistema de compresión. Desde mi punto de vista es una tontería, pues se ahorra bastante espacio y la pérdida de calidad no es para tirarse de los pelos y ponerse a chillar. De hecho la Gamcube también emplea compresión. Es una idea magnífica, para exprimir al máximo la VRAM disponible, y poder empujar alguna textura más en las escenas. AY, ESA BIOS... Como muchos saben, la Dreamcast no necesita ser modificada para poder correr backups. Realmente, pocos saben lo que se esconde tras esta afirmación. El sistema de seguridad de la Dreamcast, que hereda en parte del de su predecesora, la Saturn, es bastante sofisticado. De hecho, el sistema de seguridad de la Saturn no ha podido romperse después de muchos años de intentos por parte de mucha gente, debido principalmente y por lo que parece, a un anillo de seguridad grabado en la parte externa de los CD originales, que nadie ha conseguido entender o replicar. Existen modchips para Saturn, que una vez instalados, saltan esta comprobación, y permiten, como todos los modchips, cargar backups. Pero nadie ha podido copiar un CD de Saturn de modo que una consola sin modificar lo acepte. En cambio, es muy facil leer y copiar un juego de Saturn en cualquier grabadora, aunque la copia resultante requiera modchip para cargarse. La Dreamcast en cambio usa un soporte llamado GD-ROM, que no puede leerse en un lector de CD o DVD estándar, porque ha sufrido diversas manipulaciones sobre la estructura básica de un CD o un DVD, y que por tanto dificulta mucho su replicación. De hecho, debe usarse una Dreamcast para ripear los GD-ROMs, y pasarlos a un ordenador a través del puerto serie de la consola, a una velocidad bastante lenta. Pero los backups NO cargan en una consola sin modificar, al contrario de lo que muchos creen. En cambio, hay mucha gente que juega con copias en consolas sin modificar. ¿Por qué? La BIOS de la Dreamcast tiene una vulnerabilidad crítica, que una vez explotada, permite cargar cualquier juego grabado en un CD normal. Para poder aprovecharse de ello, hay que parchear los juegos y convertirlos en lo que se suele conocer "autoboot". Si no se hace esto, se requiere arrancar primero con un CD que lleve este parche, como el famoso utopía, que se cargue en la memoria de la consola, y permita luego cambiar el CD por cualquier copia que no sea "autoboot", encargándose el utopia de abrir el fallo de seguridad de la consola, y permitirle el paso, como si aqui no pasara nada. No voy a dar más detalles, pues aunque mi motivación es puramente educativa y de investigación, estos temas atraen a mucha gente cuyos objetivos son ilegales, y por tanto, no libremente discutibles. Así que ya sabéis, nada de emails pidiendo herramientas para parchear backups y hacerlos "autoboot", ni utopías, ni imagenes de juegos, ni nada por el estilo. Sólo preguntas técnicas, gracias 🙂 CONCLUSIÓN. En esta ocasión seré breve y conciso: la Dreamcast se sale. Ala 🙂 www.consolasparasiempre.net