mcleod_ideafix escribió:zx81 escribió:Varios. El z80full de Patrik Rak para comprobar la implementación del Z80. Fallan 52 tests, aunque podrían repetirse comprobando por ejemplo las instrucciones sin tener en cuenta el registro WZ (llamado memptr por otros), ni el comportamiento de los bits 3/5 en una instrucción SCF/CCF, por ejemplo. En general, no diría que algo me ha fallado por culpa del Z80 (me queda la duda del Taipan 128k, pero al respecto de eso no has comentado nada).
Como dije, el core de Z80 que tenemos es el que tenemos. A diferencia de lo que suele ocurrir en emulación, en donde cada autor se curra su propio core de Z80, en hardware casi todo el mundo usa el mismo core, el T80 de OpenCores, que funciona "de aquella manera". Hay otro, mucho más exacto, que uso en el core de Amstrad CPC, el az80 de Goran Devic, pero es un core poco optimizado para FPGA, que ocupa mucho más que el T80 y encima es más lento.
Ya imagino que sintetizar una CPU en VHDL no es fácil. Lo de que el core az80 sea más lento no lo entiendo muy bien. Supongo que te referirás a que tiene mayores retardos de propagación o algo similar. Lo poco que he visto de VHDL muestra que, a diferencia de un programa SW, muchas cosas se "ejecutan" en paralelo. Pero claro, si pasas por muchas puertas y tienes mucho retraso, al final tampoco ganas nada.
¿No has llegado a probar a ver qué pasa poniendo el az80 junto con lo básico para tener un 48k, para empezar?. Si cabe un CPC...
Y yo, si hay que prescindir de "delicatessen" como el ULA+ o el DivMMC, con tal de tener un 48k que se cagues las patas p'abajo, me sacrifico.
mcleod_ideafix escribió:zx81 escribió:El Fusetest que va con el emulador Fuse. Además de fallar en algunas instrucciones del Z80, falla en floating bus. De este mismo emulador, el Frame.tap, que da una diferencia en el cálculo de frames.
Ok. Lo veo, pero... ¿cómo debo interpretar que el test ha fallado? Veo que dice ""failed", pero no sé cómo interpretar ese fallo ni en qué me ayuda.
Para eso ayuda más el floatspy o el ulatest3-modified que te dice lo que va encontrando. Los test de Fuse solo dicen que algo ha fallado, pero no qué.
mcleod_ideafix escribió:zx81 escribió:El ulatest3-modified, que es un programa de Jan Bobrowski, el autor de 'qaop' y modificado por Chris Smith, de hecho me parece que me lo bajé de su web. Se ve claramente como las contenciones están desplazadas.
Curioso que el ulatest original de JB sí que me sale igual que en el QAOP/JS
Yo uso el -modified porque sale en colorillos y queda más claro qué tipo de contención tiene. La verdad es que no he probado ese emulador, debe ser que le tengo la misma manía al JodeScript que le tienes tú a Java. Pero ya hace años que Jan hizo un emulador de 48k que iba bastante bien. Aunque hace mucho que no lo uso, me extrañaría que no pasara ese test. Yo suelo comparar con Fuse, que es el que tengo más a mano.
mcleod_ideafix escribió:zx81 escribió:También de Jan, el btime.tap, que muestra como el primer byte de pantalla se pinta en el t-state 14335 y no en el 14336 como correspondería a un 'early-timing'
Acabo de probarlo y comienza la escritura en 14336. Si pulso A, la linea se desplaza 8 pixeles a la izquierda. El comportamiento lo veo idéntico al emu QAOP/JS.
De hecho, de esta página:
http://wizard.ae.krakow.pl/~jb/qaop/tests.html
Me funcionan (funciona = sale lo mismo que en el QAOP/JS) los siguientes tests:
btime
stime
ulatest3
minfo
contention
iocontention
zexbit
timingtest
No he probado:
keyboard
Fallan:
fusetest
z80tests (sobre todo el segundo.... está claro que el T80 no implementa, o lo hace mal, el registro WZ)
Timing Tests de Richard Butler
Desde luego, si intento (sería la cuarta vez) escribir un core Z80 desde cero, estos tests tendré que trillármelos a base de bien, pero mientras tanto, me temo que uso el T80 como si fuera (casi) una caja negra. El código está en VHDL, que no domino (yo uso Verilog), pero lo peor es que no está nada documentado, ni unos comentarios, ni ná.
Lo acabo de recomprobar y no, el QAOP/JS lo hace bien, el ZX-Uno no, al menos con el FW 0.64, core T24 que tengo yo. Cuando el btime arranca, "parece" que sale bien. Pero si pulsas 'a' y vas al estado 14335, la línea roja debería desplazarse hacia atrás el equivalente a 8 pixels. Y si vas con 'q' hacia adelante, la linea roja salta 8 pixels hacia adelante en 14339 y debería hacerlo en 14340.
mcleod_ideafix escribió:zx81 escribió:La "demo" BorderTrix de Andrew Owen (llamarlo demo es muy exagerado, creo yo, llamémoslo prueba de concepto), no muestra una imagen fija, sino saltarina en los bordes superior e inferior.
Esa demo también me funciona bien. ¿Qué versión del core tienes?
Confirmo, la T24-04022017.
mcleod_ideafix escribió:zx81 escribió:Si el 128k tiene contención en las páginas 1,3,5 y 7 es ahí donde la pongo.
Aunque el programa no falle, sí se nota. Pongamos un ejemplo: el infame e injugable por estar completamente roto, "Tarzán" de Martech. Lo único bueno del programa es la melodía del principio y esa melodía tiene la peculiaridad de escucharse como se compuso en el 128k/+2 y acelerada como un Neng en el +2a/+3. Si no recuerdo mal, los datos de la melodía están guardados en una página de memoria en contienda en el 128k, pero en una sin ella en el +2a. La verdad es que no recuerdo bien los detalles, pero por ahí iba el asunto. Otro programa afectado es el Cabal 128k, que se suponer que no funciona en el 128k, solo en el +2a por un problema similar. Otro programa afectado es el Robocop 3 que, no es que no funcione (en teoría NO funciona por poner el registro I donde no debe estar, pero yo lo he cargado en un +2 y no se ha reseteado). Cuando lo cargas en un +2a todo se ve OK. Pero si lo cargas en un 128k/+2 y te pones a ver la demo del principio, sin jugar, aparece la primera fase con los edificios. Fíjate entonces en el scroll de los mismos y verás como en la parte de la base de los edificios el scroll se desincroniza y se ven partidos, efecto que no sucede en el +2a. Eso no rompe el juego, pero para mi gusto y opinión no hace lo que hace el real.
Estos juegos que me dices..... tienen esos glitches porque esperan contención en esas páginas entonces?
Sí, en juegos como Robocop 3 o Tarzán es claramente porque la contención cambia de las páginas 1,3,5,7 en el 128k a 4,5,6,7 en el +2a. Eso suponiendo que sea fácil también en la reproducción del +2a hacer que los accesos a la I/O no tengan contención.
mcleod_ideafix escribió:zx81 escribió:Esto es un poco más lioso de explicar pero si me aclaras un par de puntos yo también sabré algo más. Si no me equivoco, a diferencia del Spectrum el ZX-Uno genera una imagen con todas las bendiciones del estándar PAL. Y eso... es un problema. Los timings del Spectrum van intrínsecamente unidos a una imagen fuera del estándar, por desgracia.
Y de hecho, así es en el ZX-UNO. La única cosa que he hecho es dar la opción a que el pulso de sincronismo vertical pueda ser, o bien un pulso, como en el original, o bien una señal "serrada" como dice la norma. Con la opción de sincronismo vertical "serrado", es PAL progresiva "legal", pero siempre siguen siendo (con la ULA de 48K), frames independientes de 312 lineas cada uno (311 en el 128K y 320 cuando funciona como Pentagon).
De hecho la opción por defecto sigue siendo el pulso de sincronismo vertical único, como en la ULA original. Aún no hay opción en la BIOS para cambiar este setting.
Lo "alegal" o "paralegal" no es que la señal de sincronismo tenga una forma u otra. El asunto es que el refresco de un 48k son 50.08 Hz, no los 50 que prescribe el estándar. Y la imagen debe ser interlazada, no progresiva. El asunto es que si muestras 50 cuadros por segundo de 69888 t-estados cada uno, eso hacen 3.494.400 Hz de CPU y no los 3.500.000 del original. Cada 625 cuadros (¿casualidad?) pierdes uno entero, aproximadamente cada 12'5 segundos.
El otro día estábamos haciendo pruebas comparativas de sonido, entre lo generado por un Spectrum + y por el ZX-Uno, y poniendo en un canal de audio el Spectrum+ y en el otro el ZX-Uno, buscando un punto de sincronismo es evidente que el sonido se desincroniza rápidamente.
El asunto es una putada porque, si haces un emulador que funcione exactamente al ritmo del Spectrum real y lo ves en una pantalla a 576i - 50 Hz, se ve genial con la pega de que ves subir la línea de retrazo. Y a ver cómo le dices a una TV moderna por HDMI que quieres una resolución de 50.08 Hz (el caso es que si conectas el Spectrum real se ve a esa frecuencia, aunque sea de pena).
Para alguien novato en esto del ZX-Uno, ¿es seguro poner el core EXP25v4 sin tener que salir corriendo al chapista?. Que luego no quiero tener que andar operando al ZX-Uno conectándolo vía real a una PI para sacarlo del coma etílico...
P.D.: Edito para decir que me he tirao al toro y al torero, he actualizado el core al EXP25v4 y con eso el BTIME de Jan ya sale en su sitio.
