Entradas etiquetadas con VDP
El VDP – Parte III
10 ago
Para hacernos una idea de la salida del VDP vamos a empezar hablando de los caracteres.
Como ya dije, los caracteres son la mínima unidad representable y ocupan 8×8 píxeles.
Cada caracter está representado por 32 bytes de la VRAM del VDP, luego teniendo 16 KBytes de RAM es trivial que podremos representar 512 caracteres en dicha memoria. Aunque, como veremos más adelante, hay zonas de esta memoria ocupadas por otras unidades de información, al VDP eso le da igual.
De los 32 bytes de cada caracter, cada 4 de ellos se usan para representar una fila de las 8 que lo componen. El color se obtiene de los 4 planos de bits formados por estos 4 bytes.
Por ejemplo, el primer caracter (ocupa las direcciones 0 a 31 de la VRAM) estaría formado por los bytes:
FF, 00, FF, 00, 00, 00, C0, C0, 00, 00, C0, C0, 00, 00, C0, C0, 00, 00, C0, C0, 00, 00, C0, C0, 00, 00, C0, C0, 00, 00, C0, C0, 00, FF, 00 y 00.
Desglosado en sus bits sería:
Byte b7 b6 b5 b4 b3 b2 b1 b0 0 1 1 1 1 1 1 1 1 c0 FIRST PIXEL ROW:1 0 0 0 0 0 0 0 0 c1 '0101' = color #52 1 1 1 1 1 1 1 1 c23 0 0 0 0 0 0 0 0 c3 4 0 0 0 0 0 0 0 0 c0 SECOND PIXEL ROW:5 0 0 0 0 0 0 0 0 c1 '1100' = color #12,6 1 1 0 0 0 0 0 0 c2 '0000' = color #0.7 1 1 0 0 0 0 0 0 c3 8 0 0 0 0 0 0 0 0 c0 THIRD PIXEL ROW9 0 0 0 0 0 0 0 0 c110 1 1 0 0 0 0 0 0 c211 1 1 0 0 0 0 0 0 c3 12 0 0 0 0 0 0 0 0 c0 FOURTH PIXEL ROW13 0 0 0 0 0 0 0 0 c114 1 1 0 0 0 0 0 0 c215 1 1 0 0 0 0 0 0 c3 16 0 0 0 0 0 0 0 0 c0 FIFTH PIXEL ROW17 0 0 0 0 0 0 0 0 c118 1 1 0 0 0 0 0 0 c219 1 1 0 0 0 0 0 0 c3 20 0 0 0 0 0 0 0 0 c0 SIXTH PIXEL ROW21 0 0 0 0 0 0 0 0 c122 1 1 0 0 0 0 0 0 c223 1 1 0 0 0 0 0 0 c3 24 0 0 0 0 0 0 0 0 c0 SEVENTH PIXEL ROW25 0 0 0 0 0 0 0 0 c126 1 1 0 0 0 0 0 0 c227 1 1 0 0 0 0 0 0 c3 28 0 0 0 0 0 0 0 0 c0 EIGHTH PIXEL ROW29 1 1 1 1 1 1 1 1 c1 '0010' = color #230 0 0 0 0 0 0 0 0 c231 0 0 0 0 0 0 0 0 c3
Como vemos, cada cuatro bytes forman una fila y el color asociado se obtiene leyendo de “abajo a arriba”, es decir, del byte 3 al 0, del 7 al 4, etc.
Se puede observar que en este ejemplo solo se usan 4 colores, en concreto los correspondientes al índice de la paleta número 0, 2, 5 y 12. Como ya veremos estos colores pueden ser cualquiera de los soportados siempre que estén en la posición indicada dentro de la paleta.
Suponiendo que los índices se correspondieran con los siguientes colores (podría ser cualquier color, esto es un supuesto):
- 0 -> Blanco.
- 2 -> Rojo.
- 5 -> Azul.
- 12 -> Verde.
Quedaría una imagen tal que así:
A partir de pequeñas imágenes como ésta es como está formada todo el área visible que representará el VDP, es decir, los sprites y tiles.
Espero que esto haya quedado claro, pues es la base de todo lo que viene después. Mañana hablaré de los tiles.
Jugando al Alex Kidd (entre otros)
24 jul
Hoy he terminado de implementar todo lo que me faltaba de los tiles, esto es, scroll vertical y horizontal, mirror horizontal y vertical y alguna cosilla más que no recuerdo.
Por otro lado, me he puesto con el sistema de mappers de memoria para poder cargar roms de más de 32 KBytes y tengo que reconocer que ha sido un éxito relativo.
Muchos juegos que he probado se quedan en un pantallazo negro y no arrancan (¿puede que sea por no tener el sonido implementado?), pero algunos otros parece que funcionan perfectamente.
Os dejo algunos pantallazos del emulador con algunos de estos juegos funcionando, a ver si los reconocéis.
Sprites completos y bugs arreglado
23 jul
Las cosas más tontas son las más difíciles de corregir…
Ya he encontrado el error que mostraba sprites formados por píxeles aleatorios (como los que se ven en las capturas de ayer). Después de volverme loco revisando las interrupciones, intentando hacerme una idea del código fuente del juego a corregir mediante ingeniería inversa, comparar logs de emulación con otro emulador, etc. el fallo estaba en una máscara mal aplicada para leer de la memoria del VDP. En lugar de aplicar un 0x3FFF para devolver una dirección de entre las 65536 aplicaba un 0x3F y claro, me devolvía una entre 64… Lo que no entiendo es que no hiciera cascar el juego por todos lados…
Bueno, aparte de eso me he puesto a implementar los “efectos especiales” relativos a sprites, esto es, zooms, desplazamientos y caracteres dobles.
Aquí os paso unas capturas de mi emulador mostrando la demo “Interactive Sprite Test”.
Añadido soporte de sprites y controles
22 jul
Llevo unos días liado con el tema de los sprites y parece que ya medio funcionan. En general funcionan bien en las demos que he probado, pero al aventurarme con algunos juegos comerciales se aprecian fallos gráficos.
Como digo, quería probar algún juego comercial (de momento solo los de 32 KBytes, pues es lo máximo que puede direccionar una Master System sin tener implementado el sistema de mappers), así que he aprovechado en un ratillo para implementarle los controles del jugador 1.
Los resultados de momento son satisfactorios, aunque algunos juegos no arrancan y en otros se ven fallos gráficos.
Algunos pantallazos:
Por otro lado, a petición de los lectores, os pongo un paquetito con tests para probar el Z80. Incluye el código fuente en ensamblador (.asm), el fichero binario para cargar en el emulador/simulador (.bin) y una salida mostrando la ejecución en mi emulador para comparar resultados (.log).
Finalmente, voy a reordenar los tags del blog de modo que los avances diarios vayan en la categoría de WIP (Work in Progress) y así sea más sencillo separar la información técnica de lo implementado cada día.
Ya se muestran tiles
20 jul
Después de darle muchas vueltas, al final el fallo gráfico que os mostré el otro día era una tontería. El error estaba en la inicialización de la biblioteca gráfica SDL, pues la copié y pegué de uno de mis juegos para la GP2X y se me olvidó cambiar la resolución de 320×240 a los 256×192 de la Master System…
Bueno, he ido corrigiendo problemas y aquí os pongo algunos pantallazos de mi emulador mostrando los tiles en varias demos:
Solo tengo implementada la parte más básica, así que no contemplo de momento efectos de mirroring (pintar el gráfico como si se reflejara en un espejo), zooms, desplazamientos ni interrupciones gráficas.
Como se puede observar, en el pantallazo de la foto de la chica habría que aplicar un desplazamiento vertical para que saliera centrada y en la prueba de los 64 colores simultáneos hace falta aplicar interrupciones gráficas para cambiar la paleta a mitad de fotograma (sin “trucos” como ese (los conocidos como raster effects) la Master System solo es capaz de mostrar 32 colores simultáneos.
El VDP – Parte II
20 jul
Continúo explicando brevemente el funcionamiento del VDP.
Caracteres, tiles y sprites
Puede parecer al principio algo lioso, pero hay que distinguir entre tres elementos esenciales: caracteres, tiles y sprites.
Los caracteres son pequeños gráficos de 8×8 píxeles que se usarán como base para componer cualquier elemento que aparezca en pantalla (tiles y sprites). Es decir, los caracteres son la mínima unidad dibujable, no es posible dibujar un píxel solitario (habría que dibujar un caracter con 1 píxel de un color y los otros 63 de color transparente).
Los tiles, como su nombre indica, son baldosas con las que se forma el fondo de la imagen. Su particularidad es que siempre tienen una posición fija, en cada tile se dibujará un caracter y por tanto habrá 32×24 tiles visibles.
Los sprites por su parte son gráficos (también se corresponden 1:1 con un caracter) que tienen la particularidad de poder situarse en cualquier posición de la pantalla.
En la práctica, los tiles se usarán para dibujar los escenarios del juego y los sprites para dibujar los personajes, enemigos, etc. Cada tile o sprite está formado por un solo carácter.
Las paletas
El VDP de la Master System trabaja en un modo de video paletizado. Esta técnica pretende ahorrar memoria usando una serie de paletas.
En el caso concreto de la Master System el color de cada píxel viene representado por un número de 4 bits que actúa como un índice sobre la paleta. Esta paleta a su vez está formada por 32 entradas de 1 byte, cada una representando a un color de 6 bits en RGB (2 bits para cada color, de la forma xxBBGGRR).
Con este sistema paletizado podemos hacer uso de 64 colores diferentes en pantalla con solo 4 bits de información en los gráficos.
Si alguien está echando cuentas, efectivamente, con 4 bits solo puedes direccionar 16 elementos, pero la paleta tiene 32 entradas. Efectivamente, hay que establecer una división entre los 16 primeros y segundos colores. Los sprites solo pueden acceder a estos últimos mientras que los tiles pueden acceder a cualquiera de los dos bancos por medio de un bit adicional que llevan en su descripción.
Primera salida de video
19 jul
Hoy he estado trabajando en el plano de fondo del VDP (todavía no me he metido con los sprites) y, tras varios intentos infructuosos, ya tengo mis primeros resultados.
La imagen de la izquierda se corresponde con mi emulador y la de la derecha con lo que debería mostrarse:
La paleta es normal que sea muy extraña, pues no me he metido con ella y la he llena con colores aleatorios.
Como se puede apreciar, algo estoy haciendo mal, pues aunque horizontalmente parece una salida correcta, en el aspecto vertical salen las líneas comprimidas o bien se pierden algunas.
Bueno, toca seguir trabajando en ello, pero me hacía ilusión ir mostrando estos primeros resultados.
El VDP – Parte I
18 jul
Llevo unos días sin escribir entradas, el motivo ha sido que no he tenido mucho tiempo para dedicar al emulador y el poco que tenía lo he pasado corrigiendo los testes del ZEXALL que no funcionaban (ya está todo correcto, al final era lo más tonto, la llamada a la macro SCF se me coló como CCF que es otra macro y claro, ejecutaba la que no era y por eso el checksum no salía correcto…)
Bueno, ya me he puesto a implementar el VDP (Video Display Processor), el procesador gráfico de la Master System, así que voy a hablaros un poco de él.
Este procesador está basado en un TMS9918A de Texas Instruments pero con algunos aspectos mejorados.
La resolución “oficial” del modo de video 4 (este procesador tiene 16 modos de video, pero solo el 4 es el documentado por SEGA) es de 256×192 píxeles.
Cuenta con dos memorias RAM internas al propio chip.
La primera es la llamada CRAM (Color RAM) que se encarga de almacenar las paletas de colores que se pueden usar en pantalla (hablaré de los modos gráficos paletizados, para quien no sepa qué son, en próximas entradas) y tiene un tamaño de 32 bytes (64 en la Game Gear) lo que nos da 32 colores RGB distintos de 6 bits cada uno (2 bits para almacenar cada tono: rojo, verde y azul) de un total de 64.
La segunda memoria es la VRAM (Video RAM) y tiene un tamaño de 16 KBytes. Esta memoria se divide en tres zonas:
- Screen Map (1792 bytes): es una zona dedicada a almacenar un mapa con la información de los tiles que forman el fondo (32×24 tiles de 8×8 píxeles).
- Attribute Table (256 bytes): una zona dedicada a almacenar una tabla con los atributos de un máximo de 64 sprites simultáneos.
- Character Generator (14336 bytes): es la zona de memoria donde se almacenan los patterns (no me sale una traducción apropiada), es decir, pequeños gráficos de 8×8 píxeles de los que están formados los tiles y sprites.
Por otro lado, el VDP cuenta con 11 registros internos de 8 bits que sirven para determinar su comportamiento.
Cabe mencionar que el Z80 “ve” al VDP a través de dos puertos de Entrada/Salida, concretamente los 0xBF (comandos) y 0xBE (datos).
Bueno, de momento lo dejo por hoy, a ver si me da tiempo a hacer algunas pruebas antes de cenar. Mañana os seguiré hablando del VDP.
