JSpeccy v0.90

[zx81]

Pues el archivo "cannon_bubble.TZX" que tengo aquí produce ese problema, si me dices una dirección de email te lo envío (al principio creí que era un tema del archivo, que no fuera una versión correcta o estuviera mal, porque en su día estuve en CEZ y a lo mejor era una versión "no final", pero si lo cargo con spectaculator funciona perfectamente)

Lo estoy probando con Jspeccy v.090 (Build 21/05/2012)

A la que pone el diálogo de "Acerca de" del emulador, zx81 at ono dot com.

[zx81]

El Cannon Bubble de CEZ no funciona en JSpeccy. Se resetea en modo 128K clásico, +2 y +2A, en los tres, al finalizar la carga.

Creí que era cosa del TZX, pero en Spectaculator carga sin problemas. Es una carga turbo, no sé si tiene algo que ver. He probado a desactivar la aceleración de la carga desde cinta, a ver si es un problema del soporte con los .tzx

Editado: Igual, sin aceleración de la carga y esperando al llegar al final se resetea.

Misterio resuelto. La versión que tienes debe ser una pre-release cuyo TZX solo se diferencia del "oficial" en un byte de tamaño del archivo TZX. Al ejecutarlo en modo 128k/+2, se resetea y en la consola dice:

Incompatible program with 128k. Register I = 0x61. Reset!

Cosa que no sucede con el TZX de la versión oficial, así que imagina qué cambio tiene respecto al tuyo.

Lo que no debe sucederte es que se resetee en modo +2a. De hecho, la versión que me has enviado no se resetea y funciona perfectamente. Asegúrate, por favor, de que en modo +2a te funciona.

El problema es que ese valor para el registro I está prohibidísimo en modo 128k/+2. De hecho, al menos un par de juegos comerciales no funcionan en esos modelos por el mismo motivo que tu versión de CB, el Robocop 3 y el Narco Police. En Spectaculator funciona porque no tiene en cuenta ese detalle (el Fuse tampoco lo tiene en cuenta y los 3 programas funcionan en cualquier modelo de 128k).

Lo que voy a tener que inventarme es algo para sacar los mensajes de aviso de una forma más civilizada que imprimiendo en la consola, que los usuarios de Windows no usan nunca. Eso sí es un defecto de mi emulador....

[Gandulf]

Ah, ya sé lo que pasó con el tema del +2A, cuando reseteas (botón rojo) se cambia el modelo de spectrum al modelo por defecto, seguramente tras los reseteos del 128K y el +2, le dí al reset tras cambiar de modelo

Pues no sé si es una pre-release o si se actualizó por defecto, ha pasado mucho tiempo desde entonces

Muchas gracias por todo

[na_th_an]

Sin embargo (y que yo sepa), el único efecto que tiene tener I apuntando a los primeros 16Kb de RAM ($40 <= I < $80) es nieve (y bastante, dependiendo de varios factores), no resets. Esto ocurre en todos los modelos de Sinclair y en el +2 gris de Amstrad. Para el +3/+2A/+2B se corrigió el problema.

[zx81]

Sin embargo (y que yo sepa), el único efecto que tiene tener I apuntando a los primeros 16Kb de RAM ($40 <= I < $80) es nieve (y bastante, dependiendo de varios factores), no resets. Esto ocurre en todos los modelos de Sinclair y en el +2 gris de Amstrad. Para el +3/+2A/+2B se corrigió el problema.

La FAQ de CSS, en su Referencia del 128K dice:

The ULA bug which causes snow when I is set to point to contended memory still occurs, and also appears to crash the machine shortly after I is set to point to contended memory.

Yo solo puedo intentar reproducir el comportamiento documentado. Nunca he tenido un 128k/+2 y no puedo hacer pruebas que confirmen o desmientan la frase.

Otra cosa es decidir si se lleva a emulación hasta ese punto o no.

[Metalbrain]

La FAQ de CSS, en su Referencia del 128K dice:

The ULA bug which causes snow when I is set to point to contended memory still occurs, and also appears to crash the machine shortly after I is set to point to contended memory.

