RANDOMIZE USR que no funciona en emuladores ni clones

[mcleod_ideafix]

Hace eones que "descubrí" un RANDOMIZE USE curioso. Es éste:
RANDOMIZE USR 46578

Si usando un genuino Spectrum 48K "gomas" o Plus (ningún otro), y justo después de haberle dado corriente, tecleamos este comando, aparece, al cabo de un segundo, esto:


El ordenador está como esperando una señal de carga de cassette (borde cambiante de cyan a rojo). Si pulsamos SPACE, ocurre esto:


Si se reinicia el ordenador pulsando RESET, o bien se usa un emulador, o bien se usa un Spectrum que no sea 48K/Plus, no ocurre este efecto al teclear el RAND USR.

Aún no he averiguado por qué ocurre esto. Un Spectrum 48K tiene casi toda la memoria RAM a 0. Concretamente, la posición 46578, las anteriores, y siguientes, están a 0 (instrucción NOP). Supuestamente, la CPU ejecutaría todos esos NOP's hasta llegar a la zona donde se encuentra la pila, y ejecutaría los bytes que allí hubiera como si fueran instrucciones. Dado que el contenido de la pila es el mismo de un arranque al siguiente, lo que hiciera el ordenador debería ser lo mismo, independientemente de que haya sido arrancado mediante quitar/poner enchufe o por RESET.

Para más inri, si pones RANDOMIZE USR 46577 o RANDOMIZE USR 46579, no ocurre tampoco este efecto.

¿Alguien se le ocurre qué puede estar pasando?

[antoniovillena]

Lo he probado en emulador poniendo un punto de ruptura y la pila apunta a $FF40. Todo lo que hay por encima y todo lo que hay por debajo que no sean 0 debe ser igual en todas las máquinas, por lo que la clave estará en dumpear ese intervalo de memoria.

Con el ZX Spin los bytes distintos a 0 empiezan en $FF18. Por lo que te recomiendo examinar desde $FF00 hasta $FF40. Desgraciadamente no te valdría un programa BASIC porque te cambiaría los valores. Tampoco te valdría hacer un CLEAR antes ya que la propia instrucción CLEAR también afectaría. Lo único que se me ocurre es poner un analizador lógico y observar lo que ocurre por el bus de expansión.

El que ocurran cosas distintas en distintas máquinas tiene su explicación en las interrupciones. La ULA genera interrupciones en un momento dado y pone el PC en la pila (que luego quitará pero quedará en memoria hasta que lo siguiente que metas en la pila lo machaque). Lo que haga la interrupción podrá meter valores en pila, pero lo mismo en todas las máquinas, excepto el PC (que depende del momento exacto en el que se genere la interrupción).

[zx81]

En JSpeccy siempre se visualiza el patrón que muestras en los pantallazos, salvo que como no genero "ruido" en la entrada EAR no ves cambios de borde azul/rojo, pero si pulsas SPACE sí se ve el borde como lo muestras. Como no hay diferencias de emulación entre el 48k y el Spectrum+, aunque hagas un Reset (F5 resetea la emulación, aunque no pone valores aleatorios en la RAM como sí hace la opción de "Reseteo total...") el efecto se produce siempre.

En los emuladores hay algo que *puede* estar sucediendo y que tienes que tener en cuenta y es que suelen hacer cosas raras con la detección de rutinas de carga basadas en la ejecución repetida de la instrucción IN. He probado ha desactivar ese tipo de detecciones en la última versión de FUSE y en Specemu pero no ha servido de mucho. JSpeccy no hace ese tipo de detecciones, por eso supongo que el problema anda por ahí (mucha casualidad es que los otros emuladores que he probado, el QAOP y el Specemu, produzcan exactamente el mismo efecto que FUSE cuando sus códigos fuentes no tiene nada en común). Para mi que el fallo de los emus es que se meten en las rutinas de detección de tonos sin siquiera comprobar si hay una cinta virtual insertada, aunque a JSpeccy le es indiferente si hay una cinta cargada o no en el emulador.

Creo recordar que el Specemu de Mark Woodmass permite grabar en disco un fichero con la lista de instrucciones ejecutadas, pero tampoco es capaz de "emular" ese efecto que has encontrado.

