La carrera de los bits y los megahercios, segunda parte

encabezado-carrerabits

Videoconsolas y PC

Las consolas clásicas en un vistazo

Las primeras videoconsolas de cierta potencia, capaces de mostrar un plano de scroll y sprites con un mínimo de detalle, como la NES o la Master System, eran en su esencia muy parecidas a los ordenadores de la época, como el Spectrum, Amstrad o Commodore, y estaban constituidas principalmente por:
  • Una CPU de modesta potencia (hoy día, de ínfima potencia, desde luego)
  • Una pequeña cantidad de memoria RAM, de la cual parte estaba dedicada a tareas gráficas y parte estaba dedicada a propósitos generales
  • Uno o varios coprocesadores diseñados para realizar tareas relativas al juego (vídeo y audio, generalmente). Sin esta ayuda, la CPU hubiera sido incapaz de manejar los juegos que lo hacían estas consolas. Tendrían que haber sido más sencillos, como los de Atari o Amstrad. Pero hasta la fecha los videojuegos han tendido al perfeccionamiento, y éste fue un paso importante.
Una Master System, por ejemplo, sin coprocesadores tendría una potencia equivalente a un Spectrum+, y no creo que pudiera mover juegos mejores que los que salieron para el Speccy (nombre cariñoso del popular ordenador de Sinclair). La única ventaja sería que no tendría tiempos de carga, al usar cartucho en vez de cinta, y que podría manejar juegos más grandes, porque la Master System usaba mapeadores para generar la ilusión de que la memoria era más grande de lo que era.(Si el término mapeador no te es familiar, tal vez quieras echarle un vistazo a mis tutoriales en Consolas para siempre, apartado de documentación, “Lo + básico de NES”, “Lo + básico de Master System”).Echemos un breve vistazo por encima a la NES y la Master System. Valores aproximados, no es mi intención dar una especificación exhaustiva:
 NESMaster SystemPC modesto de la época (1990)
CPU6502
8 bits
1.7MHz
Z80
8 bits
3.5MHz
386
32 bits
25MHz
RAM principal2Kb8Kb4Mb
RAM de vídeo2Kb16Kb512Kb
Procesador de vídeoPPU
Chip diseñado en exclusiva
VDP
Chip diseñado en exclusiva
VGA (con suerte)
Procesador de audioNo disponible*Integrado en el VDP
Tamaño máximo de memoria manejable64Kb64Kb4Gb**
Tamaño máximo de un juego1Mb512KbEn principio, mucho :-)***
Otros

* La CPU se encargaba de esta tarea, para lo que se modificó la CPU 6502 original.

** Máxima cantidad de memoria RAM que puede usar (sin contar memoria virtual).

*** Limitado por el tamaño máximo de memoria virtual, que es un Terabyte. Lógicamente, la verdadera limitación era el tamaño del disco duro y la memoria RAM instalada. En aquella época los discos duros rondarían los 100 ó 200Mb, y sobra decir que ningún juego de entonces ocupaba esa monstruosidad.

De momento vemos que nuestras 8 bits en poco o nada se pueden comparar a un PC actual, cuya CPU ronda los 2GHz, y tiene una memoria RAM de al menos 512Mb. Supongo que esto se veía venir (espero). Más interesante es saber que eran máquinas mucho menos potentes que un PC de la época, en cuanto a los números al menos. Pero ya sabemos que el término potencia depende mucho de a qué nos refiramos, y de cómo la manejemos. De momento diré que eran arquitecturas muy distintas, orientadas a tareas muy diferentes.

Las consolas de 16 bits: el auge de las 2D

Las consolas de 16 bits, Mega Drive y Super Nintendo, pueden verse como una evolución de la arquitectura de sus predecesoras más que como una revolución. No constituyen en sí un cambio radical de concepto, sino que amplían el esquema de las 8 bits con más potencia. Con ellas llegamos a la época dorada de los juegos en 2D.
 SNESMega DrivePC modesto de la época (1993)
