hardware

Imagen de Diskover

El hardware de la NES. Capítulo III: Haciendo scroll

cabecera scroll

Como hemos visto antes en el funcionamiento de la PPU de la NES, esta tiene ciertas limitaciones; pero aun así no se corta ni un pelo para conseguir hacer otras cosas interesantes como por ejemplo un scroll suave, que hoy en día nos parece obvio, pero que en su momento no lo era tanto para la mayoría de las maquinas.

En una época (años 80 del siglo XX) donde las limitaciones abrían el ingenio de los programadores, no era raro encontrar soluciones más o menos factibles para problemas cotidianos en el mundo de los videojuegos. De esta forma, cuando los videojuegos empezaron a ser cada vez más sofisticados, se hizo necesario el abrir nuevas caracterizaras o metas que ampliasen la jugabilidad. De esta forma, pasar de pantallas estáticas a pantallas en movimiento para generar escenarios era una evolución natural cuanto menos.

Quizá para el diseño de una máquina arcade, era factible tirar de cheques bancarios y fabricar tecnología puntera para el entrenamiento a sabiendas de que en los salones recreativos se iba a recuperar lo invertido con creces. No obstante, en el mundo doméstico la cosa no funcionaba así, y siendo maquinas pensadas para estar durante años en el hogar, los costes de fabricación se median con lupa, así como sus componentes. Una familia no se podía permitir gastar medio sueldo de un año en una maquina, pero si el de medio mes.

Muchas consolas y micrordenadores de la época de la NES decidieron invertir sus cometidos en otras características, como puede ser más velocidad de procesamiento, chips de sonido distintos y más costosos, etc... que conllevaba que hubiese recortes en otros aspectos como, por ejemplo, procesadores gráficos más limitados o con características distintas. De esta forma, mientras que la PPU de la NES peca de controlar pocos colores por sprite y background, no escatimó en otras medidas como pudiese ser el permitir hacer desplazamientos de pantalla (scroll) mediante hardware; una características más de la PPU que daba como resultado un proceso limpio y suave. Otras máquinas eligieron otro camino y se quedaron sin esta característica, lo que provocaba que nunca consiguieran un scroll afable, o que este tuviera que ser generado por rutinas de software, lo que penalizaba a la CPU.

Posiblemente la elección de la NES sea la mejor decisión que pudieron tomar los ingenieros a la hora de crearla sobre el papel, y de esta forma vamos a ver como funcionaba tal característica en su PPU.

 

MOVIENDO LA PANTALLA

Para poder hacer scroll en la NES, esta necesita un espacio en la memoria de vídeo para generar los backgrounds (fondos de pantalla) por donde vamos a movernos. De esta forma, la NES utiliza cuatro tablas de memoria reservadas para este aspecto, configurables, y a las que llama nametables. Cada una tiene un sobre nombre y son A, B, C, y D; y son de 256x240 pixeles cada una. En estas nametables mostramos nuestros backgrounds y atributos de color.

Nada más empezar a programar un juego de NES, se debe configurar las nametables mediante la pauta mirroring: horizontal, vertical o las cuatro a la vez.

- Configurándolas en horizontal, podemos hacer scroll de derecha a izquierda aprovechando dos nametables seguidas. Esto nos da un área de 512x240 pixeles. Si hacemos scroll arriba o abajo pasaríamos por la misma nametable una y otra vez.

- Configurándolas en vertical, podemos hacer scroll de arriba a abajo aprovechando dos nametables seguidas. Esto nos da un área de exploración de 256x480 pixeles. Si hacemos scroll a la derecha o a la izquierda pasaríamos por la misma nametable una y otra vez.

- Configurando las cuatro a la vez, podemos hacer scroll libre por las cuatro nametables. Esto nos da un área de exploración de 512x480 pixeles.

Podemos configurar solo una simple nametable dándonos igual como hayamos configurado previamente el mirroring dejando el scroll estático. No pasa nada. Los primeros juegos de NES eran así y no hacían uso de esta peculiaridad como puede ser Donkey Kong, Tennis, Mario Bros., Baseball, etc...

Por ejemplo, Donkey Kong Jr. tiene un mirroring vertical, pero deja la pantalla estática en el Nametable A. Podrían haberlo configurado como mirroring horizontal, pero estaríamos igual dado que la pantalla nunca se mueve del Nametable A. Internamente queda así con su mirroring vertical:

En el caso de Lode Runner, tiene un mirroring horizontal. Usa la Nametable A y la Nametable B para crear los niveles, y con ello realiza el scroll.

Gauntlet sin embargo, aprovecha las cuatro nametables para crear los niveles.

Otros juegos más modernos siguieron limitándose a este tipo de scroll simple horizontal con buenos resultados, como pudieron ser Maniac Mansion:

O por ejemplo el videojuego TMNT Fighter entre otros:

Y luego tenemos casos como Devil World, que estaba creado con mirroring horizontal para moverse con suavidad de derecha a izquierda... pero cuando se movía de arriba a abajo surgió la primera experimentación con el scroll más allá de sus límites. No consiguieron encontrar la manera de hacerlo suave debido a que tenían que mantener constantemente el sprite zero en el marcador superior, y solo consiguieron hacerlo "a trompicones", actualizando tiles a lo bestia (cada 8 pixeles). Fueron unos primeros pasos, que conste.


¡Un momento! Hogan´s Alley hace scroll horizontal más allá de los límites! ¡De hecho, el juego tipo B, consta de 3 nametables en horizontal! Si, pero mediante un truco. Ya os comenté en el artículo anterior, que si quieres cambiar alguna nametable, la PPU debe apagarse durante unos instantes, dejándonos un parpadeo negro como consecuencia ¿entonces?

Bueno, el scroll lo hace la maquina cuando superamos a los enemigos de X habitación, por tanto no lo controlamos nosotros a voluntad y eso es una ventaja para la máquina. La nametable se actualiza cuando disparamos la zapper en algún momento, aprovechando que la pantalla se vuelve negra.

Entonces... ¿Y si quiero hacer niveles más grandes que el limite establecido?

 

El SCROLL MÁS ALLÁ DE SUS LÍMITES

Bien, aquí vienen los problemas, y la solución se encontró durante el desarrollo de Excitebike sobre el año 1984, y luego fue ampliamente explotado con la salida de Super Mario Bros. en 1985.

La idea que se encontró fue la de actualizar bloques de tiles fuera del área de visión. Una genialidad que solventó un problema muy gordo. La NES podía seguir haciendo un scroll suave mientras los escenarios se iban actualizando poco a poco fuera "donde no lo viésemos".

Este truco servia tanto si querías hacer scroll horizontal, como scroll vertical.

Con el paso de los meses, la técnica se depuró aun más y ya se podía hacer scroll vertical u horizontal sin penalizar tanto a la RAM, pudiendo guardar en un buffer los sitios por donde pasabamos, pudiendo volver sobre nuestros pasos. Juegos como Megaman hicieron gala de ello.


Pero yéndonos más allá ¿estábamos limitados al scroll horizontal y vertical? ¿no podíamos usar ese truco de actualizar bloques de tiles en cualquier dirección? Claro que si, y Rare dio con ello.

Aunque en el mismo año en que salia al mercado Super Mario Bros., Hudson Soft mostró su videojuego Raid on Bungeling Bay con scroll multidireccional, este era muy primitivo y no permitía colisiones sobre el background.

Rare llamó mucho la atención en Nintendo desde sus inicios por ser unos jóvenes ingleses que, sin saber muy bien como ni por que, se empeñaron en hacer un juego para la NES llamado Slalom allá por 1986 mediante el efecto raster que ya se usaba en su día en muchos juegos de conducción.

El problema es que Rare no tenía el equipo de desarrollo para programar aplicaciones en NES y todo lo que hicieron fue gracias a la ingeniería inversa. De hecho, la NES todavía no había salido ni en Europa. Evidentemente, cuando estos chicos se presentaron en las oficinas de Nintendo son su prototipo, los japoneses se quedaron con la boca abierta.

Pero como iba diciendo, Rare dio con la solución al scroll multidireccional con colisiones en 1987 cuando mostró su Wizards & Warrior al mundo y meses después RC-Pro AM.

Nota: los errores gráficos de las nametables están causados por el emulador.

Podéis apreciar perfectamente que corresponde al background y que son los sprites.