[mcleod_ideafix]

En JSpeccy siempre se visualiza el patrón que muestras en los pantallazos, salvo que como no genero "ruido" en la entrada EAR no ves cambios de borde azul/rojo, pero si pulsas SPACE sí se ve el borde como lo muestras. Como no hay diferencias de emulación entre el 48k y el Spectrum+, aunque hagas un Reset (F5 resetea la emulación, aunque no pone valores aleatorios en la RAM como sí hace la opción de "Reseteo total...") el efecto se produce siempre.

En WOS me han dado la pista de lo que es: por lo visto, casi todos los emuladores, cuando se resetea el micro, ponen todos los registros a 0, mientras que el Z80 original los pone todos a FF (excepto el PC, claro está). He hecho la prueba con Spectaculator de poner un punto de ruptura en $0000, hacer un reset, y al saltar el punto de ruptura, poner manualmente todos los registros a $FFFF excepto el PC. Los flags los he puesto todos a 1. Al quitar el punto de ruptura y hacer el arranque normal, he puesto el RAND USR y ¡ha funcionado!

Así que imagino que en JSpeccy la CPU emulada pone sus registros a $FFFF al resetearse

Lo que no entiendo es por qué al pulsar el botón de reset no se repite el comportamiento en un Spectrum original...

[antoniovillena]

Lee el punto 2.4 de este documento.

http://www.z80.info/zip/z80-documented.pdf

Dice que después de un reset AF=SP=$FFFF y IFF1=IFF2=PC=$0000, el resto de registros es indefinido. Aconsejan poner el resto de registros a $FF en emuladores (y poner IM a 0), pero no esto quiere decir que se fuerce ese valor tras un reset.

Por lo que probablemente al encender valgan $ff los registros indefinidos pero al pulsar reset mantengan dicho valor. La prueba definitiva sería hacer un programa en ASM que ponga todos los registros a $FF, luego ejecutas un DI y un HALT, reseteas y ves lo que pasa. Apuesto a que verás la pantalla mágica.

[antoniovillena]

De todas formas la clave está en los bytes basura de la pila, desde $FF18 hasta $FF40, cuyo valor es distinto en el momento de ejecutar RAND USR 46578 en función del valor de los registros tras el reset. Si depuras un poco verás que salta a la rom donde se ejecuta un LDDR que pinta la basura en la pantalla y luego salta a otra zona donde se ve el pitido y el cambio de borde.

[mcleod_ideafix]

La prueba definitiva sería hacer un programa en ASM que ponga todos los registros a $FF, luego ejecutas un DI y un HALT, reseteas y ves lo que pasa. Apuesto a que verás la pantalla mágica.

Algo parecido he hecho...
http://www.worldofspectrum.org/forums/s ... post539714

[zx81]

Anoche ya vi la contestación donde decían que Mark Woodmass (¿acaso podía ser otro?) había encontrado lo de los registros. Ciertamente, el core Z80 de JSpeccy pone en los registros lo recomendado por Sean Young en su "Undocumented Z80". Ahora ya sabemos que ese documento tiene al menos dos errores.

Siguiendo el hilo que has creado en WoS, veo que describes lo que queda en los registros cuando pulsas el botón de reset. Parece claro que IX e IY mantienen sus valores tras un reset pero, ¿IY *siempre* queda a #FFBF en el momento de darle alimentación y SP siempre vale #8005?.

Vaya curro te estás pegando, colega....

Edito para añadir que anoche modifiqué el emulador para que tenga en cuenta si se ha producido un RESET "de patilla" y, de ser así, en lugar de poner los registros a #FF los pongo a cero. Probando tu ROM en el emulador veo lo que es de esperar, excepto porque los registros AF y AF' nunca tienen #FFFF o #0000, siempre sale algo distinto. Juraría que el primer "POP AF" que haces en el programa se carga los contenidos originales de esos registros, pero puede que tenga algún error en mi emu, que es lo más probable...

[mcleod_ideafix]

Juraría que el primer "POP AF" que haces en el programa se carga los contenidos originales de esos registros, pero puede que tenga algún error en mi emu, que es lo más probable...

No, no, es un puñetero error mío. Eso debería ser un PUSH AF. Se me fue la neurona en ese momento. Sorry