CPU65816
16 bits
3.5MHz
Motorola 68000
16 bits
7.5MHz
486DX2
32 bits
50MHz
RAM principal128Kb64Kb8Mb
RAM de vídeo64Kb64Kb1Mb
Procesador de vídeo2 PPU*
Chips diseñados en exclusiva
VDP**
Chip diseñado en exclusiva
VGA o SVGA
Procesador de audioDos chips de Sony, con capacidad de sonido digitalUn chip de Yamaha
Otro chip integrado en el VDP***
Sound Blaster 16
Tamaño máximo de memoria manejable16Mb16Mb4Gb
Tamaño máximo de un juego4Mb4Mb
OtrosCoprocesador Z80 a 3.5MHz

* Se llaman igual que el de la NES, pero no tienen nada que ver. PPU significa chip de imagen (Picture Processor Unit), y así es como lo llamó Nintendo. En la SNES son mucho más potentes.

** Igual, es una versión mejorada y ampliada del VDP de la Master System. VDP es el nombre que eligió SEGA para el chip gráfico y significa Video Display Processor.

*** El que está integrado da la funcionalidad de sonido que tenía ya la Master System. El Yamaha es el que expande la potencia sonora de la Mega Drive.

De acuerdo; como se puede ver y ya adelanté, todavía no hay por dónde coger al PC. En los años que pasaron entre las 8 y las 16 bits, los ordenadores personales evolucionaron bastante. Pero es precisamente ahora cuando llegamos al punto interesante de este articulo.

Llegan las 3D: entendiendo el cambio que ello supone

A partir de ahora me referiré a las videoconsolas de 32 bits en adelante, es decir, las de la era 3D.

Aplicaciones estáticas y aplicaciones multimedia.

En primer lugar, un videojuego no es más que un programa. Software. Muy similar al resto de programas que usas en tu ordenador, pero concebido para entretener. No obstante, hay diferencias entre un programa estático típico, como tu procesador de textos o tu navegador, y una aplicación multimedia o dinámica, como los videojuegos. Y estas diferencias son cruciales para entender el rendimiento y la potencia de una videoconsola y un ordenador frente al juego.

Primera diferencia: operaciones en coma flotante

La mayoría de los programas estáticos realizan casi todas sus operaciones con números enteros (positivos y negativos, sin decimales). Por ejemplo, 5, 2, -3, 37, etc.En cambio, las aplicaciones dinámicas hacen un uso más o menos intensivo de operaciones en coma flotante (números positivos y negativos, con un número variable de decimales). Como mínimo habrás oído hablar de este tipo de operaciones. Para quien no sepa a qué me refiero, daré unos ejemplos.
Notación científica2×103-5×1063,5×10-43,38×10-1
Representación estándar2000-50000000,00350,338
Los números en notación científica se forman por un número que multiplica a una base elevada a un exponente. Por ejemplo:

  • El primer número de la tabla es un 2, por base 10 elevada a 3. Significa es que al 2 hay que multiplicarlo 3 veces por 10.
  • El segundo número es un -5 por base 10 elevada a 6. Al -5 hay que multiplicarlo 6 veces por 10.
  • El tercer número, como tiene exponente negativo, hay que dividirlo 4 veces por 10.
  • El cuarto número te lo dejo a ti
Básicamente, se trata de escribir el número y correr la coma hacia la derecha tantas veces como indique el exponente del 10, si éste es positivo (añadiendo ceros si es necesario), o hacia la izquierda, si dicho exponente es negativo.Un número en notación científica que se almacena en binario en un computador siguiendo una serie de normas, forma un número en coma flotante. Las operaciones en coma flotante son más lentas y requieren un hardware más complejo que las operaciones con enteros. ¿La ventaja? A veces son imprescindibles.Hay aplicaciones que necesitan manejar un número variable de decimales, cosa muy útil e interesante por ejemplo para cálculos matemáticos o físicos que hay tanto en programas científicos como de simulación. También las aplicaciones de compresión de vídeo o audio, y por supuesto los videojuegos en 3D, hacen un uso intensivo de operaciones en coma flotante.

Segunda diferencia: datos e instrucciones. Entendiendo cada cosa

