Comentario #1:

hola buenas tardes, desde hace tiempo, sigo este blog, y me resulta muy interesante, ya que siempre se aprende del el..
habiendo visto este artículo y siendo usuario activo de MSX, me gustaría hacer unas pequeñas actualizaciones, en algunas de las partes del artículo.. intentaré no ser muy pesado.

No importa, las voy a agregar a la entrada sobre la familia MSX cuando termine con los ordenadores de 8 bits.

En el apartado de las Roms, para MSX1, que yo recuerde hubo varios juegos de 2megabit en venta, némesis2 y 3, salamander, sol añgunos de ellos, en MSX2, solid snake eleva esta cantidad a 512, y hay al menos un juego de la KOEI que 1megabyte.

Es decir, que ese juego de Koei es de 8 Megabits, en realidad no me extrañaria porque la documentación que he leido es que el sistema esta diseñado para que cada fabricante de cartuchos utilice su propio intercambiador de bancos (el Z80 no puede direccionar más de 64KB y la memoria del cartucho se incluye en el mapa de memoria de la CPU). En cuanto al Metal Gear 2: Supongo que te referiras a 512KB o sea… 4 Megabits.

El MSX2 y con el su VDP (9938) rompe varios de los límites del MSX1, pasa de 5 a 8 sprites por linea, permite 1 color por linea en sprite, y añade modos bitmap,… el problema es que los modos bitmap son mucho más lentos que el moto pattern (o patrón), como dato, desde el BASIC una pantalla de sc4 (modo 4) ocupa 16kb, y la de SC5/sc6 (256x212x16 y 512x212x4) ocupan 26kb, dado es estos modo trabajan a 16 colores reales, de entre una paleta de 512, De hecho, la resolución “standard” en los juegos de MSX2, es 256x212x16 con paleta, dado que al tener 128kb de Vram, puede guardar los gráficos en la zona oculta de la pantalla (en basic páginas 1,2 y 3) y mediante la operación de copiado de bits, componer los gráficos de juego. El porqué de usar 16 colores con paleta, cuando el sistema te permite usar un modo de 256 colores fijos es el mismo que la diferencia entre modo patrón y el modo bitmap, una pantalla de 256×212/256 o su equivalente de alta resolución 512/x212x16 con paleta, ocupa la friolera de 54KB, lo que hace muy dificil componer un juego con solo una página de buffer., amén de que las operaciones en este modo de mucho más lentas que en lo anterior, (recordemos que son 8 bits por pixel).

Esto me parece interesante tratarlo, lo de límite de sprites/patrones por linea. A la gente le puede parecer confuso esto pero lo voy a explicar de manera sencilla y visual para que la gente lo entienda. Si lo leemos la primera vez nos puede dar a entender que el TMS9918A no puede dibujar más de 4 sprites/patrones, los cuales recordemos que son de 8×8 pixels pero si miramos las pantallas de los juegos…

gradius2msx

Veremos que hay más resolución horizontal que esos 32 pixeles que ocuparían los 4 patrones juntos. En realidad no es un problema de tasa de relleno sino que es un problema de la arquitectura del procesador. Hay que recordar que el TMS9918A no compone su imagen con un búfer que represente la pantalla de manera normal sino que lo que utiliza son patrones por cada «linea» y cada una de estas «lineas» por el tamaño de los patrones son 8 pixeles y por tanto 8 lineas de escaneo por lo que durante esas 8 lineas de escaneo el TMS9918A solo podrá componer la escena con esos 4 patrones/sprites que obviamente puede colocar en el orden que quiera, repetirlos… No es hasta el final de esas 8 lineas de escaneo que la Name Table puede definir otros sprites/patrones. En el caso de que uno de los patrones este magnificado a 16×16 entonces el cambio se hace a las 16 lineas de escaneo y no a las 8 lineas. En el V9938 lo que hicieron fue hacer que ese límite se rompiera y pasarlo a unos 8 patrones/sprites como limite. En todo caso gracias por la puntualización porque se me había pasado por alto.

Lo de la falta de rendimiento del modo bitmap me sorprende, aunque he encontrado algo muy interesante que supongo que ya sabrás porque has tocado la máquina y es que el V9938 tarda unos 6 ciclos de reloj, hay que tener en cuenta que la tasa de relleno es muy importante y que esta depende de la velocidad de escritura en memoria, si el V9938 funciona a 21Mhz esto es una tasa de relleno de 1.5 MB/seg, y para 256×192 y 8 bits de color a 60 fotogramas por segundo necesitamos:

256x192x60= Casi 3 Megapixeles.

La tasa de relleno es tan alta por lo que para poder aguantar el tipo el V9938 tiene que renderizar en modo bitmap con 4 bits de color pero lo que me fascina es que el V9938 tenga funciones de blitter para el modo bitmap, pero el blitter ya lo tratare cuando llegue al Atari ST y al Amiga. Pero es precisamente un blitter lo que permite que un procesador del tipo patrón se pueda convertir en uno del tipo bitmap pero eso para otra entrada.

Si bien el este VDP puede gestionar HASTA 192kb, los últimos son tratados como memoria extendida,, aún así, nunca se implementaron, salvo mods de usuario.

Interesante, aunque mirando los modos gráficos del V9938 donde la resolución máxima es de 512×212 pixeles con 4 bits de color o 256×212 con 8 bits de color en realidad con unos 64KB sería suficiente, supongo que los otros 64KB son para doble buffering en modo bitmap.

Otro dato, es que los modos del msx2 y msx2+ son exactamente los mismos salvo 3 modos,:

  • un modo de 10k colores fijos, para digitalizaciones
  • un modo de 11k colores fijos, de iguales características
  • un úlitimo modo de 19268 colores con codificación YJK para presentación de digitalizaciones de alta calidad, el problema de este último modo es que la compresión provoca “derrame” de color, estropeando bastante la calidad, en una tele de tubo casi no se nota, en una LCD canta de lejos

Supongo que estos modos están pensados para imagenes fijas, en todo caso tiene sentido porque la RAM de la época no tenía el suficiente ancho de banda como para permitir esa profundidad de color y crear el búfer de imagen a la suficiente velocidad. Mea culpa por no tener ese elemento en cuenta.

Si bien es cierto, que el v9938 no tiene scroll horizontal por hard, si que existe un sistema para hacerlo pero no queda tan “al pixel” como debe, se utiliza por ejemplo en el space manbow, y lo que hace es aprovechar el movimiento de ajuste horizontal de la pantalla, se ve en este video:

 

Pero el scroll sigue sin ser a nivel de pixel y se sigue haciendo a nivel de patrón en horizontal, en todo caso tuve una discusión no hace mucho con otra persona hablando del VIC-II del C64, me comentaba lo de «Al menos el MSX tiene rutinas de scroll en su VDP, el VIC-II carece de ellas y has de hacerlas via CPU quitando ciclos». Pero claro, en el C64 el VIC-II tiene aceso a la RAM del sistema y por tanto la CPU puede tocar la escena, en el TMS9918A  y derivados la RAM para video esta inaccesible para la CPU por lo que el control de scroll se tiene que integrar en el VDP si o si.

Como digo, el VDP del MSX2/2+ es un enorme salto sobre el del MSX de primera generación, y el hecho de que el Z80 tenga que ser el que le envíe los datos, lastra sobremanera el mismo, pruebas hechas acelerando el z80 a 6 o 7mhz (cambiando el z80a por un z80h y reajustando placa), me han demostrado que el VDP puede con MUCHO más de lo que el MSX2 es capaz de darle, en este sentido los MSX2+ de panasonic incluyeron un Z80b a 5.67mhz en el engine, que mediante un par de instrucciones me ha permitido demostrar que el z80a también lastra al v9958.

El problema del Z80 es que a la hora de crear la Name Table es lento por el hecho que escribe en memoria cada 4 ciclos de reloj, pero el problema se exagera si tenemos en cuenta que:

  1. Primero ha de crear la Name Table en la RAM principal, por suerte el TMS9918A/V9938 no interactua con la RAM del sistema y la tiene libre para crear la Name Table del siguiente fotograma mientras el TMS9918A dibuja el actual.
  2. El TMS9918A tiene que transmitir la Name Table a la VRAM del TMS9918A/V9938 en el tiempo del overscan, en el TMS9918A son unas 70 lineas en total pero en el V9938 son solo 50 lineas con una CPU que es la misma y va la misma velocidad.
  3. Cuando el Z80 envia datos a memoria o a otro procesador o periférico necesita unos 4 ciclos de reloj.

La velocidad de reloj del TMS9918A es de unos 5.37 Mhz, no sabemos cuantos pixeles por linea «dibuja» solo sabemos los que muestra que son 256 y sabemos que tiene que seguir el tiempo de escaneo del televisor que son 262 lineas.

