Comprobador corrección de la emulación

[zx81]

Hola a todos,

Hace tiempo que me lleva rondando la idea de hacerle algunas cosillas a un emulador español al que nadie hace mucho caso pero que creo que tiene una gran calidad. Se trata del JaS, de Alberto Sánchez Terren, hospedado en este mismo dominio.

La cuestión es que hace ya tiempo que recuerdo haber detectado que alguna instrucción no estaba bien implementada. Creo que era la instrucción CP, pero no estoy seguro ahora. El caso es saber si hay algún TAP o similar que compruebe las instrucciones de un emulador y nos diga si hay algo que no esté correctamente implementado. Hacer eso a mano es una tarea de chinos, proclamo.

Algo debe haber porque la extensión de Viaje al Centro de la Tierra no consigo que funcione en JaS.

A ver qué me podeis recomendar y ójala ande por aquí Alberto, me gustaría saber que opina acerca de que alguien toque su código. No quiero molestar a nadie, y el código fuente muestra el (c), sin licencia GPL ninguna.

[Metalbrain]

Puedes probar con esto:
http://www.mdfs.net/Software/Z80/Exerciser/Spectrum/

o con los tests de Fuse:
http://fuse-emulator.svn.sourceforge.ne ... /fusetest/

El primero sobre todo lidia con la emulación de los flags, y el segundo con las temporizaciones.

[Gandulf]

Viaje al centro de la tierra hace uso extensivo de la instrucciones no documentadas del Z80, prácticamente en todas las rutinas, pero me extrañaría que fuera eso, porque eso lo implementan todos.

Puede ser que no tenga bien implementado el registro R, que lo usa para hacer cosas mientras se espera por el retrazo vertical.

Si me dices cuando se te queda frito o lo que hace mal te puedo decir qué puede estar emulando mal dicho emulador.

[zx81]

Viaje al centro de la tierra hace uso extensivo de la instrucciones no documentadas del Z80, prácticamente en todas las rutinas, pero me extrañaría que fuera eso, porque eso lo implementan todos.

Puede ser que no tenga bien implementado el registro R, que lo usa para hacer cosas mientras se espera por el retrazo vertical.

Si me dices cuando se te queda frito o lo que hace mal te puedo decir qué puede estar emulando mal dicho emulador.

Algo pasa, y ya no sé a qué se debe, cuando le doy a la tecla para comenzar a jugar después de la carga. Se queda matarile... aparentemente, porque si le das a la barra espaciadora se queda toda la pantalla en negro y au revoir!.

En cualquier caso, le he pasado el test zexall de la página que me dijo Metalbrain y no pasa ni una sola de las comprobaciones. Estoy haciéndole un repaso extensivo al core Z80 que lleva y ya veremos si consigo algo. Lo que más temo es que, o mucho me equivoco, o no están todos los fuentes de las clases Java...

[na_th_an]

Eso no es problema, sólo tienes que decompilarlas. Usa Decafe o DJ Java Decompiler.

[zx81]

Viaje al centro de la tierra hace uso extensivo de la instrucciones no documentadas del Z80, prácticamente en todas las rutinas, pero me extrañaría que fuera eso, porque eso lo implementan todos.

Puede ser que no tenga bien implementado el registro R, que lo usa para hacer cosas mientras se espera por el retrazo vertical.

Por cierto, aclaro que aunque el emulador implementa las instrucciones indocumentadas, no trata los bits 3 y 5 del registro F.

Respecto al tratamiento del registro R, no puedo decir nada aún....

[Metalbrain]

Por cierto, aclaro que aunque el emulador implementa las instrucciones indocumentadas, no trata los bits 3 y 5 del registro F.

Ahí tienes la razón (o una de las razones) por la que falla el zexall.

[zx81]

Bueno, después de varios días de "heavy hacking", he implementado al core Z80 de JaS el manejo de los bits 3 y 5 del registro F y he conseguido que "pase" 66 de los 68 tests del ZEXALL (lo de que pasa lo pongo entre comillas porque dan OK los test que tienen que darlo y da el mismo fallo de CRC los que fallan por un problema del propio ZEXALL).

De momento, aún fallan dos, a ver si alguien se ha encontrado con problema similar. Diré para empezar, que superar todos los test del ZEXALL es complicadillo y conforme vas intentando seguir el último documento de características indocumentadas z80-documented-v0.91.pdf te vas encontrando con problemas nuevos.