Yo solo puedo intentar reproducir el comportamiento documentado. Nunca he tenido un 128k/+2 y no puedo hacer pruebas que confirmen o desmientan la frase.

Otra cosa es decidir si se lleva a emulación hasta ese punto o no.

Hmm... ¿tal vez la clave esté en ese "shortly after", y para que se cuelgue tiene que estar un cierto tiempo mal paginado? El nuevo player de WYZ se diferencia del antiguo en que consume mucha menos memoria (tan solo 64 bytes en lugar de tener la canción entera preprocesada en un buffer), y debido a ello tarda un poquito más en procesar los datos (ya no es tan rápido como antes). Por lo tanto, es posible que al player viejo no le diera tiempo a colgarse, y al nuevo sí (aunque no sea inmediato, a lo mejor solo casca en las partes de la canción que más proceso consumen). Y la versión casi corregida del Maritrini tampoco petaba al activar los efectos de sonido, solo mostraba algo del efecto nieve.

[na_th_an]

Pues tiene todo el sentido del mundo, la verdad

El primer juego donde usé un player de WYZ fue Infinity en 2006. Maritrini lo terminamos de programar en Noviembre de 2011. Eso significa que llevo 5 años sacando juegos que funcionan DE PURA CHORRA

[zx81]

La FAQ de CSS, en su Referencia del 128K dice:

The ULA bug which causes snow when I is set to point to contended memory still occurs, and also appears to crash the machine shortly after I is set to point to contended memory.

Yo solo puedo intentar reproducir el comportamiento documentado. Nunca he tenido un 128k/+2 y no puedo hacer pruebas que confirmen o desmientan la frase.

Otra cosa es decidir si se lleva a emulación hasta ese punto o no.

Hmm... ¿tal vez la clave esté en ese "shortly after", y para que se cuelgue tiene que estar un cierto tiempo mal paginado? El nuevo player de WYZ se diferencia del antiguo en que consume mucha menos memoria (tan solo 64 bytes en lugar de tener la canción entera preprocesada en un buffer), y debido a ello tarda un poquito más en procesar los datos (ya no es tan rápido como antes). Por lo tanto, es posible que al player viejo no le diera tiempo a colgarse, y al nuevo sí (aunque no sea inmediato, a lo mejor solo casca en las partes de la canción que más proceso consumen). Y la versión casi corregida del Maritrini tampoco petaba al activar los efectos de sonido, solo mostraba algo del efecto nieve.

Es muy posible y, de hecho, creo que es lo más probable. JSpeccy comprueba al final de cada frame si las condiciones se cumplen y, de ser así, resetea. Pero si en medio del frame pones y quitas I, el emulador ni se entera.

Definir ese shortly after es complicado y nadie sabe lo que tarda realmente. Lo que sí es evidente que sabemos, gracias al Maritrini, es que el reset llega a producirse en la máquina real y, si lo haces muy corto, solo nieve. Quizá, y hablo por hablar, sea el tiempo que tarden las memorias dinámicas en perder el refresco y que dependa de donde tengas el código situado para que te toque antes o después.

Demasiados condicionantes y demasiado etéreos como para ser emulados racionalmente. Pero, ¿qué se hace entonces para que los desarrolladores de programas como Maritrini sepan que algo potencialmente peligroso está llevándose a cabo?. Creo que pocos tenemos hoy en día un 128k al alcance de la mano.

Se aceptan ideas y sugerencias. Este es el riesgo que corría por querer ser demasiado fiel (iba a decir más papista que el Papa) a la máquina real, cuando la maquina real es bastante más desconocida de lo que nos gustaría.

[na_th_an]

Ya te digo que al ser un tema puramente electrónico, que no lógico, es complicado de emular "bien". Lo que hablaron en WOS los super tacañones que más saben fue de dar una especie de "warning", en plan "se ha detectado tal y cual que en tal y cual modelo puede producir un cuelgue", o, simplemente, poder elegir si activamos o no este "crash" en el emulador, teniendo en cuenta que la mayoría de los usuarios serán jugadores y no programadores, con lo que, personalmente, lo pondría desactivado por defecto.