(5.37*10^6)/(60 fotogramas*262 lineas por fotograma)= 341 pixeles por linea de los que se muestran 256.

Obviamente durante el HSYNC no se muestran esos pixeles de más, pero sabemos que el tiempo de VSYNC y overscan es de unas 70 lineas por lo que estamos hablando que en terminos del TMS9918A el Z80 tiene unos 341*70 ciclos de reloj para enviarle los datos, esto son unos 23870 ciclos, la Name Table es de unos 32×24 y por tanto de 768 bytes, debería tener tiempo de sobras para realizar la Name Table de la escena pero hemos de tener en cuenta que el Z80 va a 2/3 de la velocidad por lo que en ese mismo periodo para si tiene unos 15913 ciclos de reloj para si, si tenemos en cuenta los cuatro ciclos de reloj para escribir en memoria esto pasan a ser 3978 ciclos y es que aún hay más, necesitamos escribir 3 bytes en el puerto de comunicacion del TMS9918A, los dos primeros son la dirección de memoria de la VRAM y el tercero es el dato en si mismo.

En el V9938 lo tenemos peor, en primer lugar la resolucion es de la Name Table es de 848 bytes por el aumento de resolución, dado que va al compas en que se renderiza la escena y tenemos unas 212 lineas mostradas ahora el VSync es solo de 50 lineas por lo que los 15913 ciclos pasan a ser unos 11366 ciclos, los cuales con los 12 ciclos de retardo que he comentado antes tenemos unos 947 bytes, por lo que en teoría el Z80 no debería ser un cuello de botella para el V9938 realmente. Pero el V9938 puede funcionar con unos 512 pixeles y por tanto con una resolución de 512×212 y esto es una Name Table de unos de unos 1696 bytes que para que el Z80 tuviese suficiente velocidad para enviarla tendría que funcionar en ese periodo de overscan de 50 lineas a unos 20352 ciclos de reloj, lo que significa que tendríamos que subir el Z80 a un mínimo de 6.4 Mhz por lo que tendríamos que tener un Z80 a 7.16 Mhz u 8 Mhz como CPU para que el Z80 no sea un cuello de botella.

Lo curioso es que si el V9938 es un TMS9918A modificado que puede ir cuatro veces la velocidad de este entonces es capaz de componer imagenes a 512×424 sin problemas, obviamente es un 424i desde el momento en que hablamos de un televisor de tubo pero la Name Tale tendría ese tamaño y ahí ya es inalcanzable para el Z80.

Un dato erroneo es el referente al MSX turbo R (del cual dispongo), este ordenador usa exactamente el mismo esquema de memoria que sus hemanos mayores (páginas de 16kb), ahogando la capacidades del R800, el cual siendo un procesador bastante desconocido es capaz de gestionar 1MB lineal, el problema es que esta característica, junto con sus dma,s no se habilitaron en el ordenador, para mantener la compatibilidad con el software existente, también he de puntualizar el turbo R a1st viene con 256KB de ram y el a1gt con 512 (amén del MIDI, pero eso no es para esta entrada).

No se nada sobre el R800 realmente, lo he mirado muy por encima y el hecho que dices que puede direccionar hasta 1MB de memoria por si solo es algo que a nivel gráfico es trivial desde que el V9958 no tiene acceso… Bueno, si que tiene acceso a la memoria principal al contrario que sus antecesores porque tiene un mecanismo de blitter que permite copiar los datos desde la RAM principal a la VRAM sin que la CPU participe en ningún momento en la composición de la escena, pero no se a que velocidad lo hace. Esto es ideal para copiar la Name Table en menos tiempo no… Es decir, no se si el Blitter tiene suficiente capacidad como para prescindir de la CPU en ese tarea, lo desconozco por completo.

Pero el Blitter tiene otra utilidad muy buena que es el hecho de poder reemplazar la lista de Patrones/Sprites en la VRAM que se utilizan para componer un nivel. Dicha lista de Patrones/Sprites se encuentran en la VRAM y esta limitada y si se pueden ir cambiando al vuelo tiene que dar una mayor variedad gráfica a la escena. No se si el Blitter tiene acceso al puerto de cartuchos porque entonces una vez el programa del nivel se cargase en la RAM el V9958 a través del Blitter podría acceder al slot de cartuchos copiando los datos y lo que es mejor si lo hace puede copiarlos al vuelo haciendo que podamos tener tanta variedad de patrones/sprite como la cantidad de estos en la Name Table dando una versatilidad creativa mucho más grande, pero es que además si el Blitter fuese lo suficientemente rápido y pudiese cambiar al vuelo el contenido del Line Buffer entonces puede romper el limite de 8 sprites y pasaríamos a tener lo que Sega en su modificación del TMS9918A para Mega Drive/Genesis paso a llamar…

