Viernes, 5 de enero de 2018

¡Feliz año nuevo a todos!

Pues lo prometido es deuda y, como regalito de reyes adelantado, aquí tenemos la continuación del artículo sobre las evoluciones del 9918. Tomaos vuestro tiempo ya que es otro tocho (no infumable, espero).

En la primera parte vimos que el TMS9918A (y sus variantes TMS9928A y TMS9929A) no es exclusivo de los MSX1, ya que lo podemos encontrar en otros sistemas como ColecoVision o la Sega SG-1000. A partir de ahí, el chip evolucionó y lo hizo de dos formas diferentes: Vimos que estos chips son totalmente compatibles con el 9918, ya que incluyen sus modos. Gracias a esto, los MSX2 son capaces de ejecutar el software diseñado para MSX1 y la Master System el software diseñado para la SG-1000. Como veis, el concepto de "retrocompatibilidad" no es algo nuevo.

Vimos que el chip de la Master System añade un nuevo modo de patrones, con unas características superiores a los modos de patrones del V9938 (y del V9958), aunque éstos le superan en memoria de vídeo, paleta de colores y en los modos bitmap. Concluyendo que son chips pensados para propósitos diferentes: mientras que el chip de la Master System fue diseñado potenciando el modo de patrones para la programación de juegos, el V9938 se pensó para una máquina de propósito general, añadiendo modos bitmap.

Segunda evolución: V9958

Y llegamos al V9958, evolución del V9938 que podemos encontrarnos en los MSX2+ y Turbo-R. En este punto me encuentro con un dilema: ¿con qué VDP de la línea evolutiva de Sega lo comparo?

Por un lado, compararlo con el VDP de la Master System va a ser muy similar a la comparación vista en el anterior artículo, ya que los modos de patrones del 9958 son idénticos a los del 9938. Por lo tanto, todo lo dicho allí vale exactamente para este chip, con la salvedad de que ahora sí que tenemos scroll horizontal por hardware y que, además, los comandos de copia de VRAM a VRAM del VDP pueden funcionar sobre los modos de patrones (sin tener que realizar trucos de CPU como en el 9938).

Pero por otro, si lo comparamos con la siguiente evolución del chip de la Master System (el de la Megadrive) no lo veo lógico. Si ya el modo de patrones (y sprites) de la SMS gana a los modos de patrones del V9958, no digamos los patrones (y sprites) de la Megadrive.

Así pues, creo que lo justo es dejarlo en tierra de nadie y limitarnos a estudiar sus características extra:

ModoResoluciónColoresSprites
Screen 10
Screen 11
(Graphic 7 + YJK & YAE)
256x192 (512x212) pixels en pantalla 12499 colores + 16 colores de paleta Modo 2
Screen 12
(Graphic 7 + YJK)
256x192 (512x212) pixels en pantalla 19268 colores Modo 2

Si os dáis cuenta, los nombres oficiales de estos modos incluyen "Graphic 7" que, recordemos, se refería a Screen 8 del BASIC. Esto es así porque son dos modos gráficos que se basan en Screen 8, pero cambiando la forma en la que se definen los colores. Además, posiblemente, surja la siguiente pregunta: ¿por qué juntas Screen 10 con Screen 11? Bueno, porque aunque el BASIC los trate de diferente forma, el modo gráfico es exactamente el mismo. La única diferencia es la forma en la que el BASIC maneja los colores de los comandos gráficos. Pero para entender esta diferencia, primero hay que ver cómo es posible que el V9958 pueda mostrar tal cantidad de colores al mismo tiempo en pantalla, cuando una imagen en estos modos gráficos ocupa lo mismo que en Screen 8 (que, recordemos, sólo puede mostrar 256 colores al tiempo).

El truco está en el sistema de codificación de colores, que pasa del espacio RGB al espacio YJK. En RGB se almacenan los valores de intensidad de las tres componentes: rojo (Red), verde (G) y azul (B), mientras que en el espacio YJK se almacenan los valores de luminancia (o brillo) (Y) y crominancia (J y K). ¿Por qué se utilizó esta codificación? Bueno, pues porque el ojo humano es más sensible a los cambios de brillo que a los cambios de color, por lo que al separar la información del brillo de la de color es posible "comprimir" la imagen de forma que demos más importancia al brillo que al color.

