El c\u00f3digo anterior es funcional, pero tiene el problema de que ocupa 541 bytes (c\u00f3digo m\u00e1s la tabla de direcciones). Teniendo en cuenta que la memoria de v\u00eddeo son casi siete kbytes, y otros siete m\u00e1s para el segundo buffer, tenemos que esos 541 bytes pueden ser un gasto excesivo de los 34,5 kbytes restantes de un Spectrum 48K (en un 128K tenemos doble p\u00e1gina por hardware, con lo que no necesitamos nada de esto).<\/p>\n\n\n\n
Para solucionarlo, en lugar de utilizar una tabla con todas las direcciones de memoria podemos utilizar una tabla s\u00f3lo con las direcciones de inicio de cada bloque de caracteres (o sea, una de cada ocho filas de p\u00edxels). Esto es posible porque pasar de una fila a la siguiente en un bloque de caracteres es relativamente sencillo: s\u00f3lo hay que incrementar el byte alto. As\u00ed, si tenemos en DE la direcci\u00f3n de un byte en una fila, s\u00f3lo necesitamos hacer INC D para pasar a la siguiente fila (siempre que no sea la \u00faltima fila de un car\u00e1cter, claro).<\/p>\n\n\n\n
As\u00ed que combinando todo lo anterior, podemos usar esta funci\u00f3n:<\/p>\n\n\n\n
LD SP, tabla_direcciones\n LD HL, buffer\n LD BC, 0\n EXX\n LD HL, buffer + 6144\n LD DE, 0x5800 ; zona de atributos de color\n LD BC, 768 ; 32 columnas * 24 lineas\nloop_l1:\n EXX\n INC B ; como BC es cero, esto es igual que LD BC, 256\n ; esto son 32 x 8 bytes en una fila de caracteres\n POP DE ; obtenemos la direcci\u00f3n inicial de la fila de caracteres\n LD IXh, E ; usamos una instrucci\u00f3n no oficial porque\n ; estamos justos de registros\n LD A, D\nloop_l2:\n INC A ; preparamos ya la direcci\u00f3n de la siguiente fila\n ; hay que hacerlo antes de LDI porque INC modifica\n ; los flags\n LDI\n ... ; 32 LDIs en total\n LDI\n LD E, IXh ; recuperamos la posici\u00f3n inicial\n LD D, A ; y la siguiente fila\n JP PE, loop_l2\n EXX\n LDI\n ... ; 32 LDIs en total\n LDI\n JP PE, loop_l1\n\n...\ntabla_direcciones:\n DEFW 0x4000, 0x4020, 0x4040, 0x4060, 0x4080, 0x40A0, 0x40C0, 0x40E0\n DEFW 0x4800, 0x4820, 0x4840, 0x4860, 0x4880, 0x48A0, 0x48C0, 0x48E0\n DEFW 0x5000, 0x5020, 0x5040, 0x5060, 0x5080, 0x50A0, 0x50C0, 0x50E0<\/pre>\n\n\n\nY con esto lo tenemos ya, y altamente optimizada, pues en realidad esto ha sido el final de muchas iteraciones. Empec\u00e9 utilizando DJNZ<\/strong> para las ocho iteraciones del bucle interno (loop_l2<\/em>), y para conservar la direcci\u00f3n inicial de la fila de caracteres, lo que hac\u00eda era meter DE<\/strong> de nuevo en la pila con un PUSH<\/strong>, para sacarlo despu\u00e9s de los LDI<\/strong>s y poder incrementar D<\/strong> para pasar a la siguiente fila. Esto era mucho m\u00e1s r\u00e1pido que almacenarlo en alguna zona de la memoria (20 Tstados) o que decrementar dos veces el puntero de pila para que volviese a apuntar al valor inicial (12 Tstados).<\/p>\n\n\n\n
La siguiente optimizaci\u00f3n que hice fue almacenar el valor de E<\/strong> en el registro A<\/strong>, de manera que despu\u00e9s de los LDI<\/strong>s s\u00f3lo ten\u00eda que hacer un LD E, A<\/strong> y ya tendr\u00eda el valor original. Por desgracia esto CASI funcionaba, pues en las filas de caracteres 7<\/em>, 15<\/em> y 23<\/em>, al llegar al final de la l\u00ednea se produc\u00eda un desbordamiento y se sumaba uno a D<\/strong>, con lo que fallaba. Una soluci\u00f3n ser\u00eda reducir el n\u00famero de columnas de 32 a 31, pero no era una soluci\u00f3n muy elegante, as\u00ed que al final decid\u00ed que era mejor almacenar D<\/strong> en A<\/strong>, y guardar E<\/strong> en una posici\u00f3n de memoria. Pero como no existe LD (nn), E<\/strong> ni la inversa, no pod\u00eda hacerlo directamente… a menos que usase c\u00f3digo automodificable. \u00bfQu\u00e9 es esto? La instrucci\u00f3n LD E, 0<\/strong> se codifica como 0x1E 0x00<\/em>, siendo el segundo byte el valor a meter en el registro E<\/strong>. As\u00ed que lo que hac\u00eda era poner un LD E, 0<\/strong> justo despu\u00e9s de todos los LDI<\/strong>s, y despu\u00e9s del primer POP DE<\/strong> almacenaba el valor de E<\/strong> justo en el segundo byte de la instrucci\u00f3n LD E, 0<\/strong>. De esta manera, cada vez que se hace una pasada en el bucle, el c\u00f3digo ha cambiado. Aunque es m\u00e1s r\u00e1pido, pues mientras que el par PUSH-POP son 22 Tstados en cada fila, con esto eran s\u00f3lo 11 Tstados dentro de loop_l2<\/em>, no me gusta nada usar c\u00f3digo automodificable, as\u00ed que me devan\u00e9 los sesos hasta que me acord\u00e9 de que ten\u00eda cuatro registros extra de 8 bits: las mitades de IX<\/em> e IY<\/em>. Es cierto que son funcionalidades no documentadas, pero funcionan en todos los Z80. As\u00ed que la soluci\u00f3n fue almacenar E<\/strong> en IXh<\/strong> (que consume 8 Tstados), y guardar D<\/strong> en A<\/strong>. Y adem\u00e1s, el resultado es ligeramente m\u00e1s r\u00e1pido tambi\u00e9n: aunque dentro del bucle pierdo ocho Tstados, pues LD E, 0<\/strong> es 1 Tstado menos que LD E, IXh<\/strong> y el bucle se repite ocho veces, los compenso fuera, pues LD A, E<\/strong> son 4 Tstados y LD (nn), A<\/strong> son 13, 17 Tstados en total, mientras que LD IXh, E<\/strong> son s\u00f3lo 8, con lo que, al final, usando IXh<\/em> en lugar de c\u00f3digo automodificable ahorro 1 Tstado por cada fila de caracteres (8 filas de p\u00edxels). Adem\u00e1s, no hay que olvidar tampoco que esos 7 Tstados se convertir\u00edan en m\u00e1s siempre que hubiese contienda en la memoria, con lo que es un win-win<\/em>.<\/p>\n\n\n\n
Y con esto tenemos una funci\u00f3n que ocupa 195 bytes en total (171 bytes m\u00e1s 24 de la tabla), a costa de ser un poco m\u00e1s lenta. \u00bfCuanto m\u00e1s? El bucle interno son 4 + 512 + 8 + 4 + 10 = 538 Tstados, y hay que repetirlo 8 veces. Pero en caso de contienda, ser\u00e1n 544 Tstados, luego la duraci\u00f3n ser\u00e1 entre 4 304 y 4 352 Tstados. El bucle externo son 4 + 4 + 11 + 8 + 4 + 4 + 512 + 10 = 557 Tstados, pero con contienda ser\u00e1n 560 Tstados, y esto repetido 24 veces, una por cada fila de caracteres. Con esto tenemos que copiar una pantalla completa ser\u00e1n entre 116 664 y 117 888 Tstados. Aplicando la f\u00f3rmula de la entrada anterior podemos aproximar a 117 597 Tstados, lo que es superior a los 112 800 Tstados de una pantalla completa. Si s\u00f3lo hacemos 23 filas necesitamos 112 696 Tstados para copiar la pantalla frente a 111 008 Tstados disponibles antes de que nos alcance el haz. Pero si hacemos 22 filas, tardaremos 107 797 Tstados, frente a 109 216 Tstados que tarda el haz en alcanzar ese punto, por lo que con esta rutina, aunque ahorramos casi dos tercios de memoria, perdemos una fila respecto a la rutina anterior.<\/p>\n\n\n\n
Sin embargo, no debemos olvidar que esto s\u00f3lo significa que no podemos tener animaciones fluidas en las dos \u00faltimas filas de la pantalla, pero s\u00ed podemos tener gr\u00e1ficos est\u00e1ticos o semi-est\u00e1ticos como un marcador, un inventario… cosas que no cambien demasiado a menudo de manera que un artifact<\/em> durante su modificaci\u00f3n pase desapercibido.<\/p>\n","protected":false},"excerpt":{"rendered":"
El c\u00f3digo anterior es funcional, pero tiene el problema de que ocupa 541 bytes (c\u00f3digo m\u00e1s la tabla de direcciones). Teniendo en cuenta que la memoria de v\u00eddeo son casi siete kbytes, y otros siete m\u00e1s para el segundo buffer, tenemos que esos 541 bytes pueden ser un gasto excesivo de los 34,5 kbytes restantes … Seguir leyendo Pintando en el Spectrum (3)<\/span>