video_thumbnail_2681021

Supongo que estas capacidades no se utilizaron en el V9958 porque pese a estar la funcionalidad implementada no era lo suficientemente rápida como para ser útil. Y me baso en el hecho que los desarrolladores pasaron olimpicamente de hacerlo aunque el concepto ya estaba implementado en el hardware.

Como ya he dicho, el V9958 es virtualmente el v9938 con scroll horizontal por hardware y 3 modos gráficos para digitalizaciones, de hecho la ampliación del MSX2 a 2+ es LITERALMENTE cambiar el VDP (haciendo ciertos puentes en el chip para porque manda algunas señales de otra forma), pasando de tener un MSX2 a un 2+ en un rato. Como nota particular respecto al VDP del MSX2+ peca de falta de ambición, pero mucha además, lo único que hacen es añadir un scroll horizontal, conservando todas las limitaciones anteriores, número de sprites, que éstos solo puedan ser de un color por línea, el límite de 8 sprites en linea (algunos juegos de MSX2 sufren enormes parpadeos por enviar sprites a go-go)…amén de que cuando el MSX2+ se lanza (1988), deberían, si querían que el ordenador no acabase como acabó, haber puesto una CPU con más “enjuntia”, una cpu que circulaba por aquella época era el HD64180, que es un z180 con mejoras. bueno disculpa la chapa.. me he dejado alguna cosilla, como que el msx2+ standarizó el mapeado de la Ram, y que introdujo la especificación MSX-MUSIX, y los sistemas de sonido que acompañaron al standard.

Vamos, que es una version 1.1 con pocos cambios respecto al V9938, no conocía el MSX2+ y no lo he tocado en mi vida pero cuando vi lo del Blitter en el V9958 me pareció un elemento fascinante que puede eliminar todos los problemas del V9938 pero veo que no es así y que el sistema como dices fue poco ambicioso y supongo que el blitter es casi inutil o poco documentado, sinceramente me deje llevar por la presencia del Blitter, un elemento que fue un paso adelante para los gráficos en ordenadores de 16 bits pero como bien afirmas en 1988 el sistema tenía que haber tenido una CPU de 16 bits basada en Z180 para que esta no fuese un cuello de botella, pero sobretodo tendría que haber tenido también como bien dices un mejor VDP. ¿Que consola fue lanzada en Japón en 1988 que llevaba un VDP basado en un hack del TMS9918A?

SONY DSC

Por lo que un MSX de unos 16 bits hubiese sido posible en 1988.

Como dato interesante, este fin de semana se celebra la 50Reunión de Usuarios de MSX en barcelona, pongo la web, por si hay interesados.

A ver si puedo ver la presentacion del VRbit. 🙂

Comentario#2: 

Urian estas que te sales, de verdad no podía ni imaginar que quedaría algo tan interesante.
A ver si se anima mas gente a escribir en estas entradas que se que las leen (Algún profesor de universidad, y al menos un par de perros viejos que incluso programaron cosas de forma profesional para estas maquinas). No te preocupes por que te corrijan, de echo cuando llegues al Amstrand cpc te aviso que es posible que te comenten cosas sobre modos indocumentados en primicia (que lógicamente si hasta este mismo año nadie las conocía, o al menos nadie las había usado, implica que es muy posible que no seas consciente de ellas).
Ademas ten en cuenta lo que te comentaba el señor Lerma, hay gente en España que lleva peleándose con estas maquinas mas de 30 años y que las conocen mejor casi que sus propios creadores si te descuidas. Que te corrijan o comenten en el blog esas cosas es para sentirse orgulloso por que demuestra que si te leen es porque realmente lo que haces esta muy por encima de la media.
Un saludo.

Gracias por valorar el trabajo y tener en cuenta que no puedo llegar a todo.

La entrada sobre el Amstrad CPC ya la he hecho, espero tus comentarios en la misma e incluso acepto correcciones en dicha entrada como en las otras que ire haciendo. Lo digo porque el Amstrad CPC es otro ordenador como el MSX que conozco poco, más que nada por la edad aunque la curiosidad me puede en todos estos casos.