mcleod_ideafix escribió:zx81 escribió: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.
Vale, pero yo no. Y el ULAplus y el DivMMC molan demasiado como para dejarlos atrás
Fíjate que no digo de prescindir porque sí, sino solo si hace falta ese espacio para el nuevo core, que dices que ocupa más que el T80. Y, por mucho que nos jorobe, el ULA+ es una cosa mona, pero sin más. Yo también lo implementé en JSpeccy y, como los microdrives, pá ná. La mayoría de la gente quiere el emulador o el ZX-Uno para jugar al Match Day o algo similar. Y, encima, el ULA+ no funciona en un Spectrum de serie. No pasa de ser una curiosidad técnica.
mcleod_ideafix escribió:zx81 escribió: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.
Pues mira... comparando con JSpeccy 0.93.1 el ULAtest3 Modified hace exactamente lo mismo que hace el ZX-UNO.
Lo tengo ahora mismo delante y, vaya, no es lo mismo:
JSpeccy: 14337 FF FF 00 40 01 41 FF FF
ZX-Uno: 14337 FF 00 40 01 41 FF FF FF
y así todas las líneas (colorillos aparte).
mcleod_ideafix escribió:zx81 escribió: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 así es en ZX-UNO. El refresco es de 50.08 Hz, exactamente igual que el Spectrum original (cuando usas como opción de frecuencia la -f0 y la ULA de 48K, claro está)
Miel sobre hojuelas. ¿esto es así también en el core del +2?. ¿50.02 Hz?.
mcleod_ideafix escribió:zx81 escribió:Y la imagen debe ser interlazada, no progresiva.
Me temo que eso no es asi en el Spectrum. Para que una imagen PAL sea entrelazada necesita que cada campo sea de 312.5 lineas, no de 312. La señal que da el Spectrum es (salvando el tema del tipo de pulso de sincronismo vertical) PAL progresiva. De hecho, las señales de video progresivas eran lo más común en los circuitos de video de la época, y precisamente en un monitor CRT ese tipo de señales son las que provocan un efecto de scanlines más prominente que cuando la señal está entrelazada (al pintar los dos campos en el mismo sitio, la linea que dejan entre dos scans nunca se llena y por tanto aparece siempre negra).
Siempre he creído, por ignorancia, que la imagen PAL estándar era la interlazada, que lo de la imagen progresiva era muy moderno. Lo curioso es lo que puedo ver en mi otro emulador, ZXBaremulator. Si pongo la imagen de la PI a 576p@50, demos como la Paralaktika o la Mescaline, parpadean. Si pongo la imagen a 576i@50, se ve perfectamente estable, sin que yo haga trucos con la imagen, excepción hecha del "efecto retrazo" que se ve porque para mi sí es imposible conseguir una frecuencia diferente de las predefinidas en la TV (se pueden hacer perrerías, pero depende de cada TV o monitor, y no es trivial conseguir que funcione).
mcleod_ideafix escribió:zx81 escribió: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.
Tampoco conseguirás mantener un sincronismo si pones dos Spectrums originales, o dos ZX-UNOs. Se debe a la tolerancia de los cristales de cuarzo. No hay dos que den exactamente la misma frecuencia. La que aparece marcada en el cristal es la frecuencia nominal, pero puede variar en decenas de partes por millón, cosa que a lo largo del tiempo se va acumulando. Más aún cuando el ordenador se calienta.... y la ULA del Spectrum, responsable de la temporización, no es precisamente fresquita.
Otra ignorancia mía. Tenía asumido, erróneamente, que el error de los cristales de cuarzo es mínimo, menos de partes por millón. He tenido que hacer alguna concesión en ZXBaremulator con el tema de los tiempos de los 128k, y mi error anda en el orden del 2'7 por mil. Asumo que el error de los cuarzos anda dos o tres órdenes de magnitud por debajo de eso. Tampoco sé cuanto envejece un cuarzo, la verdad, ni los circuitos que lo rodean que seguramente llevan peor el paso del tiempo que el propio cuarzo.
mcleod_ideafix escribió:De hecho.... he estado probando algunos tests que uso con ZX-UNO en un Spectrum 48K original de Sinclair, con estos resultados:
- El test tmeter, que me dice cuántos estados de reloj tengo para los 4 segmentos de memoria, fluctúa para el segmento de la memoria contenida, y el segmento que comienza en C000. La fluctuación parece indicar que este Spectrum a veces se comporta como un early timing, y otras como un late timing, pero con cambios de varias veces por segundo incluso. En ZX-UNO da valores consistentes con un tarly timing.
- El test BorderTrix temblequea que da miedo, en ambos textos superior e inferior. Supongo que por la misma razón.
- El test de timings de 48K de Richard Butler da como 5 o 6 fallos. Ese test no da muchas explicaciones sobre por qué fallan los tests, así que no sé si es un problema de la CPU o de los timings. Supongo que es de lo último.
Vamos, que hasta un 48K con su ULA original y su Z80 original es menos exacto en timings que lo que los papeles dicen que debería ser.
Mira, acabas de sacar un tema que me parece interesantísimo de cara a la emulación o la replicación. He observado que la mayoría de la gente, incluido yo mismo, acabamos comparando los resultados ENTRE emuladores, y raramente contra la máquina original. Y eso produce efectos replicados que muchas veces no se corresponden con el original. Por ejemplo, en mi Spectrum+ Issue6A, el btime de Jan Bobrowsky se cuelga al decrementar el contador a 14335. Si voy para adelante no. Tengo dos versiones de ese test, y las dos se cuelgan. Hay un programa de los tests de Jan, el ptime, que intenta averiguar en qué momento exactamente se produce el cambio de página de memoria de vídeo, es decir, de sacarla de la página 5 a la 7 o viceversa. Se supone que Patrik Rak averiguó cuando se produce, aunque no me consta que lo dijera, y que lo implementó en ZXDS. Pues bien, probado en mi +2a, el comportamiento de ZXDS no coincide con la máquina real. Pero si no lo pruebas y te fías del ZXDS, replicas algo que no es correcto.
mcleod_ideafix escribió:Por cierto, y en aras de colaborar para que JSpeccy sea aún más exacto, querría que probaras esta demo técnica, Scroll17, para 128K. En el ZX-UNO y en ZesarUX funciona bien, pero en JSpeccy, versión 0.93.1 no se ve el banner por encima del fondo como debiera. Se ve bien cuando pasa por encima del borde, pero no se ve cuando pasa por encima del paper. Pista: comprueba cómo estás decodificando el puerto 7FFD cuando estás en un 128K o +2 gris, porque me da que lo estás decodificando como si estuvieras en un +2A
Pensé que era porque no estaba usando el OpenGL como recomiendas, pero incluso con el -Dsun.java2d....etc.... se ve mal (bueno, no es el único: el core TBBlue del Next tampoco hace esto bien). Ahora eso sí: si activo esa opción, dejo de ver el contenido de las opciones de configuración y el contenido de algunos cuadros de diálogo. El JAVA.... es lo que tiene
Arreglado. El problema era querer coger un atajo:
Código: Seleccionar todo
... 'if' que trata los puertos pares....
portFE = value;
// return;
}
if (spectrumModel.codeModel == MachineTypes.CodeModel.SPECTRUM128K) {
if ((port & 0x8002) == 0) {
Ese 'return' ahora comentado era el problema. Como el programa usa el mismo puerto para cambiar de página y el borde, una vez que cambiaba el borde salía del método y la parte del puerto 0x7ffd ya no se ejecutaba. Enhorabuena, hacía dos años lo menos que no encontraba un bug de ese tipo en la emulación. Lo que dudo ya es que ese atajo lo aplico en más sitios del método inPort y quizá todos debería quitarlos. A saber que otra cosa rara se le puede ocurrir a alguien. Y la otra duda es quien debería ejecutarse primero....
Por otro lado, el OpenGL lo recomiendo en Linux y, si no me equivoco, tú usas Windows. El tema solo afecta a X11 porque desde Java 8 utilizan la extensión XRender y eso nada tiene que ver con Windows. En mi máquina, que tiene una VGA NVidia con los drivers oficiales del fabricante, funciona bien. Pero en máquinas que no tienen un driver OpenGL nativo y usan Mesa (la implementación SW de OpenGL) hay problemas, o hay funciones no bien implementadas o entre Mesa y Java algo falla. Para ese caso, y repito esto solo es aplicable en Linux, se puede usar:
-Dsun.java2d.xrender=false
Lo que no llego a entender es porqué introdujeron ese problema en Java 8, con la primera versión, y han llegado a publicar Java 9 sin solucionar el problema, y eso que está catalogado como bug. Pero es que no lo han arreglado ni en la JVM oficial de Oracle, ni en la libre de OpenJDK.
Java es software y tiene lo que tiene el software, si con algo no se entiende bien, las cosas no rulan. Pero te aseguro que hace mucho que uso OpenGL desde Java de forma transparente y no tengo problemas. Quizá tengas, como tengo yo en un portátil, una VGA Intel i915 o similar y a saber qué soporta de OpenGL.