Aprovechando las cuatro nametables, los tiles de alrededor del área de visión (nuestra cámara) se iban actualizando según nos moviésemos por el escenario. Chapó.

 

PROBLEMAS DIFICILES DE SOLVENTAR

¿Os habréis dado cuenta de que muchos juegos de NES tienen una especie de error gráfico cuando la pantalla se mueve, sobre todo si son videojuegos donde el desplazamiento es en diferentes direcciones?

Bueno, esos "gliches" aparecen cuando por la forma de cargar metatiles que tiene el programa en cuestión, se queda corta de RAM y no le da tiempo a cargar los nuevos metatiles que forman el background a tiempo fuera de la pantalla visible. Por eso podemos ver como cambian estos, viendo durante un corto espacio de tiempo los metatiles de la primera columna de la pantalla.

Programadores más audaces conseguían apurar el código para que este error no ocurriese, pero lo cierto es que en gran parte del catalogo de NES que salió a la venta, ocurría.

 

PARA IR FINALIZANDO

Como podéis ver, la NES era una máquina tremendamente limitada pero en la que se invirtió muchísimo tiempo para investigar y poder solventar problemas o escollos a fin de darnos unos resultados satisfactorios.

Espero que esta información os sea de alguna forma de utilidad. No os perdáis el próximo capitulo.

Imagen de Diskover

El hardware de la NES. Capítulo I: Conceptos básicos

El hardware de la NES

La intención de este artículo no es más que la de demostrar las maravillas que se consiguieron hacer con una NES a lo largo de su vida útil y más tarde en el entorno de la scene homebrew que tan viva está hoy en día. No puedo ser muy técnico debido a mi falta de cualidades en entornos de programación o conocimientos, pero intentaré ser lo más preciso posible.

Partimos de una máquina limitada que a lo largo de los once años de estancia en el mercado (1983-1994), fue evolucionando tanto técnicamente como por hardware, compitiendo cara a cara contra Sega Master System, PC-Engine, SNES y Mega Drive.

Originalmente, debido al hecho de abaratar costes, la NES fue diseñada para que fuese ampliable constantemente. Algo muy inteligente para su diseñador, Masayuki Uemura. De hecho, el tiempo le dio la razón.

Así pues, la consola al desnudo, originalmente, nos presentaba una máquina escueta y limitada pero muy por encima de su competencia, lo cual era todo un logro. Estamos hablando del año 1983, y sus competidoras más cercanas en aquella época se reducian a la Atari 2600, Colecovision, Intellivision, etc... máquinas tambien de 8 bits (Intellivision es de 16 bits, ojo), pero muy escuetas o vagas en el resto de sus apartados.

Para entender esto, debemos repasar las características técnicas con las que la NES (Famicom en Japón) salió al mercado:

CPU (procesador): RP2A03, 1,79 MHz (NTSC) o RP2A03, 1,63 MHz (PAL) fabricado por Ricoh y basado en el MOS 6502.

- Dispositivo DAC.

- Controlador DMA.

RAM: 2Kb.

PPU (procesador gráfico): RP2C02, 5,37 MHz (NTSC) o RP2C07, 5,32 MHz (PAL).

- Paleta: Compuesta por 48 colores y cinco grises de base; rojo, verde, y azul se pueden oscurecer individualmente en regiones específicas de la pantalla usando código temporizado. Esta paleta dicen que fue seleccionada por el propio Shigeru Miyamoto y le supuso un verdadero dolor de cabeza. Es un tanto extraña dado que abundan los tonos azules pero sin embargo escasea el tono rojo.

- Colores en pantalla: 52 colores en una línea de escaneo (color de fondo + 4 conjuntos de 3 colores de cuadro + 4 conjuntos de 3 colores de sprite).
- Animaciones (sprites) apoyadas por hardware.
- Sprites en pantalla: 64 (sin recarga en mitad de pantalla).
- Tamaños de sprite: 8x8 u 8x16 pixeles.
- Memoria de video: PPU conectada a 32 KB de vídeo RAM. PPU contiene 2 KB de RAM interno atribuible/de cuadro; 256 bytes de RAM de posición de sprite; 28 bytes de RAM de paleta (que permite selección de color de fondo); 8 KB de ROM/RAM de patrones de cuadros en el cartucho.
- Resolución: 256x240 píxeles.