Los programas están formados por una secuencia de instrucciones que la CPU va ejecutando una tras otra. Estas instrucciones operan a su vez con datos, ya estén éstos almacenados en el propio programa (por ej. en una ROM), en la memoria de la máquina (RAM), en la caché o en los registros de la CPU.carrerabits-esq01En un sistema mínimamente complejo existe una jerarquía de memoria. La memoria secundaria es un almacén masivo de datos (ej. disco duro, CD o DVD). Todos los datos aquí guardados deben ser cargados en memoria RAM antes de poder ser usados por la CPU. De ahí que los “loading” aparecieran con las consolas de CD. Lo que hace el “loading” es cargar información en la memoria RAM, es decir, subir por la jerarquía de memoria. La RAM es mucho más rápida que la memoria secundaria, pero es mucho más cara. Por ello, para mejorar el rendimiento del sistema se usa una pequeña cantidad de RAM en combinación con una memoria secundaria mucho mayor. Así, en la PlayStation o en la Saturn podíamos tener juegos de hasta 650Mb, con una memoria RAM de sólo 2Mb. De esta manera, se puede “virtualmente” cargar todo el CD, pero en fracciones de 2Mb. Cuando se requiera otra información (ej, pasamos de nivel), habrá que remplazar los datos de la RAM por otros nuevos. Es decir, la RAM se usa como buffer (almacén temporal).Aunque son técnicas muy diferentes, a efectos prácticos es similar a lo que conseguían los mapeadores en las 8 bits: dar la ilusión de tener una memoria más grande, haciendo visible a la CPU una pequeña porción del juego en cada momento. Pero con los mapeadores no existía una desventaja muy relevante, que sí aparece en la era CD: los tiempos de carga.En los cartuchos no había pantallas de carga porque los juegos estaban almacenados en memoria ROM, que es tan rápida como la RAM y permite ejecutar directamente desde ella. Pero ya podemos ver la desventaja de esto: el coste. La ROM es mucho más cara que un CD o un disco duro. Por eso, cuando aumentaron las necesidades de tamaño, se pasó a otro soporte de menos coste por byte.

La caché va más allá

La idea de la caché es añadir a la jerarquía de memoria un nivel más rápido que la RAM. Todo lo que la CPU va requiriendo se carga en la caché. Ésta tiene una capacidad muy pequeña, pero su velocidad es endiablada y su cometido es guardar los datos e instrucciones que la CPU ha necesitado recientemente.carrerabits-esq02

Sólo unos pocos bloques de los que están en la RAM se guardan en la caché. Los bloques grises son bloques usados pero que no están en la caché. Los blancos son bloques vacíos. Es sólo un ejemplo.

Así pues, en la caché se almacena un conjunto muy pequeño de información con la que está trabajando la CPU. La ventaja es que mientras lo que queramos esté en la caché podremos disponer de ello muy rápidamente porque no habrá necesidad de traerlo de nuevo de la RAM, que lleva mucho más tiempo. Y por lo tanto, es lo mismo que cargar del CD a la RAM. Lo que ya está en la RAM no hay que leerlo del CD. Pero la caché va más allá, porque permite que la CPU trabaje mucho más eficientemente, y cuando funciona bien, imprime una mejora masiva de rendimiento.En una aplicación dinámica (por ejemplo, un videojuego), donde una serie de operaciones tienen que hacerse en un tiempo determinado, es vital que todo se haga lo más rápido posible (y si no, pues ya se sabe, el juego se ralentiza, da trompicones y esas cosas).Todo el rollo de la caché sirve para entender lo que viene a continuación.Una aplicación estática suele operar con un conjunto de datos más o menos definido, pero siguiendo un flujo de instrucciones en principio desconocido, que varía constantemente. Algunos os preguntaréis de dónde saco esto. Fíjate en que este tipo de programas suelen tener muchas opciones distintas al alcance del usuario. Por ejemplo, en un procesador de textos podría crear tablas, pasar el corrector ortográfico, hacer una conversión… tareas variopintas a las que el usuario puede acceder cuando quiera, pero que operan sobre unos mismos datos (el documento).Una aplicación dinámica suele operar con un volumen muy elevado de datos. Un juego requiere procesar continuamente las posiciones de los objetos, la rotación de los polígonos, la física… y todo eso es un chorro constante de datos que vuelan a toda velocidad hacia la CPU. En cambio, muy a menudo este procesamiento es llevado a cabo por porciones pequeñas de código con unas pocas instrucciones que se repiten muchas veces.Esto es muy importante, porque va a condicionar enormemente el rendimiento de la caché.