[zx81]

Como suele suceder, voy a tener que sacar una versión 0.90.1 para resolver algunas cosillas que han surgido o que me han sugerido y que son sencillas y rápidas de implementar.

Entre las que me han surgido, tengo que agradecer a Radastan que me descubriera la Palaractika demo, porque puedo decir sin mucho miedo a equivocarme, que es la demo más psicóticamente afinada en tiempo que he visto. Cuando todas las demos que he probado funcionan, la Paralactika aún presenta "defectos". Varios días llevo enfangado en lograr que funcione pixel-perfect. Sin lugar a dudas, cuando queráis probar la calidad de una emulación, esa demo es la auténtica prueba del algodón. Eso sí, como pasa con todo en esta vida, hay que saber donde mirar...

Lo otro que me gustaría aclarar creo que es posible consultarlo en este foro. Podría consultarlo en WoS pero, ya que mi emulador es español y aquí hay doctores de sobra, me parece suficiente con recabar opiniones de los contertulios habituales. Se trata de qué hacer finalmente con el tema del 128k/+2, el registro I y las páginas de RAM en contienda.

Las opciones posibles ahora, son:

1.- Dejarlo como está y que se resetee. Eso afecta a muchos juegos, además de los ya conocidos, al Renegade II y al Narco Police y eso solo son los que he encontrado yo que fallan. Aunque he probado muchos de los que tengo en casa, es imposible probarlos todos. Recordar que se desconocen todos los condicionantes para que el ordenador se resetee, solo sabemos que cuanto menos están implicados el registro I con valores entre 0xC0-0xFF y la página superior que haya paginada en ese momento. Esto solo se aplicaría al 128k, el +2 seguiría emulando un modelo "reparado".

2.- Avisar, pero no resetear. Los usuarios que arranquen el emulador desde un administrador de ficheros nunca verán el aviso, pero hasta que me invente algún tipo de log en una ventana aparte, es lo que hay.

3.- Pasar de todo como hacen el resto de emuladores y ¡viva la Pepa!.

Se aceptan sugerencias, consejos, opiniones y posibilidades alternativas.

Y, como es natural, me mojo por anticipado y afirmo que yo apostaría por la opción 1. La razón es que no es muy grave porque siempre podemos jugar con el modelo +2 (o sea, que no nos quedamos en bolas) e incluso, si lo llegamos a necesitar, si al +2 se le ponen las ROMS del 128k tendríamos un 128k reparado porque esa es la única diferencia entre un 128k y un +2 con fallo, la ROM. La ventaja es que la consecuencia es tremendamente cantarina, es imposible que se te pase por algo una cosa así, dado que no te deja continuar. Es un poco bruto el método, pero absolutamente efectivo.

Venga, ahora os toca a vosotros.

[na_th_an]

Yo apostaría por la 2, sinceramente, sobre todo habiendo juegos comerciales que se cuelgan en este emulador pero que funcionan en hardware real.

De todos modos, según mi conocimiento, el tema es el siguiente: es en el +2A negro donde no afecta esto. El 128 y el +2 gris, a nivel de hardware, son prácticamente idénticos. El fallo nada tiene que ver con la ROM, sino con la glue logic y el tema del bus flotante, que directamente están MAL (por fallos de diseño). No se solucionaría nada con lo que dices de las ROMs. El fallo se corrigió para el +3 y, por consiguiente, para el +2A, que no es más que un +3 con cinta.

[sromero]

Lo otro que me gustaría aclarar creo que es posible consultarlo en este foro. Podría consultarlo en WoS pero, ya que mi emulador es español y aquí hay doctores de sobra, me parece suficiente con recabar opiniones de los contertulios habituales. Se trata de qué hacer finalmente con el tema del 128k/+2, el registro I y las páginas de RAM en contienda.

Yo pondría un checkbox en las opciones generales del emulador, rollo:

[X] Emulación de reset cuando I=blah y X tiende a infinito

Por defecto, a "off", rollo "que los juegos funcionen".

Así nadie te podrá decir que no está bien implementado

[zx81]