Uno de los que fallan, y que por cierto es el único que también falla en el fuse 0.9.0, es el llamado
bit n,<b,c,d,e,h,l,(hl),a>... CRC:f554d742 expected:5e020e98.

Dado que el otro test de bit funciona sospecho que el problema reside en el manejo del registro oculto manejado por la instrucción BIT n,(HL), tal y como describe el undocumented-z80 mencionado antes. Creo hacer todo lo que dice ese documento pero sospecho que aún falta algo que quizá no esté descrito ahí.

El otro test que falla es el ld <bcdexya>,<bcdexya> que sospecho se puede deber a algún fallo que no he sido capaz de ver aún. Dado que pasa el test anterior, que es igual salvo porque en lugar de los XY maneja los HL, algo debe haber en esa parte. A ver si simplifico un poco más el core Z80 y reduzco posibilidades ( a decir verdad, le he metido un tute que ha dejado poco del núcleo original de Alberto).

Por cierto, a ver si es posible localizar a Alberto Sánchez o a alguno de sus tutores del PFC. Escribí un mail a la dirección indicada en la página Web del JaS el Jueves pasado que aún no me ha contestado...

Quisiera tener la conformidad del autor respecto a liberar versiones nuevas de su emulador antes de meter la pata, y en los fuentes del emulador no se especifica la licencia (o yo no he sido capaz de encontrarla).

[Metalbrain]

Bueno, después de varios días de "heavy hacking", he implementado al core Z80 de JaS el manejo de los bits 3 y 5 del registro F y he conseguido que "pase" 66 de los 68 tests del ZEXALL (lo de que pasa lo pongo entre comillas porque dan OK los test que tienen que darlo y da el mismo fallo de CRC los que fallan por un problema del propio ZEXALL).

¡Buen trabajo! ¿Funciona ya la versión extendida de Viaje al Centro de la Tierra?

De momento, aún fallan dos, a ver si alguien se ha encontrado con problema similar. Diré para empezar, que superar todos los test del ZEXALL es complicadillo y conforme vas intentando seguir el último documento de características indocumentadas z80-documented-v0.91.pdf te vas encontrando con problemas nuevos.

Uno de los que fallan, y que por cierto es el único que también falla en el fuse 0.9.0, es el llamado
bit n,<b,c,d,e,h,l,(hl),a>... CRC:f554d742 expected:5e020e98.

Dado que el otro test de bit funciona sospecho que el problema reside en el manejo del registro oculto manejado por la instrucción BIT n,(HL), tal y como describe el undocumented-z80 mencionado antes. Creo hacer todo lo que dice ese documento pero sospecho que aún falta algo que quizá no esté descrito ahí.

Que yo sepa el registro oculto no tiene nada que ver con ese test, te lo digo porque yo me estuve peleando con el código del gp2xpectrum hasta pasarlo todo, y no tuve que implementarlo.

[Gandulf]

Si necesitas un TAP para probar el emulador ponte en contacto conmigo, o si no tienes implementada la carga de cinta y prefieres que te pase dos .Z80 para probar tu emulador.

[zx81]

Si necesitas un TAP para probar el emulador ponte en contacto conmigo, o si no tienes implementada la carga de cinta y prefieres que te pase dos .Z80 para probar tu emulador.

Afortunadamente, el JaS soporta TZX. VACDT sigue sin funcionar, y sigue teniendo básicamente el mismo fallo, que ahora mismo no sé a qué achacar. Carga el primer menú, redefino las teclas a la manera "tradicional", le doy a jugar y juraría que se queda en espera de cargar algo, pero quizá un bug en el tratamiento de los TZX hace que la cinta no continue y no se pueda arrancar de nuevo.

Por otro lado decir que no sé aún si el registro R está bien implementado (¿como probarlo?) y que el JaS no tiene en cuenta para nada la contended memory. Desconozco hasta qué punto afecta eso al juego.

Pero podrías enviarme el TAP y los dos .z80 para probar el juego después de la carga, si me haces ese favor a:

jsanchez at todounix.homeip.net

Muchas gracias

[zx81]

Bueno, después de varios días de "heavy hacking", he implementado al core Z80 de JaS el manejo de los bits 3 y 5 del registro F y he conseguido que "pase" 66 de los 68 tests del ZEXALL (lo de que pasa lo pongo entre comillas porque dan OK los test que tienen que darlo y da el mismo fallo de CRC los que fallan por un problema del propio ZEXALL).