Cuadro resumen del uso de las cachés

Los diagramas que siguen muestran la caché como un almacén, con dos “cañerías” para meter y sacar información. La parte coloreada de la cañería simboliza el caudal que entra y sale, y los bloques coloreados de dentro de la caché, la cantidad de información que se reutiliza, o en otras palabras, que beneficia al rendimiento.La caché suele estar dividida en caché de instrucciones y caché de datos.

Caché de instrucciones

Las aplicaciones estáticas hacen un uso regular de la caché de instrucciones, porque su eficiencia depende de muchos factores, y habitualmente el flujo de instrucciones es muy variable; esto es, las instrucciones no permanecen mucho tiempo en la caché para ser reutilizadas, sino que son sustituidas por nuevas instrucciones antes de que pueda sacarse un buen provecho.Las aplicaciones dinámicas hacen un uso muy bueno de la caché de instrucciones porque como ya comenté, los cálculos son a menudo realizados por relativamente pocas instrucciones que se repiten muchas veces.carrerabits-esq03

Caché de datos

Las aplicaciones estáticas hacen un uso razonablemente bueno de la caché de datos, en función del caso, porque a menudo todos los datos que se necesitan intensivamente caben en la caché y el flujo de datos no suele ser muy rápido (la cañería lleva poco caudal).Las aplicaciones dinámicas hacen un uso pésimo de esta caché, porque el flujo de datos es muy rápido (la cañería lleva mucho caudal), y a menudo la información que entra en la caché no vuelve a usarse, por lo que hay que estar continuamente sacando datos para meter otros a toda pastilla.carrerabits-esq04
Básicamente, las aplicaciones estáticas hacen buen uso de la caché de datos y malo de la de instrucciones, y las aplicaciones dinámicas todo lo contrario, aunque tal vez peor, porque el pésimo uso de la caché de datos está agravado por el elevado ritmo y la masiva cantidad de datos que se mueve.El tema de la caché es mucho más complejo, y he ocultado detalles para no enfarragar. En futuros artículos tal vez retome el tema. De momento no quiero perder el hilo.

Tercera diferencia: ancho de banda

El ancho de banda es la capacidad de un canal para transmitir información. En nuestro caso, el ancho de banda será el número de bits por segundo que se pueden transferir. Este flujo de datos se envía casi siempre por medio de buses.Un bus es un canal de comunicación compartido. A él van conectados distintos dispositivos, de los que sólo uno puede emitir, mientras el resto escuchan. Cuando muchos quieren emitir a la vez, se debe esperar y se degrada el rendimiento.En la imagen de abajo se ve un ejemplo ficticio.Las líneas de color oscuro son buses. Como puede verse, hay un bus ancho entre la CPU y la memoria RAM y otro más estrecho que comunica la CPU, un procesador de entrada/salida (I/O) y un coprocesador (Cop). Mientras que la CPU puede enviar y recibir datos de la RAM cuando quiera por medio de su bus dedicado, sólo puede comunicarse con el procesador de entrada/salida si ni éste ni el otro coprocesador están enviando datos.carrerabits-esq05El ancho de banda de un bus es el número de bits que se pueden trasmitir por él cada segundo. Siempre que no sea imprescindible, un bus se comparte por varios dispositivos, ahorrando así tener que conectarlos individualmente, uno por uno.Por tanto, un bus debe verse como una autopista de datos usada por muchos contribuyentes, respetando la norma de que sólo uno esté enviando información en cada momento. Así que todos se comportan amigablemente, y por tanto, si yo quiero mandar algo y otro está en posesión del bus, debo esperar.