Para ello, en Screen 12 el VDP almacena los valores de brillo (Y) de cada pixel de manera independiente, pero sólo almacena los valores de color (J y K) para grupos de 4 píxeles consecutivos de la siguiente forma:

bits7 6 5 4 32 1 0
pixel 0Y0K(low)
pixel 1Y1K(high)
pixel 2Y2J(low)
pixel 3Y3J(high)

Es decir, mientras que podemos controlar el brillo de cada pixel de la pantalla de manera independiente (con valores de 5 bits, es decir de 0 a 31), sólo podemos alterar el color (con dos valores de 6 bits con signo, es decir, de -32 a 31) en grupos de 4 pixeles consecutivos. Bien, ya tenemos unos cuantos datos, así que vamos a hacer números: podemos definir en cada pixel 5 bits de brillo y 12 de color, lo que hace un total de 17 bits para cada pixel... un total de ¡131072 colores diferentes!

¿Y por qué no podemos ver tantos colores en Screen 12? Bueno, la respuesta es que el 9958 sólo puede manejar valores RGB de 5 bits, por lo que la conversión de YJK a RGB no es una función inyectiva, es decir: valores diferentes de YJK producen el mismo valor de RGB por cuestiones de redondeo. Veamos esa función:

R = Y + J

G = Y + K

B = 5/4 * Y - J/2 - K/4

y pongamos un ejemplo rápido con los valores YJK(28,4,4) e YJK(29,4,4), que van a representar el mismo valor RGB(31,31,31) como podemos ver a continuación:

R = 28 + 4 = 32 -> 31

G = 28 + 4 = 32 -> 31

B = 5/4 * 28 - 4/2 - 4/4 = 32 -> 31


y


R = 29 + 4 = 33 -> 31

G = 29 + 4 = 33 -> 31

B = 5/4 * 29 - 4/2 - 4/4 = 33.25 -> 31

Vale, así que ya hemos visto cómo el VDP almacena el color de cada pixel mediante una compresión con pérdidas de los colores de la imagen original. Ahora lo que tenemos que hacer es calcular cuántas combinaciones diferentes de valores YJK nos producen valores RGB diferentes. Lo más sencillo es recurrir a la "cuenta de la vieja" y transformar las 131072 combinaciones de valores YJK en valores RGB, para así contar cuántos valores diferentes tenemos. Para ello, he hecho un programita en JavaScript que hace este cálculo para Screen 12 y Screen 10/11 y aquí tenemos los resultados del mismo:
Como se puede ver, las 131072 combinaciones de posibles valores de YJK se reducen a 19268 diferentes combinaciones RGB en Screen 12. Por otro lado, en Screen 10/11 tenemos un total de 65536 combinaciones YJK que se reducen a 12499 diferentes combinaciones RGB. ¿Por qué? Bueno, resulta que en Screen 10/11 la estructura de los datos es la siguiente:

bits7 6 5 432 1 0
pixel 0Y0A0K(low)
pixel 1Y1A1K(high)
pixel 2Y2A2J(low)
pixel 3Y3A3J(high)

Mientras que los valores de J y K se almacenan de la misma forma que en SC12, tenemos que los valores de Y se almacenan utilizando sólo 4 bits. El 5º bit se utiliza como un atributo A que funciona de la siguiente manera:
Es decir, si para un pixel concreto tenemos que el valor de su bit 3 (atributo A) es 1, significa que ese pixel tomará un color de la paleta, cuyo índice será el formado por los bits 4 a 7 del byte correspondiente. Llevando esto al extremo, tendríamos que si ponemos a 1 todos los bits de atributos de la pantalla tendríamos una suerte de SC5, pero que ocuparía el doble de memoria, ya que sólo se tendría en cuenta el valor del nibble superior de cada byte. De esta manera es posible mezclar gráficos RGB con gráficos YJK, a cambio de reducir el número máximo de colores visibles en pantalla.

Si, por el contrario, el valor del bit 3 es 0, entonces el color de ese pixel se calculará dentro del espacio de color YJK, tomando como valor de Y el formado por los mismos cinco bits que se usan en Screen 12. Pero, ¡ojo! Realmente sólo varían los cuatro bits superiores (16 combinaciones diferentes), lo que nos da como posibles valores para Y los números pares entre el 0 y el 31, ya que el bit menos significativo (el 3) siempre vale 0. Supongo que de esta manera se simplifica la circuitería del chip, ya que los cálculos para obtener Y son siempre los mismos: tomar el valor de 5 bits formado por los bits 3 al 7. Esto no lo he podido contrastar en ningún sitio, ya que no he encontrado ninguna documentación donde se indique explícitamente eso, pero es lo único que me cuadra para poder obtener los 12499 colores diferentes en Screen 10/11 en los que coinciden la mayoría de documentos (algunos dan otros valores erróneos, como 12599, que parecen typos).

