Scroll en Videojuegos Clásicos: De Simples Pantallas a Mundos Interminables

Uno de los temas más polémicos entre los primeros ordenadores es el scroll o desplazamiento de pantalla. El cual era un enorme desafió para algunas máquinas y pan comido para otras. ¿Por qué? Pues seguid leyendo que os lo vamos a explicar al detalle y de forma que podáis entenderlo de forma general y para todos los sistemas.

El scroll en los primeros ordenadores

Hoy en día estamos acostumbrados a desplazar las páginas web o las aplicaciones de nuestro ratón con la rueda del mismo, si estamos en el móvil no es fácil hacerlo con el dedo e incluso los juegos en dos dimensiones tienen niveles que abarcan varias pantallas desde hace ya algo más de cuarenta años. Por lo que damos al scroll como algo ya por hecho, sin embargo, en los primeros sistemas algo que a día de hoy es tan simple era tan complejo y necesitaba tanta potencia si se hacía a través de la CPU sin hardware de ayuda podía suponer un reto.

Esto definió por completo el tipo de software que tuvieron los diferentes sistemas. Claro está que tenemos casos como el estándar MSX que en sus dos generaciones no usaba scroll, sino que generaba cada pantalla del escenario por separado, con un fundido a la hora de entrar en la nueva parte del escenario para darle tiempo a la CPU a reorganizar el tilemap o mapa de caracteres que formaba el fondo. Y todo venía por el hecho que muchos ordenadores no se diseñaron para videojuegos, sino para pequeños negocios y oficinas.

Pensad que en aquel momento, la complejidad de los chips no se medía por miles de millones de transistores como a día de hoy, sino en miles a finales de los 70 y decenas de miles a principios de los 80. Por lo que había características que por economía se dejaban de lado. Es más, el mercado empresarial tenía más capacidad económica que el de los juguetes, por lo que eran preferibles las 80 columnas al scroll.

¿Cómo funciona el scroll por hardware?

Antes de nada hemos de entender cómo funciona el truco del scroll por hardware, este consiste en tener un mapa de caracteres o tilemap más grande de lo que se ve en pantalla, de tal manera que si la resolución de pantalla es de 40 caracteres visibles y queremos hacer scroll horizontal hacía un sentido, solo necesitaremos una columna adicional, si lo queremos en los dos sentidos, entonces dos de ella, una a cada lado. Lo mismo se aplicaría para el scroll vertical, pero añadiendo filas de caracteres arriba o abajo.

El scroll por hardware fue implementado por primera vez en el Atari 800 a través del ANTIC y la solución fue tan efectiva y elegante que sistemas como el Commodore 64 y la Famicom/NES lo terminaron copiando tal cual con alguna variación. Por lo que no nos merecía volver a explicarlo para cada sistemas. Básicamente, tenemos dos registros que nos sirven para desplazar en horizontal o en vertical la cantidad de píxeles desde donde empezamos a dibujar la escena, provocando que el escenario se desplace. Es más, si tenemos suficiente memoria podemos almacenar varias pantallas en la zona de la memoria de vídeo, pero lo habitual era dibujar unas pocas columnas o filas adicionales para permitir el desplazamiento.

Por desgracia, el 6845 CRTC se lanzó al mercado como chip independiente antes de la solución de Atari y el TMS9918A tanto de lo mismo, por lo que no implementaron la capacidad de realizar scroll por hardware.

Varios planos al mismo tiempo

Las recreativas y consolas de 16 bits tenían la capacidad de realizar scroll parallax, esto son, varios tilemaps o fondos al mismo tiempo desplazándose a diferente velocidad. ¿Cómo lo conseguían? Pues duplicando y a veces triplicando el hardware que genera y gestiona los fondos y dándoles a cada uno un set de registros para controlar el scroll.

El coste del scroll por software

Hemos de partir del hecho que el verdadero scroll por hardware supone actualizar la pantalla en cada fotograma. Tenemos casos de muchos juegos del ZX Spectrum y del Amstrad CPC que realizan scroll por software, pero funcionando a una fracción de la tasa de frames máxima. Por ejemplo, juegos como la conversión del R-Type de Irem para el ordenador de Sinclair se movía entre los 12.5 y los 15 FPS.