A veces esto no es tolerable, porque se necesita asegurar un cierto caudal de datos, así que se utilizan buses dedicados para conectar dos dispositivos, como la CPU y la RAM del dibujo. Así se evitan esperas innecesarias y ralentizaciones debido al tráfico de otros elementos del sistema.Por ejemplo, se podría haber hecho esto:carrerabits-esq06Así no habría ningún tipo de espera por incordio del vecino. Pero esto que a priori parece razonable, no suele ser común. Resulta mucho más caro, sobre todo porque en un sistema real hay muchas conexiones que hacer. No son esquemas tan sencillos. Y el coste adicional es en dinero, y también en superficie de circuito. Más conexiones implica trazar más pistas, y siempre interesa mantener todo lo más pequeño posible.Una aplicación estática suele trabajar bien con grandes cachés, donde quepan la mayor parte de los datos e instrucciones que se necesitan. De este modo, no se requiere un gran ancho de banda entre la CPU y el sistema porque los accesos a memoria no son continuos, la comunicación con dispositivos externos (como una memoria USB) consume muy pocos recursos, y además no suele haber una restricción muy fuerte de velocidad. Es decir, menos rendimiento implica esperar unos segundos más a que el procesador de textos exporte nuestro documento a otro formato, por ejemplo, pero nada más.Una aplicación dinámica no puede apoyarse únicamente en más caché. El torrente de datos es masivo, y se requiere cambiar el enfoque de diseño si queremos hacer consolas potentes. Y no basta tampoco con hacer una súper-CPU, como muchos creen, porque lo más importante es mantener esta súper-CPU alimentada continuamente de datos e instrucciones que deben traerse de la memoria a gran velocidad. Si no, la súper-CPU se pasará la mayor parte de su super tiempo sin hacer nada, desperdiciando su potencia y los millones de euros que costó su desarrollo. Para el rendimiento de una videoconsola, el ancho de banda entre la CPU y el resto de dispositivos, en especial la memoria, es vital.

Requisitos de una consola 3D

Una consola 3D está concebida casi exclusivamente para ejecutar aplicaciones dinámicas, por lo que para ser potente y poder mover juegos más complejos deberá:
  • Ser muy rápida haciendo operaciones en coma flotante
  • Conseguir paliar el efecto del pésimo uso de la caché de datos
  • Manejar una alta tasa de transferencia de bits entre la CPU y el sistema.
Hablaré de lo primero más adelante. El resto lo ilustraré con un ejemplo.Imagina que eres el dueño de una fábrica que necesita de materia prima para elaborar un producto. Todo es transportado por camiones, que traen los materiales desde distintos lugares y llevan tu producto para ser vendido.Podrías pensar en usar camiones de gran tonelaje, que una vez por semana te abastecen, y en construir un enorme almacén en tu fabrica, para guardar toda la mercancía. De este modo, con buena organización, tu ritmo de producción sería constante a la máxima velocidad que te permitiera tu maquinaria, tus operarios, etc.Pero este esquema no es adecuado para todas las tareas. Imagina que tu fabrica usa productos perecederos, que no pueden ser almacenados mucho tiempo, y los consume muy rápido. Estos productos requieren condiciones especiales. Te resultaría muy caro usar camiones grandes, adaptados, a lo que habría que sumar además el coste del gran almacén.Con la solución esbozada anteriormente, lo único que podrías hacer es traer cuantos más productos fuera posible en los camiones, apilar todo lo que puedas en tu gran almacén, y empezar a rezar para que:
  • Nada se estropeé, o se eche a perder
  • El rápido ritmo de producción no consuma todas tus reservas antes del siguiente envío
No es una solución muy interesante; intentemos mejorarla.Para empezar, vamos mejorar los accesos a nuestra fabrica y nuestra logística, de manera que haya muchos más envíos. Vamos a usar más camiones, que lleguen más a menudo. Y nos vamos a ahorrar el gran almacén: construiremos un pequeño local que servirá de almacenamiento temporal, que contendrá los productos que acaban de llegar y esperan a ser procesados en nuestra fábrica.Asegurándonos un suministro constante y abundante tendremos nuestra fábrica funcionando al máximo de su capacidad. Ésta es la forma de trabajar de una consola. Un gran ancho de banda (muchos camiones, muchos envíos) que mueve el enorme flujo de datos por el sistema, y una memorias no muy grandes (pequeño almacén temporal), que no buscan guardar muchos datos, sino permitir un movimiento veloz y continuado, abasteciendo a la CPU y los coprocesadores con materia prima fresca.

