jltursan escribió:¡Perfecto!, las pantallas son simplemente las guindas del pastel, no hay obligación de incluirlas; pero es que quedan redondas
Una vez vista, hay que ponerla si o si!
Para Dragón ha sido un plis plas, a la primera todo en órbita. Como Basic empeza en $c00 y el juego en $e00, pues disponemos de
512 bytes para Basic.
En CoCo las cosas empeoran ya que el Basic empieza en $e00, siendo inmediatamente sobreescrito al cargar el binario ...
He añadido una pequeña rutina en código máquina que se ejecuta desde el Basic y así la carga del binario se hace ya desde fuera
del programa, por lo que el hecho de que lo 'machaque' no molesta
Al arrancar el programa mostraba todo el menú inicial con letras de doble altura ... maldición!
Resulta que, al declarar todas las variables en la página cero para liberar memoria para el programa, el valor inicial de las variables
depende del contenido que tuvieran cuando estaban gestionadas por el Basic. Dragón no modifica el área de la variable que controla
la altura de las letras, pero CoCo *SI*, así que, de momento, le he puesto un POKE a valor cero en el BASIC, pero por supuesto que
lo correcto es asegurar que las variables no inicializadas tengan valor cero ...
Esto puede que de alguna pista sobre los 'problemillas' que aparecían en determinadas pantallas relativos a la caída de Foggy que, en
ocasiones llegaba a ser imposible! Estoy convencido de que es tema de variables no inicializadas también ...
He hecho dos variantes del programa que lanza los binarios una para cada modo gráfico, nombres LPM3.BAS y LPM4.BAS
saludos
pere
Pd El zip contiene 2 dos carpetas: CoCo y Dragon, cada una de las cuales contiene el disco virtual y los dos binarios