Yo apostaría por la 2, sinceramente, sobre todo habiendo juegos comerciales que se cuelgan en este emulador pero que funcionan en hardware real.

De todos modos, según mi conocimiento, el tema es el siguiente: es en el +2A negro donde no afecta esto. El 128 y el +2 gris, a nivel de hardware, son prácticamente idénticos. El fallo nada tiene que ver con la ROM, sino con la glue logic y el tema del bus flotante, que directamente están MAL (por fallos de diseño). No se solucionaría nada con lo que dices de las ROMs. El fallo se corrigió para el +3 y, por consiguiente, para el +2A, que no es más que un +3 con cinta.

Creo que no me entendiste con lo de las ROMs. Me refería a que si al +2 le pones las ROMs del 128k, tienes un 128k arreglado porque esa es la única diferencia. O viceversa, que también es cierta, si al 128k le pones las ROMs del +2 tienes un +2 estropeado. No creo que haya ninguna situación que haga que necesites explícitamente un modelo concreto entre el 128k y el 2, pero lanzaba la idea por si acaso.

Me apunto la 2 por tu parte. Gracias por contestar.

[zx81]

Lo otro que me gustaría aclarar creo que es posible consultarlo en este foro. Podría consultarlo en WoS pero, ya que mi emulador es español y aquí hay doctores de sobra, me parece suficiente con recabar opiniones de los contertulios habituales. Se trata de qué hacer finalmente con el tema del 128k/+2, el registro I y las páginas de RAM en contienda.

Yo pondría un checkbox en las opciones generales del emulador, rollo:

[X] Emulación de reset cuando I=blah y X tiende a infinito

Por defecto, a "off", rollo "que los juegos funcionen".

Así nadie te podrá decir que no está bien implementado

Esa es la opción civilizada pero, si no la daba entre las posibles ahora, es por algo. Hacer eso bien requiere modificar la caja de diálogo de configuración, ver donde meto otro checkbox, añadirlo al fichero xsd a partir del que se genera el código de manejo del XML, y meter la lógica de uso en el programa.

Lo que pretendo ahora es meter un fix rápido para salir del paso. Por eso, siendo la que cuentas LA solución, ahora mismo no es la más rápida de implementar. Y realmente, tampoco sé si tiene sentido todo ese berenjenal dado que nada se sabe acerca de qué causa realmente el problema. Y si no se sabe nunca, complicado será que se pueda hacer una emulación sensata y con criterio de eso algún día.

Gracias por la opinión.

[na_th_an]

Yo apostaría por la 2, sinceramente, sobre todo habiendo juegos comerciales que se cuelgan en este emulador pero que funcionan en hardware real.

De todos modos, según mi conocimiento, el tema es el siguiente: es en el +2A negro donde no afecta esto. El 128 y el +2 gris, a nivel de hardware, son prácticamente idénticos. El fallo nada tiene que ver con la ROM, sino con la glue logic y el tema del bus flotante, que directamente están MAL (por fallos de diseño). No se solucionaría nada con lo que dices de las ROMs. El fallo se corrigió para el +3 y, por consiguiente, para el +2A, que no es más que un +3 con cinta.

Creo que no me entendiste con lo de las ROMs. Me refería a que si al +2 le pones las ROMs del 128k, tienes un 128k arreglado porque esa es la única diferencia. O viceversa, que también es cierta, si al 128k le pones las ROMs del +2 tienes un +2 estropeado. No creo que haya ninguna situación que haga que necesites explícitamente un modelo concreto entre el 128k y el 2, pero lanzaba la idea por si acaso.

Me apunto la 2 por tu parte. Gracias por contestar.

No, es que no es así El +2 y el 128 son idénticos por dentro, al menos en lo que respecta al bug. No es un bug de ROM. Es un bug de diseño de hardware (el bug está en la ULA). Cambiar las ROMs no debería solucionar nada. De hecho, hay un fix hardware para los 128 y los +2 para que no tengan nieve ni se cuelguen, y nada tiene que ver con la ROM

Además (que yo sepa) las ROMs del 128 y del +2 son prácticamente idénticas.