El arranque del Spectrum a cámara lenta

[Bubu]

¿Queréis ver el arranque del Spectrum a cámara lenta? Veréis, el otro día estaba en casa esperando a un montador de muebles (qué cosas), y me empecé a aburrir. Total, enchufé el Spectrum con el divIDE y me puse a buscar juegos. Vi uno que se llamaba 007-Disassembler. ¿ein? Lo ejecuté, y era lógicamente un desensamblador.
Total, que puse la dirección 0 a desensamblar, y empecé a ver las primeras líneas de la ROM que todos conocemos:

Código: Seleccionar todo

di
xor a
ld de, $ffff
etc

Como la espera parecía que se iba a hacer larga, seguí mirando ese desensamblado. Entonces, vi un ld (hl), 2 y que eso se repetía para toda la RAM, ¡¡ incluida la vídeo RAM !! Y todos sabemos que el 2 en la vídeo RAM son una serie de líneas verticales de color rojo.

¡¡ Ostras !! Había descubierto sin querer el por qué se ven líneas rojas verticales al arrancar el ordenador. ¡¡ Qué guay !!
Pues nada, hoy he copiado esa rutina a la RAM, y le he añadido unas pausas al bucle para ver cómo se va pintando lentamente, y el resultado es éste:

Código: Seleccionar todo

  org 60000
  xor a
  ld de, $5aff
  ld b, a
  ld a, 7
  out ($fe), a
  ld a, $3f
  ld i, a
  defb 0, 0, 0
  defb 0, 0, 0
  ld h, d
  ld l, e
RAM_FILL
  ld (hl), 2
  call PAUSA
  dec hl
  cp h
  jr nz, RAM_FILL
RAM_READ
  and a
  sbc hl, de
  add hl, de
  inc hl
  jr nc, RAM_DONE
  dec (hl)
  call PAUSA
  jr z, RAM_DONE
  dec (hl)
  call PAUSA
  jr z, RAM_READ
RAM_DONE
  ret
PAUSA
  ld bc, $100
  push af
MAS_PAUSA
  dec bc
  ld a, b
  or c
  jr nz, MAS_PAUSA
  pop af
  ret

Veréis cómo arranca el ordenador a cámara lenta. Al final, la pantalla que se forma es ésta:



que se vuelve a borrar, quedando la pantalla en negro y el borde en blanco. Posteriormente la pantalla se vuelve blanca y sale el mensaje de todos conocidos: (c) Sinclair Research Ltd. Esto del mensaje no lo tengo todavía preparado, pero caerá también.
Esta rutina es realmente un chequeo de la RAM. Se graba en toda la RAM el valor 2, luego se decrementa 2 veces dejando toda la RAM por tanto con valor 0.
Bueno, si queréis probar el arranque a cámara lenta, ensamblar el código anterior y ejecutarlo desde el BASIC con RANDOMIZE USR 60000

[Gandulf]

Una curiosidad muy buena, nunca he ojeado la rom del spectrum con detalle y creí sinceramente que esas líneas al inicio eran el estado inicial de la ULA al iniciarse, vamos que nunca le busqué un significado "por programa"

[zxbruno]

Gracias por esto.
Antes era costumbre tratar de asustar a los amigos con un simulador de reset, pero era dificil porque no se veian esas rayas rojas.

[sromero]