En el Z80 tenemos la instrucción LDIR que permite copiar varios bytes de una zona de la memoria a la otra a un coste de 21 ciclos por byte. La ventaja es que no requiere la sincronización de memoria por cada nuevo byte al enviarse estos de forma secuencial, por lo que al final el tiempo medio termina siendo de 12.5 ciclos por byte. Teniendo en cuenta que la CPU de Zilog en los ordenadores de la época funcionaba a 3.579545 MHz y con una tasa de 50 o 60 FPS dependiendo de si hablamos de PAL o NTSC.

• 3579545 ciclos de reloj/60 cuadros por segundo = 59659 ciclos por frame.
• 59659 ciclos por frame/12.5 ciclos por byte copiado = 4772 bytes por frame.

Ni utilizando toda la potencia nos daría tiempo a generar un fotograma entero en el ZX Spectrum, si hablamos del PC o el Amstrad CPC con 80 bytes por línea y 200 líneas en total, eso son 16 KB, no, no hay suficiente velocidad para desplazar todo el frame.

No hace falta tanta fuerza bruta

Ahora bien, el problema real para realizar el scroll se encuentra en las instrucciones de desplazamiento de bits, las cuales tanto en el Z80 como en el 6502 y el 8086 se encuentran ausentes en el set de instrucciones. El hecho de desplazar varios bits por línea y añadir una columna más de caracteres supone no hacerlo píxel por píxel, sino bit por bit, y esto tiene un coste computacional enorme. En este caso no se usaría LDIR, sino las instrucciones RL (Rotate Left) y RR (Rotate Right) sobre el tilemap ya generado, las cuales tienen un coste de 8 ciclos de reloj.

Supongamos que tenemos un búfer de línea de 640 bits, el típico en el 6845 CRTC, esto significan 80 bytes. Por lo que sí queremos desplazar un solo bit por píxel, esto serán 640 ciclos de reloj por línea. Pero, ¿qué ocurre si nuestro juego usa 4 bits por píxel? Esto se convierten en 2560 ciclos de reloj por línea de escaneo. Y si hacemos el cálculo correspondiente, pues obtenemos que se requerirían 30.720.000 ciclos de reloj en la CPU, casi diez veces más que la frecuencia de dichos microprocesadores de la época.

Las unidades DMA no sirven para el scroll

Las unidades DMA se utilizan para acceder a la memoria quitándole el control del bus a la CPU. Hemos de tener en cuenta que los primeros ordenadores usaban topología de bus compartido. Por lo que cuando accedían a memoria colocaban en espera al microprocesador central. Sin embargo, a medida que fue pasando el tiempo, estas unidades DMA se volvieron más rápidas, permitiendo hacer accesos a memoria más rápido que la CPU, por lo que pasaron a ser ideales para realizar operaciones de copia en menos ciclos, pero sin la eficiencia del scroll por hardware.

–

No obstante, las unidades DMA solo van bien cuando estamos hablando de copiar memoria de una parte a otra, no de desplazar varios bits, ya que carecen de instrucciones de manipulación de datos que reducirían la velocidad de copia y desafiarían su propósito. Por lo que no se usarán para el scroll, pero sí para otras funciones como el poder cambiar ciertos valores más rápidamente o a tiempo.

La salsa secreta para el scroll: el Barrel Shifter

Hemos hablado que para el scroll hace falta desplazar los bits de una línea a izquierda y derecha. Pues bien, sin ser scroll eso es lo que se hacía en el Space Invaders de Taito, cuya recreativa llevaba integrado un Barrel Shifter.

La idea del Barrel Shifter es que a partir de n bits de entrada podemos reordenarlos en cualquier orden y con la ventaja de hacerlo en un solo ciclo de reloj al ser lógica combinatoria y no secuencial. Pues bien, el truco de los sistemas que soportaban scroll por hardware era tener uno para poder desplazar los bits del búfer de línea de forma rápida y eficiente.

Con esto hemos llegado al fin de nuestro artículo sobre el scroll por hardware y el motivo por el cual se encontraba tan limitado en los primeros sistemas.