Uso y abuso de la RAM7

[zup]

Abro este hilo separado del de paginación en 128k, para compartir información sobre ese campo de minas que es la página 7 de la RAM. Este tema lo he estado discutiendo en WOS y Zona de pruebas, donde he encontrado un montón de información útil.

El mejor documento que he conseguido es el desensamblado de la ROM del +3. Si miramos en el desensamblado de la ROM de disco, hay una sección descrita como sysvarp7.def. Ahí van todas las zonas ocupadas conocidas, y su descripción. Ahora van algunas observaciones sobre la RAM7:

- Muchos juegos que cargan desde cinta, tanto si usan cargadores desde c/m (Captain Blood, Carrier Command) como si usan cargadores BASIC (Operation Wolf, Typhoon, ¿Gryzor? este lo convertí hace tiempo y no me acuerdo de su cargador), cargan datos a la RAM7 y funcionan correctamente. Podemos suponer que, si no se usa el disco, la RAM7 es segura.

- Si cargamos desde disco el +3DOS corromperá datos que tengamos en ciertas áreas de la RAM7, o bien intentará leer datos de zonas que hemos sobreescrito provocando un cuelgue.

- Como se discutió en otro hilo, la RAM7 parece tener datos del editor de BASIC. En condiciones normales de ejecución, esto no es un problema (no se usa el editor), pero si tienes datos en la RAM7 y vuelves al editor no se puede preveer ni el comportamiento del editor ni la integridad de los datos de la RAM7 (aunque no me imagino por qué alguien edita el BASIC teniendo c/m o datos en memoria). En el desensamblado de la ROM, admiten que el uso de la RAM7 por parte del editor no se conoce por completo.

Y estas son mis dos listas de zonas de la RAM7. La lista de áreas utilizadas son las que pueden ser machacadas por el +3DOS (dependiendo del tipo de operación, y también de si cargas desde BASIC o c/m, algunas de estas áreas pueden usarse).

Áreas utilizadas:

Código: Seleccionar todo

$c000 ~ c05ff   49152 ~ 49427
$db00 ~ $e7ff   56064 ~ 59391
$db00 ~ $e500   56064 ~ 58624   Usada en +3e
$e600 ~ $e601   58880 ~ 58801   Usada en +3e
$e8e0 ~ $eb50   59516 ~ 60240   Usada en +3e
$ec00 ~ $eff8   60416 ~ 61342   Usada en +3e
$f3be ~ $f330   62398 ~ 62526   Usada en +3e

Áreas libres:

Código: Seleccionar todo

$c060 ~ $daff   49428 ~ 56063   6636 bytes
$e60e ~ $e77b   58894 ~ 59259    366 bytes   ?
$e800 ~ $ebff   59932 ~ 60415    484 bytes   ?
$ec20 ~ $ecff   60448 ~ 60671    224 bytes   ?
$f511 ~ $f6e9   62737 ~ 63209    473 bytes   ?
$f700 ~ $fbff   63232 ~ 64511   1280 bytes   ?
$fe00 ~ $ffff   65024 ~ 65535    512 bytes   Libre si no hay boot

Unas pocas observaciones a estas listas:
- El área que se usa al principio de la RAM7 coincide con la ubicación de la "segunda pantalla". Perfectamente utilizable si no usas el disco entre medias, pero me pregunto por qué machacan un área que estaba documentada para otro uso.
- Las áreas a partir de $e800 se usan para cosas del editor. Quizás podamos considerarlas como un área libre bastante hermosota, a condición de que jamás volvamos al editor. Aún así, ciertos comandos (COPY / FORMAT) pueden usarlas... pero no me imagino para qué quieres formatear un disco en un juego.
- La última área sólo se usa si llamas a DOS_BOOT. Esta rutina se llama solamente cuando quieres cargar el sector de arranque del disquete, así que una vez hayas terminado de usar ese sector la puedes considerar libre.
- He puesto solo las áreas "más gordas". Hay bytes por aquí y por allá que no están utilizados, pero supongo que no se me ocurren muchas cosas que almacenar en un byte.

¿Alguien quiere añadir/debatir algo acerca de esto?

[zup]

Y el recordatorio de turno: ¿cómo saber si +3DOS me ha machacado algo de mis datos?

Ya lo comenté en otra parte: ZX Spin (y Spectaculator, pero me gusta más lo de ZX Spin) puede sacar "fotos" de la RAM a nuestro disco duro, para luego poder compararlas. Instrucciones básicas (para ZX Spin):

Suponemos que tenemos un bloque de datos de 10000 bytes que debe ir en la RAM7 a partir de la dirección 50000 (dirección del Z80). Así que vamos a seguir tres pasos:

1.- Sacar una "foto" de referencia:
Si tenemos ya un fichero binario en nuestro disco duro (recordemos: la longitud son 10000 bytes), ya está hecho.

Si no, cargamos el fichero a partir de 32768 (LOAD "ram7" CODE 32768. Después vamos al menú File > Save Binary File... y en el cuadro de diálogo que aparece, rellenamos estos datos:
- Filename: ram7.def
- RAM Page: Main Memory
- Start Address: 32768
- Length: 10000

2.- Sacar una "foto" de cómo están las cosas antes de ejecutar nuestro programa:
Después de cargar los datos, ubicarlos en la RAM y todo eso, imaginemos que nuestro programa empieza a ejecutarse en 26324.

Vamos al menú Tools > Debugger..., y en la ventana que aparece seleccionamos el menú Breakpoints > Set Breakpoint.... En Address elegimos 23624 y dejamos el resto de campos en blanco y pulsamos aceptar. Con eso tenemos un breakpoint que saltará justo cuando acabemos de cargar. Ahora pulsamos sobre la flecha que pone Run para volver al Spectrum.

Cargamos el juego. En cuanto termine de cargar, saltará otra vez la ventana del depurador. Ahora vamos al menú File > Save Binary File... (está en las dos ventanas, no importa cuál elijáis) y en el cuadro de diálogo volvemos a rellenar, pero con estos datos:
- Filename: ram7.tst
- RAM Page: Bank 7 -> Este es el banco de RAM que queremos salvar. Ponemos esto porque, cuando terminamos de cargar, puede que la RAM7 esté o no paginada (de hecho, lo normal es que estuviera paginada la RAM0).
- Start Address: 848 -> Este es el inicio desde el inicio del banco de RAM. cuando paginas la RAM7, se coloca a partir de 49152, así que nuestros 10000 bytes (a partir de 50000 en condiciones normales) deberían estar posicionados en la dirección 848 del banco (50000-49152).
- Length: 10000

3.- Comparar:
Abrimos una ventana de DOS (Inicio > Ejecutar, cmd) y vamos al directorio donde están los ficheros ram7.ref y ram7.tst. Ahí ejecutamos fc /b ram7.ref ram7.tst. A partir de aquí pueden pasar dos cosas:
- fc se vuelve loco a soltarnos líneas con diferencias. Algo hemos hecho mal y no es seguro ejecutar nuestro programa.
- fc suelta que no hay diferencias. Nuestro programa se ha cargado correctamente. Si no usamos el editor ni el disco, ya se han acabado nuestros problemas con la RAM7.

Notas:
- No comparo los 16384 bytes de la página completa ya que, según el uso que hayamos dado a nuestro +3 antes de cargar el programa, seguro que hay diferencias en las áreas que no hemos metido datos (y nos pueden despistar).
- Hay programas para comparar ficheros binarios, pero fc existe en todos los Windows y no nos interesa tanto saber cuáles son las diferencias como saber si hay alguna diferencia.