¡Buen trabajo! ¿Funciona ya la versión extendida de Viaje al Centro de la Tierra?

Desgraciadamente no.

De momento, aún fallan dos, a ver si alguien se ha encontrado con problema similar. Diré para empezar, que superar todos los test del ZEXALL es complicadillo y conforme vas intentando seguir el último documento de características indocumentadas z80-documented-v0.91.pdf te vas encontrando con problemas nuevos.

Uno de los que fallan, y que por cierto es el único que también falla en el fuse 0.9.0, es el llamado
bit n,<b,c,d,e,h,l,(hl),a>... CRC:f554d742 expected:5e020e98.

Dado que el otro test de bit funciona sospecho que el problema reside en el manejo del registro oculto manejado por la instrucción BIT n,(HL), tal y como describe el undocumented-z80 mencionado antes. Creo hacer todo lo que dice ese documento pero sospecho que aún falta algo que quizá no esté descrito ahí.

Que yo sepa el registro oculto no tiene nada que ver con ese test, te lo digo porque yo me estuve peleando con el código del gp2xpectrum hasta pasarlo todo, y no tuve que implementarlo.

Después de una limpieza de casi 1900 líneas de código, he conseguido que el test del ld <bcdexya>,<bcdexya> funcione, o sea, que ya son 67 test correctos.

Lo que me marea del problema de la instrucción bit es que me da un CRC que no coincide ni con el ZEXALL en el Spectrum original, ni con el CRC que da el fuse 0.9.0......

[Gandulf]

OK, e voy a enviar dos Z80 para descartar la gestión de cinta, y tb un TAP para que no vayan los bloques de control de parada de cinta, que puede que no los tenga implementados. ¿Tiene AutoPlay este emulador? Es posible que tengas que activar mediante alguna tecla/opción la cinta para que empieze a cargar.

En cuanto al registro R, su tratamiento es fundamental en estas dos fases, si los Z80 no te funcionan (o si quieres verificar si lo hace bien) verifica que el registro R varía correctamente, es decir, respetando el BIT 7. Y que la instrucción ld r, a actualiza ese bit 7. También es muy importante que el flag "p" esté correctamente implementado.

EDITADO: Acabo de releer los síntomas que me dices y sin lugar a dudas el problema está en la gestión de la cinta. O no tienes el AutoPlay activo y lo tienes que hacer de forma manual (bien porque no lo tiene implementado bien porque esté desactivado) o no gestiona correctamente los TZX. Pero me inclino por lo primero.

[zx81]

EDITADO: Acabo de releer los síntomas que me dices y sin lugar a dudas el problema está en la gestión de la cinta. O no tienes el AutoPlay activo y lo tienes que hacer de forma manual (bien porque no lo tiene implementado bien porque esté desactivado) o no gestiona correctamente los TZX. Pero me inclino por lo primero.

Yo también me inclino en principio por un problema en la gestión de la cinta, porque se para justo antes del bloque 8 y luego no arranca ni aunque le des a play. Utilizas una rutina propia de carga, ¿verdad?.

[zx81]

Menos mal que ya vuelve a estar en línea el foro....

Definitivamente es un problema de la gestión de cinta. Ocurre que tal y como está el emulador, te lo pierdes todo. Alberto tuvo la habitual pero mala costumbre de capturar todas las excepciones de Java a nivel Exception y pase lo que pase, continua como si tal cosa.

En cuanto quitas los comentarios a los ex.printStackTrace se monta un festival de excepciones en el acceso a cinta que da gusto. Así que para probar el VACDLT voy a necesitar el TAP o, casi seguro, el snapshot.

Por cierto, una cosa a tener en cuenta, el core Z80 ya pasa todos los test. Ocurre que el documento que he mencionado antes no es correcto en cuanto al tratamiento de los bits 3 y 5 de F en la instrucción BIT n,r. Esos bits son copia de los bits correspondientes del valor del registro a comprobar, sin tener en cuenta ni el bit a comprobar, ni si está a 1 o a 0. Simplemente son copia. Con solo eso el resultado en el nuevo core es exactamente el mismo que en un Spectrum real.

Ahora bien, el resto de curiosidades respecto al registro oculto y las instruciones BIT n,(HL) y BIT (IX/IY+n) son ciertas.