Sí que he visto en esta web que para convertir una imagen de Screen 12 a Screen 10/11 bastaría con ejecutar la siguiente instrucción de BASIC:

LINE (0,0)-(255,211),&B11110111,BF,AND

que provoca el efecto de poner a 0 el bit 3 de todos los bytes de la memoria de vídeo. Eso reduciría los colores para poder visualizar la imagen en Screen 10/11, pero sin cambiar sus valores, lo cual confirma lo que indico: en Screen 10/11 los valores de Y son los números pares entre 0 y 31.

Como dato curioso, he calculado cuántos colores RGB diferentes se podrían obtener si se tomasen los valores de Y de 0 a 15 y salen 11865, un valor que no he encontrado en ningún sitio. Incluso he encontrado un programa en C en el que me he basado para hacer el javascript que menciono arriba y hace exactamente lo mismo: calcular Y de 0 a 31 ignorando el valor del bit del atributo... pero no lo explica en el artículo. Me permito ahora reescribir las tablas con las estructuras de los datos de color en Screen 12 y Screen 10/11 como creo que deben ser:

bits76543210
pixel 0Y0.4Y0.3Y0.2Y0.1Y0.0K.2K.1K.0
pixel 1Y1.4Y1.3Y1.2Y1.1Y1.0K.5K.4K.3
pixel 2Y2.4Y2.3Y2.2Y2.1Y2.0J.2J.1J.0
pixel 3Y3.4Y3.3Y3.2Y3.1Y3.0J.5J.4J.3
Screen 12 color data structure

bits76543210
pixel 0P0.3
Y0.4
P0.2
Y0.3
P0.1
Y0.2
P0.0
Y0.1
si A0 = 1
Y0.0 si A0= 0
K.2K.1K.0
pixel 1P1.3
Y1.4
P1.2
Y1.3
P1.1
Y1.2
P1.0
Y1.1
si A1 = 1
Y1.0 si A1 = 0
K.5K.4K.3
pixel 2P2.3
Y2.4
P2.2
Y2.3
P2.1
Y2.2
P2.0
Y2.1
si A2 = 1
Y2.0 si A2 = 0
J.2J.1J.0
pixel 3P3.3
Y3.4
P3.2
Y3.3
P3.1
Y3.2
P3.0
Y3.1
si A3 = 1
Y3.0 si A3 = 0
J.5J.4J.3
Screen 10/11 color data structure

Y ahora, tras esta explicación sobre el funcionamiento del espacio de color YJK en los MSX2+, vamos a ver la diferencia entre Screen 10 y Screen 11. Realmente son sólo diferentes a nivel de BASIC, ya que en realidad son exactamente el mismo modo. Lo único que sucede es que en Screen 10 todos los comandos gráficos aceptan un valor para el color entre 0 y 15, con lo que modifican únicamente el nibble superior (y ponen a 0 el bit del atributo), permitiendo ejecutar comandos de dibujo similares a Screen 5 sobre una imagen de 12499 colores. Por el contrario, en Screen 11 los colores permitidos van de 0 a 255, con lo que se modifican TODOS los bits de cada byte. Eso hace que los comandos gráficos del BASIC actúen de una forma muy rara en este modo.

Nuevamente estamos ante una evolución que se orienta más a un ordenador de propósito general (permitiéndole mostrar imágenes más realistas) que a una consola de videojuegos, con potentes modos de patrones como los que tienen la Master System o la Megadrive. Ya sabemos que los modos extra del 9958 se han aprovechado muy poco para juegos y, básicamente, se han limitado a mostrar imágenes estáticas de mayor calidad que las de Screen 8.

Sin embargo, otras características del 9958 sí que se han aprovechado más como el scroll horizontal por hardware o el hecho de que los comandos del VDP puedan funcionar sobre los modos de patrones sin necesidad de engañar al VDP para que se crea que está en Screen 8. Esto le da mucha más versatilidad, pero seguimos teniendo la limitación de dos colores por línea en cada patrón, algo que ya el VDP de la Master System solventa sin problema alguno.