Primera comparación entre consolas y PC

Ordenador PC
AplicacionesSon máquinas pensadas para ejecutar razonablemente bien un conjunto muy amplio de programas, y principalmente aplicaciones estáticas.
Coma flotanteAunque cada vez se le presta más atención, y los Pentium 4 y Athlon se han esforzado en mejorarlo, los PC se han caracterizado por un rendimiento en coma flotante mediocre en comparación con otros sistemas. Procesadores un poco más antiguos, como el Pentium y el K6, eran bastante lentos en este tipo de operaciones, lo que constituía uno de los principales limitantes en aplicaciones que se apoyaban en coma flotante, entre ellos los videojuegos.
Memoria y cachéSuelen tener una cantidad generosa de memoria RAM y una memoria caché lo más grande posible, aspirando a mantener la mayor cantidad de información retenida y apoyándose en ello para alcanzar un elevado rendimiento.
Ancho de bandaLa comunicación de la CPU con la memoria se hace a través de un bus principal, muy rápido (FSB). Para el resto de componentes se usan otros buses de menos ancho de banda:
  • Uno dedicado para la tarjeta gráfica (AGP).
  • Otro para las ranuras de expansión PCI.
  • Otros para los discos duros, USBs, puertos paralelo y serie…
Videoconsola
AplicacionesEstán pensadas para ejecutar un conjunto reducido de aplicaciones pero haciéndolo muy bien, principalmente aplicaciones dinámicas.
Coma flotanteEs un aspecto al que se le da mucha prioridad, y normalmente tienen un elevado rendimiento en este aspecto aspirando a hacer cuantos más cálculos sea posible, lo que se traduce en más polígonos y una física más compleja.
Memoria y cachéSuelen tener mucha menos memoria que un PC, y cachés más pequeñas, aspirando más a transportar la información muy rápido que a almacenar una gran cantidad, apoyándose en esto para alcanzar un elevado rendimiento.
Ancho de bandaLa comunicación entre la CPU y los distintos dispositivos está optimizada para alcanzar altas velocidades de transferencia, distribuyendo el tráfico a través de multitud de buses independientes estratégicamente colocados, que garantizan un alto rendimiento.
Todo esto es mucho más fácil de diseñar en una máquina como una consola, cuyo objetivo es muy concreto. Un PC es el blanco de un abanico de aplicaciones muy extenso, que complica su optimización, porque ya se sabe, no puede llover a gusto de todos.En la Dreamcast, el bus que comunica la CPU con la memoria tiene un ancho de banda de 800Mb/s. Por ese bus podría mandarse una cantidad de información equivalente a la que cabe en un CD, en menos de un segundo. Es mucha velocidad, sobre todo para su época (1997). Y por si 800Mb/s pareciese mucho, dentro de la CPU el bus que comunica la caché con las unidades de coma flotante tiene un ancho de banda de 3.2Gb/s. Parece que se busca hacer muchas operaciones en coma flotante. ¿Será casualidad? Como nota diré que este canal de 3.2Gb/s, que es sin lugar a dudas rapidísimo (y monstruoso para su época), no puede ser exprimido al 100% en aplicaciones reales ya que está limitado a la comunicación caché-unidades de cálculo, y la cache requiere ser rellenada, como es obvio. Los accesos a la RAM para refrescar el contenido de la caché echa abajo parte del rendimiento máximo teórico de la consola, que aun así es muy respetable.En la PlayStation 2, la memoria RDRAM tiene un ancho de banda de 3,2Gb/s (dos canales de 16 bits a 800MHz, o sea (2*16*800millones) / 8). Los buses internos del Emotion Engine pueden transportar hasta 2,4Gb/s, y la consola es mucho más potente que la Dreamcast en coma flotante, aunque hay que decir que los cálculos de rendimiento de SONY son, cuanto menos, muy optimistas en todos los aspectos. Eso de que la PlayStation es capaz de mover 60 millones de poligonos… jejej. Ni en sus sueños más salvajes, vamos. Claro, así los seis millones de polígonos que daba Nintendo para su GameCube parecía poca cosa. Pero en cambio, en aplicaciones reales no creo que la Play pase los 20 millones de polígonos (y creo que estoy siendo optimista), mientras que parece que la GameCube es capaz de sobrepasar los 12 millones de polígonos. Bueno, a lo que iba.Estaba hablando del rendimiento en coma flotante. El máximo teórico de la Dreamcast es 1,4GFLOPS. El máximo teórico de la PlayStation 2 es de 6,2GFLOPS. En la vida real, la Dreamcast puede alcanzar los 0,9GLOPS. En la vida real, la PlayStation 2 puede alcanzar los 2GFLOPS.Aviso de que todo esto es muy difícil de medir, y depende en gran parte de la aplicación, el detalle y la maestría de los programadores. Además, la PlayStation 2 tiene una arquitectura un poco extraña y difícil de manejar. En teoría es una mala bestia, pero en la práctica casi depende más de la habilidad de exprimir y usar eficientemente esa potencia.Más sobre esto pronto.