[zx81]

Juraría que el primer "POP AF" que haces en el programa se carga los contenidos originales de esos registros, pero puede que tenga algún error en mi emu, que es lo más probable...

No, no, es un puñetero error mío. Eso debería ser un PUSH AF. Se me fue la neurona en ese momento. Sorry

No pongas esa cara hombre, que un error lo tienen hasta los genios. Después del curro que te estás pegando con este tema, te puedes permitir el lujo de cometer un error o incluso dos, como si fueras una persona normal.

Mirando el código de la ROM de prueba, que creo que se ensambla con PASMO (¿estoy en lo cierto?), le faltaría al pack el fichero "chars.bin". Supongo que no es más que el volcado del juego de caracteres de la ROM original, pero si lo añades mejor que mejor. Vamos, solo es una sugerencia...

[mcleod_ideafix]

Mirando el código de la ROM de prueba, que creo que se ensambla con PASMO (¿estoy en lo cierto?), le faltaría al pack el fichero "chars.bin". Supongo que no es más que el volcado del juego de caracteres de la ROM original, pero si lo añades mejor que mejor. Vamos, solo es una sugerencia...

Sí, se ensambla con PASMO (opción -bin) y sí, el fichero "chars.bin" no es ni más ni menos que los últimos 768 bytes de la ROM estándar, donde está el juego de caracteres.

[zx81]

Gran trabajo, mcleod. Para mi emulador, creo que me voy a quedar con el comportamiento del modelo Zilog Z8400APS. Z80A CPU., salvo porque el valor del registro SP no queda muy claro en un cold reset. De momento, lo pondré a 0 en un cold reset y lo preservaré en un warm reset, como el resto de registros generales.

Poner SP a cero tendría cierto sentido debido a que el registro apunta al último valor introducido (PUSH primero decrementa SP y luego escribe). Eso haría que el primer valor introducido en la pila estuviera en las direcciones 0xFFFE-0xFFFF.

Lo que llevo dos días preguntándome es cómo diablos se te ocurrió probar, precisamente, el RANDOMIZE USR 46578...

[mcleod_ideafix]

Gran trabajo, mcleod. Para mi emulador, creo que me voy a quedar con el comportamiento del modelo Zilog Z8400APS. Z80A CPU., salvo porque el valor del registro SP no queda muy claro en un cold reset. De momento, lo pondré a 0 en un cold reset y lo preservaré en un warm reset, como el resto de registros generales.

Mi sospecha es que un reset limpio dejaría a todos los registros excepto IR y PC, con el valor que tuvieran antes. Si no se ve así siempre es porque (y esta es mi sospecha) el reset que yo doy es "patatero" con multitud de rebotes, lo que significa que la CPU se resetea en realidad varias veces, y entre reset y reset le da tiempo a ejecutar las suficientes instrucciones como para que los registros ya no tengan el valor "marca" que le pongo al final del programa.

Poner SP a cero tendría cierto sentido debido a que el registro apunta al último valor introducido (PUSH primero decrementa SP y luego escribe). Eso haría que el primer valor introducido en la pila estuviera en las direcciones 0xFFFE-0xFFFF.

En alguna de las capturas se ve cómo SP de hecho contiene BBBBh. Si mi sospecha es cierta, también explicaría el por qué veo casi casi siempre que vale 7FFFh (el valor que obtiene tras unas cuántas instrucciones de ejecución)

Lo que llevo dos días preguntándome es cómo diablos se te ocurrió probar, precisamente, el RANDOMIZE USR 46578...

Eso fue en mi época ochentera de Spectrumiano. En alguna parte había leído sobre el famoso RANDOMIZE USR 5050 para resetear el micro con colorines, y comencé a probar con RANDOMIZE 12345, 23456, y chorradas así. En una de ellas se ve que "lié" los dedos y en lugar de poner 45678 puse 46578.

[chernandezba]

Leyendo posts antiguos me he encontrado con éste y con el tema de los registros que arrancan con valor aleatorio (idealmente 255) en la cpu...

Bueno esto lo he emulado ahora también en mi emulador ZEsarUX y se comporta igual que las imágenes

Saludos
César