lunes, 28 de noviembre de 2011

Intro del KNT en MSX1

SCREEN 8... ILLEGAL FUNCTION CALL

Imaginemos la situación, tenemos un bonito MSX2 y al intentar ejecutar SCREEN 8 obtenemos un curioso mensaje de error: ILLEGAL FUNCTION CALL.

¿Cómo? ¿Que no es posible? Pues lo cierto es que sí lo es. Y no sólo SCREEN 8, también sucedería lo mismo con SCREEN 7. Mirad este vídeo si no os lo creéis.

Todos estamos acostumbrados a trabajar con MSX2 que tengan, al menos, 128Kb de VRAM (digo al menos, porque se puede aumentar la memoria de vídeo hasta los 192Kb, pero eso es otra historia). Sin embargo, existen varios modelos de MSX2 con tan solo 64Kb de VRAM. Según la lista de hardware de la MSX faq, dichos modelos son:

Bien, en todos estos modelos cualquier intento de usar tanto SCREEN 7 como SCREEN 8 va a resultar en un bonito error. ¿Por qué? La respuesta la encontramos indagando un poco en la documentación técnica disponible (os recomiendo PORTAR).

Resulta que estos dos modos utilizan un total de 256 bytes por cada línea horizontal y por razones de velocidad la VRAM está direccionada de diferente forma: los 64K inferiores almacenan las direcciones pares y los 64K superiores almacenan las direcciones impares. De esta forma el controlador de vídeo puede incrementar las líneas de dirección inferiores a la misma velocidad de reloj que en los modos de 128 bytes por línea horizontal (como pudiera ser SCREEN 5).

Lo divertido del caso es que esto se hace de forma totalmente transparente para el programador. Todo el cambio de direcciones se realiza por hardware, sin que nosotros tengamos necesidad de saber ese comportamiento. Bien. Con esta pequeña explicación, habréis deducido que si sólo tenemos 64Kb de VRAM, por mucho que el hardware intente entrelazar la imagen, todos los bytes impares no podrán escribirse, con lo que el VDP debería leer $FF y tendríamos una bonita pantalla llena de líneas verticales en blanco entrelazadas con nuestra imagen.

El BASIC, que es más inteligente de lo que parece, chequea una variable que la BIOS ha calculado para comprobar cuanta VRAM hay. Si sólo hay 64Kb de VRAM no permite activar ninguno de estos modos, por lo que en un MSX2 con 64Kb de VRAM sólo tenemos los modos de vídeo del 0 al 6.

Las preguntas que surgen ahora son, ¿qué pasaría si le decimos al VDP que construya una imagen tomando los datos de la VRAM que no existe? ¿Lee 255 y nos muestra una imagen en blanco? Pues lo que sucede es, ni más ni menos que lo que se puede ver en este vídeo.

¡Flipante! El VDP se arma un lío tremendo y nos muestra una imagen que va cambiando de forma constante. Aunque tiene algunos patrones, no hemos podido averiguar por qué sale eso en concreto. No cambia ni aunque haya una imagen en la página 0, sólo alguno de los colores, que lo toma del segundo parámetro que utilicemos en la instrucción COLOR.

Es hora de probarlo

Pues nada, sólo tenéis que coger vuestro MSX2 con 64Kb de VRAM y prob... ¿qué? ¿Que no tenéis un MSX2 con sólo 64Kb de VRAM? Bueno, pues caben dos opciones: quitarle los chips de VRAM de los 64Kb superiores o bien usar un emulador... ¿O no? Probemos con los dos emuladores más populares: BlueMSX y OpenMSX. Crearemos una máquina MSX2 con sólo 64Kb de VRAM y veremos si al ejecutar SCREEN 8 obtenemos un bonito ILLEGAL FUNCTION CALL.

¡Vamos a por BlueMSX!

Probemos primero con BlueMSX. ¡Anda! ¡Pero si me deja ejecutar SCREEN 8! No, no os he estado engañando. Si volvemos a arrancar la máquina, lo primero que nos llama la atención es que en el arranque del MSX2, bajo el logo, veremos perfectamente que la máquina tiene 128Kb de VRAM, cuando en realidad le hemos dicho que debe tener 64Kb.

¿Por qué? Resulta que el BlueMSX emula los 64Kb de VRAM haciendo mirroring de los 64Kb inferiores en los superiores. Esto significa que si escribimos en cualquiera de esos dos bancos, en realidad estamos escribiendo en ambos a la vez. Por este motivo la BIOS se cree que hay 128Kb de VRAM y así actualiza sus variables, pero esos 64Kb superiores simplemente son una copia de los inferiores.

Sí, podemos usar SCREEN 8, pero es algo totalmente ilegible. Para poder comprobarlo utilizad el siguiente código en BASIC:

10 COLOR 15,0,0:SCREEN 8
20 OPEN "GRP:" AS#1
30 COLOR 255
40 PSET (0,0),0
50 PRINT#1,"HELLO WORLD!"
60 GOTO 60

Mientras que en un ordenador real con 64Kb de VRAM este código no funciona porque nos da un error en la línea 10 (al intentar ejecutar SCREEN 8), en el BlueMSX sí que funciona, aunque el resultado no es legible. Probad el mismo listado con SCREEN 7 (cambiando la línea 30 por "COLOR 15", obviamente) y veréis que sucede algo similar. En un MSX2 (o superior) con 128Kb de VRAM este programa funciona como se supone debe hacer.

Y ahora Open MSX

Probemos en Open MSX 0.8.1 (la última versión disponible). Nos creamos una máquina con 64Kb de VRAM y ¡maravilla! ¡En el arranque se detectan sólo 64Kb de VRAM! Tecleamos SCREEN 7 y obtenemos el error. Con SCREEN 8 nos pasa lo mismo. Nunca un error del BASIC había originado tantas alegrías.

Resumiendo: existen (al menos) cinco modelos de MSX2 con sólo 64Kb de VRAM. En dichos modelos no podemos contar ni con SCREEN 7 ni con SCREEN 8. Si estamos realizando algún juego que vaya a usar esos screens, o que requiera 128Kb de VRAM, deberemos tener en cuenta su existencia y si queremos ser puristas, en caso de que no haya VRAM suficiente adaptarse (como hace QBIQS) o mostrar un mensaje de error.

También hay que tener en cuenta que BlueMSX está emulando de forma incorrecta los 64Kb de VRAM, ya que, como hemos comprobado, cuando intentamos visualizar el contenido de los 64Kb superiores en el Hitachi MB-H3, obtenemos una imagen bastante extraña. Eso nos permite concluir que este modelo no hace un mirroring completo de los 64Kb inferiores en los superiores.

Nuevamente quiero agradecer a BiFiMSX su ayuda sobre este tema. También a él le debemos que C-BIOS realice correctamente la detección de los 64Kb de VRAM, algo que hizo tras una charla que mantuvimos al descubrir que el QBIQS en C-BIOS con 64Kb de VRAM no funcionaba como es debido. También he de agradecer a JLTurSan que me haya prestado su flamante Hitachi MB-H3 para hacer las pruebas sobre la máquina real.

martes, 22 de noviembre de 2011

Plantilla para cajas de cartuchos

Nuestro amigo RC-743 ha realizado una estupenda plantilla para que podamos hacer cajas para nuestros cartuchos de MSX. Tiene la medida perfecta para que quepa dentro el cartucho, de forma que no tengamos que hacer un cajoncito extra para meterlo.

Pinchad sobre la imagen para descargaros la plantilla y, si os gusta, no dejéis de darle las gracias a su autor.

domingo, 20 de noviembre de 2011

Programando para COLECOVISION

La consola COLECOVISION fue la propuesta de COLECO al boom de las consolas. Vio la luz en 1982 y en sus apenas dos años de vida comercial vendió más de seis millones de unidades.

La COLECOVISION nos ofrece un hardware muy muy similar al del MSX1, ya que comparte con éste CPU y VDP. El sonido lo genera con el SN76489 de Texas Instruments, que es el mismo que podemos encontrar en la Sega Master System, aunque esto dará para otra historia ;)

Aunque la CPU y el VDP son idénticos, no funcionan exactamente igual en ambos sistemas, por lo que hay que tener en cuenta los siguientes puntos importantes:
  • RAM: la norma MSX dicta que la mínima cantidad de RAM disponible en un MSX1 ha de ser de 8kb, situadas en el área desde $E000 a $FFFF. En la COLECOVISION tenemos única y exclusivamente 1kb de RAM, situada en la zona entre $7000 y $73FF, aunque también puede accederse en otras áreas que forman un mirror de esta zona de memoria.
  • Ubicación de la ROM: en MSX lo normal es que las ROMS de 32k se sitúen en la zona de memoria desde $4000 hasta $BFFF, aunque como ya sabemos todos, gracias al sistema de slots del MSX es posible situar las ROMS prácticamente en cualquier dirección. Sin embargo, en COLECOVISION la ROM sólo puede situarse en los 32kb superiores: de $8000 a $FFFF.
  • Interrupciones: en el MSX no tenemos NMI, es decir, todas las interrupciones que se generan son enmascarables. En la COLECOVISION parece ser todo lo contrario. La interrupción de blanqueo vertical (producida por el VDP cada vez que se termina de dibujar un frame) es una NMI. No he encontrado información sobre si se pueden producir otro tipo de interrupciones enmascarables, así que por el momento las podemos ignorar. Esto, que parece poco, significa que las instrucciones DI y EI no van a desactivar las interrupciones del VDP, por lo que habrá que utilizar el bit 5 del registro R#1 del VDP para controlar las interrupciones (si está a 0, el VDP no generará interrupciones).
  • Acceso al VDP: en MSX la norma dicta que las direcciones de acceso al VDP han de leerse de los bytes 6 y 7 de la BIOS. En COLECOVISION el VDP se sitúa en varios puertos, pero lo normal es acceder a través de los puertos $BE y $BF. Esto equivaldría a tener una BIOS en MSX en la que en las direcciones 6 y 7 tuviéramos el valor $BE.
