En el emulador

Hay que anclarlo en la pagina 2

openMSX no acierta solo con este cartucho: lo coloca en 0x4000 y el juego no arranca, porque su cabecera declara TEXT en 0x8010 y ahi no hay nada. Hay que decirle donde va. Con una extension propia:

<?xml version="1.0" ?>
<!DOCTYPE msxconfig SYSTEM 'msxconfig2.dtd'>
<msxconfig>
  <info>
    <name>3D Golf Simulation</name>
    <manufacturer>T&amp;E Soft</manufacturer>
    <code/><release_year>1983</release_year>
    <description>Cartucho de 16 kB anclado en la pagina 2.</description>
    <type>cartridge</type>
  </info>
  <devices>
    <primary slot="any"><secondary slot="any">
      <ROM id="3D Golf Simulation ROM">
        <mem base="0x8000" size="0x4000"/>
        <rom><filename>.../3dgolf.rom</filename></rom>
        <mappertype>Mirrored</mappertype>
      </ROM>
    </secondary></primary>
  </devices>
</msxconfig>

Se guarda en share/extensions/ del directorio de usuario de openMSX y se arranca con -ext <nombre>. slotmap confirma que la ROM esta en 0x8000.

Y hace falta un MSX japones

El juego escribe las posturas del golfista y los rotulos del panel con bytes altos, que en un MSX japones son los graficos y el katakana y en uno europeo son otros simbolos. En una maquina europea el campo sale igual -es geometria pura- pero esos rotulos salen mal. No es un fallo del cartucho.

Y paciencia

Dibujar el hoyo 1 le lleva al interprete mas de cinco minutos de reloj emulado: la subrutina 2500 lee el contorno valor a valor con PEEK, HEX$ y VAL, y los rellenos del plano tampoco son rapidos. tools/omsx_campo.tcl apaga el limitador de velocidad y espera hasta el segundo 380 antes de volcar.

Lo que se comprobo contra la VRAM

tools/campo.py dibuja el campo ejecutando en Python las mismas subrutinas del programa, sobre una emulacion de SCREEN 2 con sus atributos de color. make vram compara el resultado con el volcado del emulador:

region	pixels iguales	bytes de VRAM iguales
plano cenital	15.737 de 15.744 (99,96 %)	4.217 de 4.224 (99,83 %)
vista 3D	18.011 de 18.432 (97,72 %)	4.439 de 4.608 (96,33 %)

El plano es el que importa, porque es el que el juego lee con POINT para saber de que es el terreno. Los siete pixels que bailan estan en el borde de dos bunkers.

En la vista 3D, los que bailan son pixels de borde de las mismas lineas, desplazados uno. Se probaron seis variantes del trazado de lineas y ninguna cierra el hueco del todo; queda en Preguntas abiertas.

Lo que la VRAM enseno del SCREEN 2

Emular la pantalla no era opcional -el juego LEE de ella- y el modelo obvio salia mal. Lo que dice la VRAM de verdad:

• Un LINE ... BF no es un monton de puntos: rellena por bytes enteros, y donde la fila de ocho pixels queda cubierta del todo deja el patron a cero y el color en el nibble bajo. El suelo de la vista vale patron 00 y color 0C; el cielo, 00 y 05.
• Al pintar un punto de un color que no es ninguno de los dos de la fila, el resultado depende de como estuviera la fila. Si estaba toda de fondo, el color nuevo entra como tinta -y por eso las lineas blancas de la vista salen finas sobre el verde, de 0C a FC, en vez de arrastrar la celda entera-. Si estaba toda de tinta, entra como fondo: asi es como el marco blanco se mete en el borde del plano, de 60 a 6F con el patron de FF a 7F.
• SCREEN 2 + CLS deja la tabla de color a 0x00, no a 0xF0.

Con el modelo ingenuo, el plano cuadraba al 38 %. Con este, al 99,96 %.