{"id":2703,"date":"2021-01-01T22:32:03","date_gmt":"2021-01-01T22:32:03","guid":{"rendered":"http:\/\/blog.rastersoft.com\/?p=2703"},"modified":"2023-12-25T19:48:34","modified_gmt":"2023-12-25T19:48:34","slug":"pintando-en-el-spectrum","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=2703","title":{"rendered":"Pintando en el Spectrum (1)"},"content":{"rendered":"\n

Cuando ten\u00eda 12 a\u00f1os hered\u00e9 el Sinclair ZX Spectrum<\/a> de mi hermano. Era un ordenador que me fascinaba, y con \u00e9l aprend\u00ed a programar, primero en BASIC, y luego directamente en Ensamblador. Tambi\u00e9n aprend\u00ed rudimentos de electr\u00f3nica digital, y gracias a ello constru\u00ed varios circuitos que le acopl\u00e9, como un teclado nuevo, un puerto de E\/S de 16 bits, y m\u00e1s.<\/p>\n\n\n\n

Es una m\u00e1quina a la que siempre le tuve mucho cari\u00f1o, y por eso me lanc\u00e9 hace unos a\u00f1os a escribir mi propio emulador, FBZX<\/a>, cuando los que hab\u00eda en aquel entonces no me acababan de convencer. Y recientemente, a ra\u00edz de varios canales de youtube de \u00abnostalgia de 8 bits\u00bb, me he puesto un poquito as\u00ed y he decidido intentar programar algo. Al principio prob\u00e9 a usar el compilador de Z88dk<\/a> para poder utilizar lenguaje C, hasta que vi la chapuza de c\u00f3digo que genera (algo que no es culpa de los desarrolladores, sino de la propia arquitectura del Z80, que no es nada adecuada para C y, sencillamente, es imposible generar mejor c\u00f3digo). Ante esto, decid\u00ed pasarme a Z80ASM<\/a> y trabajar desde cero en ensamblador. A fin de cuentas, en una m\u00e1quina de 8 bits cada bit cuenta, y el poder optimizar cada rutina hasta la \u00faltima instrucci\u00f3n puede ser la diferencia entre conseguir o no conseguir algo concreto.<\/p>\n\n\n\n

Y precisamente una de las cosas en donde la velocidad es cr\u00edtica es a la hora de pintar en la pantalla, pues, por desgracia, el Spectrum original no tiene ninguna ayuda para esa tarea, si siquiera una doble p\u00e1gina (a pesar de que s\u00f3lo habr\u00eda requerido a\u00f1adir un \u00fanico flip-flop a la ULA). El Spectrum 128K s\u00ed tiene dos p\u00e1ginas de v\u00eddeo, lo que permite que la ULA muestre una de ellas mientras el c\u00f3digo genera el siguiente fotograma en la otra p\u00e1gina, y cuando haya terminado, s\u00f3lo tiene que esperar a que la ULA empiece a pintar un nuevo cuadro para cambiar la p\u00e1gina activa, de manera que ahora se mostrar\u00e1 lo que haya en la segunda p\u00e1gina y el programa podr\u00e1 pintar el siguiente fotograma en la primera p\u00e1gina.<\/p>\n\n\n\n

Cuando se usa el sistema de doble p\u00e1gina, las animaciones van fluidas y sin parpadeos ni deformaciones. Por desgracia, los modelos de 48K, al no tener esta capacidad, obligan al programador a sincronizarse con el haz de electrones de la pantalla para evitar que \u00able pille el rayo\u00bb en mitad de un acceso a la pantalla. Hay mucha literatura al respecto, as\u00ed que no voy a entrar en explicar en qu\u00e9 consiste lo de \u00abcompetir con el haz<\/a>\u00ab. S\u00ed voy a dar, sin embargo, algunas notas sobre c\u00f3mo funciona la pantalla en el Spectrum. Para ello, veamos este dibujo de una televisi\u00f3n con la imagen generada por la circuiter\u00eda del ordenador (la famosa ULA):<\/p>\n\n\n\n

\"\"<\/a>
Una televisi\u00f3n con la imagen generada por un Spectrum.<\/figcaption><\/figure>\n\n\n\n

En el dibujo vemos una televisi\u00f3n, y en la pantalla podemos ver las dos zonas en las que se divide la imagen generada por la ULA en el Spectrum: el border<\/em> (en color verde en el dibujo) y el paper<\/em>, o la zona de trabajo, en color blanco. Tambi\u00e9n vemos esquematizado el recorrido del haz de electrones, de derecha a izquierda y de arriba a abajo, aunque exagerado. El border<\/em> es una zona en la que s\u00f3lo podemos definir qu\u00e9 color global queremos, pero no podemos pintar en ella. S\u00f3lo en el paper<\/em> podemos pintar p\u00edxeles escribiendo en una zona de memoria, a partir de 0x4000 hasta 0x5800, en donde cada bit se corresponde con un pixel. Esta zona se divide en 256×192 pixels. A mayores, justo a continuaci\u00f3n se encuentra la zona que almacena los atributos<\/em> de color, que mide 768 bytes. Esta zona ocupa un byte para cada grupo de 8×8 p\u00edxels, y especifica qu\u00e9 color se usar\u00e1 para cuando el bit asociado a cada pixel est\u00e1 a 0 o a 1.Para m\u00e1s detalles, recomiendo leer la informaci\u00f3n de World of Spectrum<\/a> sobre la memoria de v\u00eddeo. Edito: o bien la entrada n\u00famero 4<\/a> de esta misma serie, donde entro en m\u00e1s profundidad en c\u00f3mo es la distribuci\u00f3n de la pantalla en el Spectrum. Siento no haber hecho las cosas en orden.<\/em><\/p>\n\n\n\n

La ULA refresca la pantalla a una tasa de 50 veces por segundo. Adem\u00e1s, para simplificar la circuiter\u00eda, no utiliza entrelazado, sino que siempre pinta \u00fanicamente las l\u00edneas impares. Y dado que el reloj de la CPU va a 3,5 MHz, eso significa que desde que comienza a pintar la imagen, en la esquina superior izquierda del borde, hasta que ha terminado y empieza a pintar la siguiente, tenemos, en teor\u00eda, 3 500 000 \/ 50 = 70 000 ciclos de reloj o Tstados. Y como tenemos 312,5 l\u00edneas (recordemos que s\u00f3lo utilizamos medio campo, por lo que es la mitad de 625), cada l\u00ednea dura 224 Tstados. En la pr\u00e1ctica no podemos tener media l\u00ednea, por lo que, en realidad, cada frame dura 69 888 Tstados y tenemos un total de 312 l\u00edneas. Adem\u00e1s, sabemos que cada vez que se empieza a pintar un frame<\/em>, la ULA genera una interrupci\u00f3n, la cual podemos utilizar para sincronizarnos con la generaci\u00f3n de la imagen. Por \u00faltimo, hay 64 l\u00edneas de border<\/em> antes de que empiece a pintarse el paper<\/em>.<\/p>\n\n\n\n

Con todo esto ya podemos hacer un primer c\u00e1lculo, que nos dice que si queremos estar seguros de que hemos pintado todo en pantalla antes de que el haz llegue al paper<\/em>, tenemos que hacerlo en menos de 64 * 224 = 14 336 Tstados. Por desgracia esto es muy poco tiempo.<\/p>\n\n\n\n

Una soluci\u00f3n consiste en esperar a que la ULA haya terminado de pintar el paper<\/em> y, entonces, pintar lo que necesitemos. En este caso tendremos 69 888 – (224 * 192) = 26 880 Tstados, que es el tiempo que tarda en pintar la parte inferior y la superior del borde. Ya es un poco m\u00e1s, pero todav\u00eda no llega para demasiado.<\/p>\n\n\n\n

La soluci\u00f3n que usan muchos juegos consiste en implementar una doble p\u00e1gina por software<\/em>. Para ello, pintan toda la imagen en una zona diferente de memoria, y cuando est\u00e1 lista, la copian de golpe en la memoria de pantalla. De esta manera la imagen que aparece siempre es definitiva y no hay parpadeos. El inconveniente es que consume casi siete Kbytes extra.<\/p>\n\n\n\n

El problema es que, como de costumbre, la cosa no es tan sencilla. Veamos por qu\u00e9. La primera idea, la m\u00e1s naive<\/em>, ser\u00eda utilizar la instrucci\u00f3n LDIR del Z80. Esta instrucci\u00f3n permite copiar un bloque de memoria a otra posici\u00f3n, y recibe tres par\u00e1metros: la direcci\u00f3n inicial del bloque (en el registro HL<\/em>), la direcci\u00f3n de destino (en el registro DE<\/em>), y el tama\u00f1o del bloque (en el registro BC<\/em>), y hace todo el trabajo por nosotros: lee el byte contenido en la direcci\u00f3n de memoria apuntada por HL, lo escribe en la direcci\u00f3n de memoria apuntada por DE, incrementa en uno ambos registros, decrementa en uno el registro BC, y repite la operaci\u00f3n hasta que este \u00faltimo valga cero. \u00a1Una bicoca<\/a>! As\u00ed que lo \u00fanico que tendr\u00edamos que hacer es esperar a la interrupci\u00f3n, cargar los valores en los registros, y ejecutar LDIR. \u00bfO no?<\/p>\n\n\n\n

El problema es que cada iteraci\u00f3n de LDIR consume 21 Tstados. Eso significa que una pantalla completa, que ocupa 6 912 bytes, tardar\u00e1 145 152 Tstados en copiarse… \u00a1que es m\u00e1s del doble de lo que se tarda en generarse! Eso significa que el haz nos alcanzar\u00e1 como m\u00ednimo dos veces en cada volcado. Y s\u00ed, digo \u00abcomo m\u00ednimo\u00bb, porque por cuestiones de dise\u00f1o, la pantalla no se almacena de manera secuencial en memoria, sino que primero viene la fila 0 de pixels, ocupando 32 bytes, luego la fila 8, luego la 16, 24, 32, 40, 48 y la 56, momento en que vuelve atr\u00e1s hasta la fila 1, luego la 9, la 17… Eso hace que podamos cruzar el haz varias veces, y complica a\u00fan m\u00e1s la gesti\u00f3n de la pantalla.<\/p>\n\n\n\n

Por si fuera poco, hay un segundo problema, y es que la ULA interfiere en el acceso a la RAM cuando est\u00e1 generando la imagen. Esto es debido a que en chips de RAM normales no es posible que dos sistemas lean o escriban a la vez, sino que se tienen que turnar. La ULA necesita leer dos bytes (uno con los pixels, y otro con los atributos de color) cada cuatro Tstados mientras est\u00e1 pintando el paper<\/em>, y s\u00f3lo deja la memoria libre cuando est\u00e1 pintando el borde. Para conseguir esto, lo que hace es monitorizar constantemente a la CPU, y si intenta acceder a la zona de v\u00eddeo mientras la ULA est\u00e1 pintando el paper<\/em>, le detiene el reloj a la CPU hasta que termine.<\/p>\n\n\n\n

Por suerte, gracias a un ingenioso dise\u00f1o, la ULA s\u00f3lo necesita tres Tstados para leer esos dos bytes, as\u00ed que lo que hace es agrupar dos lecturas seguidas y dejar los dos Tstados restantes para la CPU. Esto significa que, si queremos que la escritura en la zona de v\u00eddeo no se vea penalizada por la ULA, tenemos que hacer accesos con un periodo que sea m\u00faltiplo de ocho Tstados<\/strong>. De esta manera, el primer acceso se ver\u00e1 retrasado entre uno y seis Tstados seg\u00fan donde caiga, pero el resto coincidir\u00e1n exactamente en el siguiente hueco. Y este es otro de los problemas de LDIR: como cada ciclo dura 21 Tstados, que no es m\u00faltiplo de ocho, significa que, en la pr\u00e1ctica, ser\u00e1 como si la instrucci\u00f3n durase 24 Tstados (la primera har\u00e1 la escritura en el primer hueco libre; la segunda lo har\u00e1 en el segundo hueco, tres periodos despu\u00e9s, con lo que ambas durar\u00e1n 21 Tstados; la tercera, en cambio, se retrasar\u00e1 seis Tstados, la cuarta no sufrir\u00e1 retraso, la quinta se retrasar\u00e1 seis Tstados… y as\u00ed sucesivamente).<\/p>\n\n\n\n

Sin embargo, si vemos el juego de instrucciones, comprobaremos que existe tambi\u00e9n una instrucci\u00f3n similar, LDI, que hace lo mismo excepto repetir la operaci\u00f3n, y s\u00f3lo consume 16 Tstados, que, adem\u00e1s, es m\u00faltiplo de 8 y, por tanto, no sufrir\u00eda penalizaci\u00f3n por parte de la ULA. \u00bfQu\u00e9 pasar\u00eda si pusi\u00e9semos una laaaaaarga ristra de ellas, una detr\u00e1s de otra? Pues que necesitar\u00edamos 6 912 * 16 = 110 592 Tstados. A\u00fan es m\u00e1s que el tiempo que se necesita para refrescar una pantalla, pero a\u00fan nos queda un as en la manga. \u00bfQu\u00e9 ocurrir\u00eda si esperamos a que el haz llegue hasta el principio del paper<\/em>, y justo entonces empezamos a pintar? En ese caso, el haz ir\u00eda por delante nuestra, y nunca lo adelantar\u00edamos porque ya hemos visto que somos m\u00e1s lentos que \u00e9l, y eso significa que cuando el haz haya pintado toda la pantalla y vuelto al punto de partida, ya llevaremos m\u00e1s de la mitad de la imagen pintada y, adem\u00e1s, tendremos a\u00fan casi otro frame<\/em> de tiempo antes de que nos alcance.<\/p>\n\n\n\n

Veamos exactamente de cuanto tiempo disponemos. Tenemos los 69 888 Tstados que tarda en recorrer un frame<\/em>, y ahora tenemos que sumarle el tiempo que tarda en llegar hasta el borde inferior derecho del paper<\/em>. Esto ser\u00e1 224 Tstados_por_linea * 191 lineas_completas + 128 Tstados_de_la_ultima_linea = 42 912 Tstados. Esto significa que si utilizamos este truco, tendremos disponibles un total de 112 800 Tstados para copiar la pantalla antes de que nos alcance el haz, que es m\u00e1s de lo que tarda la ristra de LDIs. \u00a1Buena cosa!<\/p>\n\n\n\n

Por desgracia, esta idea tiene dos problemas:<\/p>\n\n\n\n