El eslabón perdido: V9948

¿Nunca os habéis preguntado por qué se salta del V9938 al V9958? O también, ¿por qué la identificación del V9938 es 0 mientras que la del V9958 es 2? O incluso una pregunta más común, ¿por qué no existe Screen 9?

Al parecer, la respuesta a todas esas preguntas es la siguiente: existió el V9948. Según algunos rumores, este chip fue, al parecer, utilizado en un MSX2 destinado al mercado Koreano e incluía un modo de pantalla adicional (llamado Screen 9) para representar el alfabeto Koreano (o Hangul). Eso explicaría muchas cosas: para hacer compatibles los programas ya existentes no se podría usar Screen 9 porque lo haría incompatible con algunos modelos de MSX2. Además, la identificación del V9948 podría ser 1, lo que explica por qué se salta del 0 en la identificación del V9938 al 2 en la del V9958 (mirad el registro de estado 1), además de la numeración de los chips.

Incluso habría una cuestión adicional que quedaría solventada. El V9958 añade los registros 25 al 27 a los ya existentes en el V9938, pero éstos llegaban hasta el 23. ¿Por qué saltarnos el registro 24? Porque ese registro podría haberse utilizado en el V9948. Por último, según se puede leer al pie de esta página, Ademir Carchano tendría el databook completo del 9948.

¿A que ahora todo encaja? Pues bien, eso mismo tuvieron que pensar quienes iniciaron este Hoax allá por 1999. Si sabéis leer algo de portugués, podéis ir a esta página en la que nos explican la gestación de ese Hoax en tres capítulos. Incluso se puede ver alguna foto (obviamente retocada) del supuesto chip e incluso su "datacheat" (que no datasheet, como es lógico).

El caso es que este Hoax se extendió por algunas páginas y, como habéis podido ver, en determinados sitios con documentación sobre programación en MSX aún es posible encontrar información sobre la existencia de dicho chip. Yo dudo muchísimo que existiera realmente, dado que aún no se encontró ningún MSX real que lo contenga ni ha trascendido ese supuesto databook.

Dicen que una mentira adornada con verdades es mucho más creíble y, ciertamente, la broma tiene sus buenos fundamentos y explicaría algunas cosas. Pero hay que reconocer que lo de Screen 9 es cierto. Sí existe ese modo en algunos MSX2 Koreanos como el Daewoo CPC-300, en el que encontramos un Screen 9 en BASIC que es, en esencia, un Screen 6 controlado por software para mostrar el set de caracteres del alfabeto Koreano. Dicho Screen 9 forma parte del Hangul BASIC, que podemos encontrar como extensión para máquinas no Koreanas.

Pero, ¡aún hay más! En esta página japonesa se menciona explícitamente el V9948 como VDP de un posible MSX3. Si utilizamos un traductor como Google Translator, podemos leer más información: según algunos testimonios, el MSX3 fue un proyecto nunca anunciado para constituir la tercera generación del estándar. Ideado en 1985, cuando salió el MSX2 al mercado, contaría con un Z280 como CPU, un VDP V9948 y MSX-AUDIO (como el Music Module). También se indica que, según otro testimonio, existió otro proyecto llamado "TryX", que montaría una CPU compatible con Z80, pero más rápida, junto a un VDP V9978 o V9998. Pero debido a que no dio tiempo a terminar el VDP, se creó el MSX Turbo-R que todos conocemos.

Así pues, mi conclusión es que ese VDP nunca existió realmente, ya que no hay fotos reales, datasheets o información técnica oficial sobre él. Incluso dudo que existiera como proyecto más allá de su nombre, dentro de esa idea de MSX3 que ni siquiera fue anunciada. Mi opinión es que estamos ante un rumor falso (pero muy bien ideado) dentro del mundo del MSX.

Siguiente evolución: la revolución

La siguiente evolución del VDP de los MSX1 supondría una revolución completa, ya que saltaremos por un lado al V9990 y por otro al chip gráfico de la Megadrive. Un salto gráfico muy potente... a cambio de perder retrocompatibilidad (totalmente en el caso del V9990 y parcialmente en el caso de la Megadrive). Pero esto ya lo dejamos para un próximo artículo.

¡Nos leemos!