Pasemos ahora a ver la estructura de la cabecera de una ROM de COLECOVISION:
  • $8000: contiene dos bytes que pueden ser $AA y $55 o bien $55 y $AA. La diferencia es que en el primer caso se mostrará la pantalla de presentación de COLECO y en el segundo caso no.
  • $8002: Puntero a una copia en RAM de la tabla de atributos de sprites (*)
  • $8004: Puntero a una tabla de prioridades de sprites (*)
  • $8006: Puntero a un buffer libre en RAM (*)
  • $8008: Puntero a una zona de memoria (12 bytes) para gestionar los controles (*)
  • $800A: Puntero al inicio del juego
  • $800C a $8020: aquí lo que hay que situar es el código que será ejecutado cada vez que se haga un RST. En la BIOS de la COLECOVISION, en las direcciones a las que se puede hacer RST ($0008, $0010, $0018, $0020, $0028, $0030 y $0038) encontramos saltos incondicionales a esta zona. Tenemos 3 bytes para cada RST, por lo que si necesitamos utilizar alguno de ellos, pondremos un JP a la rutina necesaria (tres bytes), mientras que si no lo necesitamos, podemos poner un RET (y un par de NOPs para rellenar). Concretamente las direcciones de salto para cada RST son:
    • RST $08: $800C
    • RST $10: $800F
    • RST $18: $8012
    • RST $20: $8015
    • RST $28: $8018
    • RST $30: $801B
    • RST $38: $801E
  • $8021: aquí situaremos el código a ejecutar (máximo 3 bytes) cuando se produzca una NMI. Recordemos que en la COLECOVISION se produce una NMI cuando el VDP termina de dibujar un frame, por lo que aquí deberíamos situar un salto incondicional a la rutina de tratamiento de interrupciones.
  • $8024: aquí situaremos una cadena identificativa del juego, que será la que se mostrará en la pantalla de presentación de COLECO (si los dos primeros bytes de la ROM son $AA y $55). El formato de la cadena será:

    LINEA 2 / LINEA 1 / AÑO (4 dígitos)

    y la pantalla de presentación quedaría parecido a esto:

    COLECOVISION

    PRESENTS

    LINEA 1

    LINEA 2

    AÑO
Los punteros marcados con (*) o bien serán 0 o bien apuntarán a zonas de RAM, en cuyo caso serán usados por la BIOS de la COLECOVISION.

Por el momento ya tenéis información suficiente como para intentar hacer una pequeña ROM para COLECOVISION, como por ejemplo el clásico "HOLA MUNDO". En un futuro post veremos cómo leer los controles y las diferencias entre el AY-3-8910 (el PSG del MSX) y el SN76489 (el PSG de la COLECOVISION y la Sega Master System).

El emulador que os recomiendo para trabajar con la COLECOVISION no es otro que el mismísimo BlueMSX. ¡Buen provecho!

martes, 8 de noviembre de 2011

Cuadragésima RU de Barcelona: 20 años disfrutando el MSX


El próximo 10 de Diciembre de 2011 se celebrará la cuadragésima Reunión de Usuarios de MSX en Barcelona (RU para los iniciados), que será una edición especial dedicada al vigésimo aniversario de esas reuniones.

En esta ocasión la reunión se aleja de Cotxeres para instalarse en un nuevo espacio, concretamente en la Sala de actos del Centro la fontana, en C/ Gran de Gracia número 190, al lado de la parada de metro de Fontana, L3. La apertura al público será a las 11 de la mañana, aunque los expositores podrán entrar desde una hora antes para montar sus stands.

Es un evento importante para todos los aficionados al MSX. Si vas a estar por Barcelona el 10 de Diciembre, ¡NO TIENES EXCUSA PARA NO ASISTIR! Para más información, pinchad sobre la imagen para ir a la web de la AAMSX.

Por mi parte, espero poder asistir a la reunión, aunque no pondré stand. Eso sí, si voy igual cae alguna sorpresita que otra ;)