Es una cosa bastante curiosa que descubrí cuando empecé a programar ASpectrum (http://aspectrum.sourceforge.net).

Después de hacer el core de Z80 (bueno, una versión 99% funcional), y de ejecutar multiples programas escritos en ASM de Z80, cogí la ROM del Spectrum y la ejecuté con el core. Hice una primera versión del emulador con SDL que pintaba en pantalla el contenido de la videoram (sin muchas florituras), y ahí fue donde descubrí, con mi emulador en modo debug, y la ventanita de SDL, el porqué del color rojo

[mcleod_ideafix]

Otra cosa curiosa es por qué hace ese tipo de test para comprobar la memoria (llenarla con 2, decrementar todo el bloque, y después volver a decrementar) en lugar de llenarla con un valor (el que sea) y después comprobar que sigue ese valor en cada celdilla.

Pues resulta que este método que usa la ROM del Spectrum es muy ingenioso y permite descubrir un tipo de fallo que no se descubriría si se usara el típico bucle de relleno / comprobación. Es el fallo que se produce cuando una línea de dirección queda a un determinado valor siempre. Por ejemplo, porque falla alguna de las salidas del multiplexor 74158, o bien porque en alguna de las DRAM hay un fallo que pone una línea de direcciones a 1 o a 0 siempre. Esta situación se daba más de lo que uno piensa, sobre todo por tres decisiones de diseño del Spectrum: la posibilidad de usar chips de OKI o TI, el elegir chips de 64K "estropeados" para implementar los 32K superiores a base de usar sólo el banco no defectuoso, y el implementar la lógica de acceso RAS/CAS mediante multiplexores y retrasos, que el usuario tenía que incorporar al instalar la ampliación de 32K.

El fallo está en que a causa de una mala decodificación de la dirección de memoria, hay más de una dirección del Z80 que va a parar a la misma dirección de RAM. Por ejemplo, suponéos que cambiáis la memoria superior y ponéis 8 chips nuevos, peeeeeeeeero os olvidáis de cambiar los jumpers OKI/TI/3/4/L/H a la combinación adecuada: os podeis encontrar, como fue mi caso, con un Spectrum en el que la inicialización de la memoria dice que la máxima dirección de RAM física es la 49151 en lugar de la 65535. Sin embargo, si se pokea cualquier valor en 49152, un peek a esa misma dirección da el valor recién pokeado. Entonces... ¿cómo puede estar mal esa dirección?

La razón es que, en mi caso, A14 fallaba: en los 32K superiores hay dos multiplexores y uno de ellos es quien determine qué hacer con A14: este bit de direcciones puede aparecer al seleccionar la fila o la columna, en las DRAM. Eso se elige con los jumpers mencionados, y en función del tipo de memoria, A14 a veces pasa al bus de direcciones de las DRAM y a veces, queda a un valor fijo.

Puse mal los jumpers, y eso hacía que el valor de A14 entregado a las DRAM superiores fuera siempre el mismo, independientemente de que A14 fuera en el Z80 un 1 o un 0. Eso significaba que todas las direcciones superiores (de 32K para arriba), fueran del tipo 10xxxxxx xxxxxxxx en lugar de 1xxxxxxx xxxxxxxx.

Dicho de otra forma: cuando el procesador quería acceder, por ejemplo, a la posición de memoria 49152 (11000000 00000000), en la memoria, se accedía a la posición 32768 (10000000 00000000). O lo que es lo mismo: las posiciones de memoria de la 49152 hasta la 65535 en realidad eran una copia de las posiciones 32768 a 49151.

Un test de memoria que sea del tipo "relleno un bloque con un valor, y después compruebo que el valor sigue en cada posición del bloque", no detectará este fallo y concluirá, erróneamente, que la memoria está bien.

El test de la ROM del Spectrum en cambio sí lo detecta: comienza con un bucle de relleno, sí. Pero el bucle de comprobación, en lugar de leer simplemente lo que hay en memoria, lo que hace es modificarla y comprobar que la modificación produce el resultado esperado. Con una situación como la descrita anteriormente, habrá posiciones de memoria que se modificarán dos veces, y eso será detectado por la rutina. Por eso la ROM paraba al intentar modificar la posición 49152 y restarle 1. El resultado debería ser 1 (era 2 al principio), pero como en realidad la posición 49152 es la posición 32768, y esa fue decrementada en la primera vuelta del bucle, resulta que ahora se vuelve a decrementar y su valor final es 0, erróneo para la rutina de test, y por tanto dando por terminado ahí.

[zx81]

Un test de memoria que sea del tipo "relleno un bloque con un valor, y después compruebo que el valor sigue en cada posición del bloque", no detectará este fallo y concluirá, erróneamente, que la memoria está bien.

Probablemente, había cierta cantidad de fallos al montar los Spectrums, especialmente con el tipo de memorias que se montaran en cada momento. Así que el test de la ROM debía detectar ciertos tipos de fallos durante las pruebas de calidad.

Y como al principio existía el modelo de 16k ampliable, eso también servía para que los SAT lo tuvieran más fácil a la hora de comprobar las ampliaciones.

[Manu]

Otra cosa curiosa es por qué hace ese tipo de test para comprobar la memoria (llenarla con 2, decrementar todo el bloque, y después volver a decrementar) en lugar de llenarla con un valor (el que sea) y después comprobar que sigue ese valor en cada celdilla.

(...)

Con comentarios como este, da gusto leer a fondo este foro

[Bubu]

Bien, bien, bien, ya sabemos por qué se pone el borde blanco, la pantalla negra, y salen rayas finas verticales en rojo. Y ¿por qué antes de todo eso se ve la pantalla llena de colores aleatoriosn durante una décima de segundo? :



A mí se me ocurre que puede ser porque la RAM contiene bits aleatorios al arrancar, y cuando la ULA los lee, muestra esa zurrapa en pantalla, pero me gustaría que algún experto lo confirmase o comentase cómo va la historia.

[Manu]

Que yo sepa, eso es exactamente lo que pasa...

[carmeloco]

Buenas, se me ocurren 2 sencillos programas en basic para ver lo de las rayas rojas en pantalla y lo de los datos aleatorios en la memoria.

Para las rallas sería:

10 FOR n=16384 TO 23296
20 POKE n,2
30 IF n<23296 THEN NEXT n
40 GO TO 40

Para los datos aleatorios:

10 FOR n=16384 TO 23296
20 POKE n,INT (RND*256)
30 IF n<23296 THEN NEXT n
40 GO TO 40

La línea 40 es para que no se nos borren las 2 últimas líneas al acabar el programa y la 30 para evitar que se ejecute la 40 antes de llenar toda la memoria de video.

Ya sé que es una tontería, pero es que estoy de baja y me aburro en casa.

Un saludo, Carmeloco.

[na_th_an]

¿Y no bastaría con un NEXT n sin el IF y restando uno del límite superior del bucle?

[carmeloco]

Pues si, que tonteria mas grande lo del IF, pero fue la primera cosa que se me pasó por la cabeza, jejeje Creo que es por culpa de que cuando estudié electronica, programaba mucho una calculadora Casio programable que tenía y se tenían que usar mucho los condicionales, quizá por eso ahora los meto hasta en la sopa

¿Y lo de restar 1 para que? Funciona bien sin restar el 1, básicamente porque el < en el IF está mal puesto, ya que el valor máximo a escribir es el 23296

Los listados quedarían asi:

Para las rallas sería:

10 FOR n=16384 TO 23296
20 POKE n,2
30 NEXT n
40 GO TO 40

Para los datos aleatorios:

10 FOR n=16384 TO 23296
20 POKE n,INT (RND*256)
30 NEXT n
40 GO TO 40

Hay que ver los estragos que está haciendo el aburrimiento en mi, y lo oxidado que tengo el basic

[na_th_an]

Lo de restar 1 es porque la pantalla acaba en 23295, y estás escribiendo un byte mas

[carmeloco]

Cierto, se me fué la pinza. Cogí la primera dirección de la zona de video (16384) y le sumé el total de bytes que tiene una pantalla SCREEN$ (6912) para ver la dirección final, pero no tuve en cuentaque con eso, sale una de más. Vuelvo a pedir perdón una vez más...

P.D.: El resultado final por pantalla es el mismo, aunque grabe una dirección más.
P.D.2.: Mis listados en basic siguen siendo una tremenda tontería.

[na_th_an]

No creo que sean una tontería, símplemente es un modo de ver en cámara lenta qué hace el Speccy cuando arranca