La comparación que sí vale

Ya presenté al principio un cuadro comparativo de las retroconsolas de 8 y 16 bits con los PCs de su época, pero ahora llega el momento de comparar una consola 3D, a la que se aplica todo lo que hemos hablado, y discutir los resultados.
 DreamcastPlayStation 2PC modesto de la época (1999)
CPUHitachi SH4
32 bits
200MHz
Emotion Engine*
64 bits
300MHz
AMD Athlon
32 bits
700MHz
Caché8Kb (instrucciones)
16Kb (datos)
40Kb (instrucciones)**
32Kb (datos)**
64Kb (L1)
512Kb (L2)***
RAM principal16Mb32Mb128Mb
RAM de vídeo8Mb4Mb (embebida)32Mb
Procesador de vídeoPowerVR2Graphics Synthesizer
Diseñado en exclusiva
GeForce 256
Tamaño máximo de un juego1Gb4Gb
OtrosUsa un ARM7 como coprocesador de audioEl procesador de I/O lleva «integrada» una PSX

Como anécdota, el ARM7 es la CPU que usa la Game Boy Advance, y el coprocesador de la DS.

* En el Emotion Engine están integrados la CPU, varios coprocesadores, las cachés y además una memoria especial de 16Kb muy rápida.

** Suma total de las cachés de la CPU y los coprocesadores.

*** Un poco más lenta que la caché L1, pero mucho más rápida que la memoria principal.

Como puede verse, y espero que no sea ninguna sorpresa, las especificaciones del PC siguen sobrepasando en todo y por bastante —aunque no tanto como antes— a las de una consola, o al menos eso parece. Se aprecia como las memorias son más pequeñas en las consolas, algo de lo que ya hemos hablado.Así que con toda esta información, pasaré a dar un breve repaso sobre la manera en la que procesan videojuegos un PC y una consola. Cuál es su estrategia, planteamiento, y cómo se las apañan para exprimir el máximo número de polígonos. A ver si consigo unir todo lo que he explicado en este articulo y dar una visión de conjunto que permita entender de dónde sale el rendimiento de nuestra consola.