La forma de funcionar la PPU se merece un artículo más grande que próximamente se desarrollará. Pero debeís saber que podemos tener por cada fondo 4 paletas de colores con 1+3 colores distintos. Y en los sprites tambien: 4 paletas de colores con 1+3 colores distintos.
Esto significa que aunque tengamos nuestras cuatro paletas con cuatro colores, al menos un color debe de ser compartido entre todas ellas. En el caso de los background es el color que se usa como fondo plano, y en el caso de los sprites, es el color que se usa como transparente.

SONIDO: Generadores de tonos (dos cuadrados, un triángulo, un ruido, y generador PCM). Se llegaron ha hacer auténticas maravillas con estos canales. Para muestra, la OST del videojuego Super Spy Hunter (Battle Formula en Japón) de Sunsoft, compañía que dominó ampliamente este chip de sonido sin ningún apoyo externo de hardware.

Los dos generadores de tonos cuadrados y el triangular se encargaban de generar la sintonía del juego; tonos agudos y graves. Mientras que el canal de ruido se encargaba de hacer las percusiones. Además, gracias al PCM se podian reproducir samples que normalmente se usaban para introducir sonidos nuevos o incluso voces, aunque debido al tamaño tan grande que estos tenían, se limitaban muchas veces a sonidos simples de medio segundo.

Todos estos canales se usaban indistintamente para música como para sonido, por lo que muchas veces era un problema reproducir una banda sonora completa ya que en intervalos de tiempo, un cenal podía ser interrumpido por un sonido, cortandose la sintonía. Males menores con las que tuvimos que sobrevivir.

A partir de estos componentes básicos se desarrollarón casí un millar de videojuegos diferentes, y demostraron la evolución de una época y una máquina a la par.

Una vez sabido esto hay que comentar que cuando se desarrolla un juego básico en NES, los cartuchos constan de un chip llamado PRG de 16Kb o de hasta 32Kb, que es donde se introduce todo el código lógico de los juegos; el programa en si. Y otro chip llamado CHR de hasta 8Kb que es donde se almacenan los gráficos, divididos en dos bancos de memoria de 256 azulejos (tiles) cada uno, lo que nos da 512 azulejos distintos divididos en dos bancos de memoria: uno para usar en los backgrounds (fondos), y otro para usar en sprites.

Comúnmente a este tipo de juegos se les conoce como NROM por no tener ningún tipo de mapeador de memoria ampliable (mapper), chips que aparecieron más tarde.

Estas capacidades básicas son las que la NES puede paginar por si misma de golpe por el bus de datos, que son 32Kb de PRG ROM/RAM y 8Kb de CHR ROM/RAM.

Con esta base hubo una primera tirada de juegos muy básicos entre 1983 y 1985, donde podíamos encontrarnos con juegos tan simples como Donkey Kong o más complejos como Super Mario Bros. A estos se les cataloga dentro de la “Primera Epoca de la Famicom/NES”.

Es a partir de 1985 cuando la cosa empieza a cambiar y empiezan a aparecer los primeros mappers, que permitían paginar mucha más memoria, tanto en PRG como en CHR con lo cual se conseguían hacer juegos más grandes hasta llegar a los 712Kb en juegos oficiales (en piratas y no oficiales se llegó a más).

En general, una buena parte de los juegos de la NES usaron el mapper de Nintendo MMC1 o más tarde el MMC3. En otro artículo hablaré de ellos.

Con los nuevos mappers se incluían más bancos de memoria PRG o CHR, y un selector de banco tipo 74XX para poder seleccionar en todo momento el banco que se desease leer. Dado que la NES solo puede leer de golpe 32Kb de ROM y 8Kb para los gráficos, lo que se hacia era constantemente cambiar de bancos para leer datos y poder mostrar mas funciones o gráficos distintos. Con el paso de los años esto se fue perfeccionando, las compañías sacaron partido a los mappers y algunas crearon los suyos propios, mientras otras exprimieron las que proporcionaba la propia Nintendo donde pudimos llegar a ver genialidades como Kirby´s Adventures.

En el próximo artículo nos adentraremos de lleno en los cartuchos de NES.

Etiquetas: 
Suscribirse a RSS - hardware