Be, comencem un projecte interessant! La idea es passar el JailDoctor's Dilemma a Spectrum i MSX. En el dubtós cas que acabara este projecte (cosa mai vista), podria plantejar-me dur-lo també a CPC o (qui sap!) C64.
Però no divaguem més! La realitat es que va a ser prou mes fàcil passar-lo a MSX que a Spectrum (i amb aquestos dos primers posts espere que es veja un poc més clar), per tant, començarem amb la versió de MSX.
No obstant, m’agradaria primer fer un repàs del que ens ofereix el Spectrum. En tot moment estic parlant del ZX Spectrum 48K. Els de 128K, a part de òbviament molta més memòria, no m’aporten massa avantatges (exceptuant, també, el xip d’àudio!), així que per ara em centraré en el 48K.
Comencem amb la CPU: El Zilog Z80 “de tota la vida”. Però espera, si ara passem a la memòria, perquè no te els 64K que el Z80 pot adreçar? Doncs resulta que els primers 16K es on trobem la ROM.
Els 48K restants son RAM, i podem usar-los. Però part d’eixa RAM ja te una funció, i algunes d’aquestes funcions son intocables. Per a ser exactes, la memòria on està guardada la informació de la pantalla.
El Spectrum no te modes de pantalla, com la majoria dels seus contemporanis. Així que simplement te una zona on podem escriure 256x192 píxels, des de l’adreça 0x4000 (16384, o siga, quan acaben els 16K de la ROM) fins a 0x57FF (22527). Això ens dona 6144 bytes. Com cada píxel es nomes 1 bit, cada fila de la pantalla cap en 256x8bits, o siga, 32 bytes. Com hi ha 192 files, 32x192=6144.
Però el gran problema que sempre li he trobat a la memòria de pantalla del Spectrum es la forma en que està guardada. Per desgracia no es lineal, primer tots els píxels de la primera fila, després la segona fila, etc... No, la distribució es prou mes complexa: primer va la primera fila, sí, però després va la octava fila, després la fila 16, ... fins al final, aleshores continua amb la fila 2, després la 9, la 17...
Sí, es un poc rallant, però be... La qüestió es que, si guardem cada píxel nomes amb un bit, no hi ha possibilitat de color. Simplement o està el píxel o no està. Per a donar color tenim la zona de memòria contigua, des de 0x5800 a 0x5AFF, 768 bytes. Cada byte dona color a un bloc de 8x8 píxels (si dividim la pantalla en blocs de 8x8, tenim 32x24 blocs = 768). Y cada byte conté la següent informació:
Els 3 bits de menor pes contenen el color de primer pla (o siga, el color dels píxels que estan a 1), els següents 3 bits contenen el color de fondo (els píxels a 0). El bit 6 ens diu si usem els colors brillants o els obscurs. I l’últim bit si ha de estar fent flash (que gilipollada, no?).
Si recordem la paleta del Spectrum, els 7 primers colors son obscurs i els altres 7 clars. Com nomes tenim que triar entre 7 colors, amb 3 bits tenim prou. Però esta es la raó per la que no es poden usar els colors brillants i obscurs a l’hora en un mateix bloc de 8x8.
I açò de tindre que ficar la mateixa combinació de colors a cada bloc de 8x8 es el que du al famós “color clash”.
La qüestió es que podem arribar a usar pràcticament tota la resta de RAM, a partir de 0x5B00. Al final son uns 41K que tenim disponibles. En eixe espai ha de cabre el joc sencer: codi, imatges, musica, textos... tot.
Ah, per finalitzar, el ZX Spectrum 48K no te xipset de só. Nomes podem activar o desactivar el bit 4 del port 0xFE per a que el altaveuet pite. Així i tot intentarem traure-li profit.
En el pròxim post parlaré del MSX per a que també tingau un mínim coneixement de les màquines en les que treballarem. I seguidament ens ficarem a transformar les dades del JDD a formats mes reduïts i millor donats a les reduïdes màquines en les que anem a treballar.