En el próximo artículo…¡Enfrentaremos nuestra PS2 al PC! 🙂Hagan sus apuestas.Por cierto, iba a hacer una comparación Dreamcast vs PC, porque la de PlayStation vs PC es más típica, pero es muy didáctica y además supongo que captará más interés. Aunque si surge la posibilidad, escribiré sobre la Dreamcast 😉
Redactor
  1. neth

    Pues mucho más denso y técnico, pero  tan ilustrativo como la primera engtrega. Lectura obligada, enhorabuena.

  2. JakCore

    Creo que es imposible explicar este tema de manera más sencilla. Por cierto deberías poner un link al final del articulo enlazando con la primera parte. 

  3. patroclus

    En efecto, es mucho mas duro, pero como dice JakCore, es complicado exponerlo de forma mas asequible. No son cosas faciles. Pero cuando se sabe esto, comprender algo mas complejo es mas facil. Los articulos que estan por llegar seran mas digeribles ;) 

  4. Ikael

    Muy currado. El tema que trata es bien complejo, no muy apto para las masas, pero aún así lo has hecho bastante comprensible (en especial gracias a la metáfora de los camiones ;-)).

  5. Tito Almo

    Muy didáctico, con cosas así hasta los patanes podemos entender estos asuntos.
    Habría estado bien una comparaiva PS2/GC/XBox, pero vamos, que es un trabajo impecable

  6. patroclus

    Almorrano, el proximo artículo sera una comparativa PS2/PC, para ilustrar todo lo que acabo de explicar, pero tocare un poco la comparativa GC/Xbox/PS2 que tanta polemica ha dado ;-) 

  7. Tito Almo

    Ah, sí otra cosa más, hay que tener en cuenta la resolución, porque no es lo mismo la resolución que manejaba una Megadrive o SNES que la de un PC de la época, ese también es un factor y de los gordos pero que tal vez no pegase en esta entrega, que se centraba más en el manejo de información

    David, no lo tomes como crítica impertinente, al contrario, si se me van ocurriendo cosas es porque le sigo dando vueltas al artículo. ;)

  8. SpaceDevil

    Muy bueno el artículo. Sin embargo, me he quedado con una duda, cuando compara las consolas de 8 bits con los ordenadores de la época, dice que sin los coprocesadores, éstas serían igual de poco potentes que, por ejemplo, un Spectrum. Sin embargo, el ordenador MSX, y sobre todo, el MSX 2, tenían prácticamente la misma potencia que la NES o la Master System (recuerdo que el juego Rastan Saga era igual en estos dos últimos), ¿esto se debe a que los MSX tenían coprocesadores también, o que estos últimos iban integrados en los juegos de cartucho donde se alcanzaban esas altas prestaciones?. Lo digo, por que a priori, tanto el Spectrum como el MSX compartían el mismo procesador, el Z80.
    Gracias por todo. Me gusta mucho su página, aunque a veces pecan un poco de excesivamente nintenderos!!!, jejeje. Un saludo a todos.
     

  9. Tolrak

    Salacious Crumb, me alegro por tu pregunta, es muy buena. Te explico. En efecto, el MSX2 es una version mejorada del MSX1. Salio en 1985, poco antes que la NES (creo). El MSX 2 tenia mucha más memoria que el MSX1. Su BIOS era mas grande, su version de BASIC mejorada, y pasaba de tener unos 64Kb de RAM (maxima), a tener 128Kb.Como su CPU es la Z80, como mencionas, su potencia podría ser comparable a la de un Spectrum 2. Pero, en efecto, el MSX2 tenia un coprocesador gráfico, de la misma familia que el de la Master System, pero mejorado. En resumen los chips graficos de la Master Syste, y GameGear son una modificacion del TMS9918. Este chip era en origen poco potente, pero en las consolas de SEGA se le añadieron nuevas funcionalidades, mejorandolo bastante. El MSX1 tambien usa un chip basado en el TMS9918 (aunque a no se si mejorado o no)No obstante, el MSX2 usa el sucesor del TMS, el V9938, tambien de Yamaha. Este chip representa una mejora muy considerable. Añade modos de video nuevos, algunos muy potentes, mas colores por sprites, una paleta mas flexible, etc… Ademas, pasa de 16Kb de video a unos impresionantes 128Kb, que lo pone mas a la altura del chip de Megadrive que de Master System. Aunque desconozco si el MSX2 realmente podria igualar a una Megadrive, tecnicamente es muy similar, aunque sigue manteniendo una CPU de 8 bits muy inferior al 68000 de 16 bits de la Megadrive. Asi que supongo que este hecho colocará al MSX2 por debajo de las consolas de 16 bits.  Los MSX2 y Turbo mejoraron aun mas si chip grafico.  Asi que en resumen… si, tienen coprocesadores :-)

  10. patroclus

    UPPS!! Perdon. El post anterior es mio, solo que estaba trabajando en el ordenador de Tolrak, en el juego del que Ikael hablo en el blog hace poco.  ;-)

  11. SpaceDevil

    Muchas gracias por responder. En efecto, sospechaba que debían tenerlos, por que las diferencias gráficas entre los MSX y los otros ordenadores de su generación, eran abismales en según qué juegos.