Proposición ZXUno+

Dudas, cuestiones, sugerencias y peticiones en general sobre el proyecto / Questions and requests about the project
Avatar de Usuario
Uto
Mensajes: 1394
Registrado: 17 Dic 2015, 16:39

Re: Proposición ZXUno+

Mensaje por Uto » 23 Ene 2018, 18:25

zx81 escribió:
Uto escribió:También se ha dicho en algún sitio de este foro que poner un Z80 real limita la velocidad máxima, porque no hay Z80 reales a 28Mhz.
Como todo en esta vida, depende del objetivo que busques. El mío es tener un clon del Spectrum 48k (si lo tengo del 128k también, miel sobre hojuelas) que sea indistinguible del original en todos los sentidos posibles. Con 3'5 Mhz me bastan (3'5469 Mhz para el 128k).

En mis objetivos no están el CPC, el MSX, los Timex, el Sam Coupé, los modos ULA+, el DivMMC o el Space Invaders. Respeto a quien sí lo quiera, pero yo prefiero tener UN solo core que sea perfecto, a tener cuatro docenas a medias.

Esta es mi opinión. Si no le gusta, tengo otras... :)
Mi comentario era solo para apuntar a ese detalle, no pretendía decir que eso sea malo o bueno :-)

Tampoco tengo objetivos la verdad, si me pongo a pensar quizá tenga deseos, que probablemente vayan más por el tema de mejorar el CPC que mejorar el Spectrum, pero vamos, ya digo que son deseos, porque como de VHDL ni papa, no puedo tener objetivos :lol: . Bueno sí, podría tener el objetivo de crear un core de una maquina que haga un bip, y luego ya el core de una máquina que haga un bip cuando pulse una tecla. Creo que eso serían objetivos razonables para mi :lol:

Lo que está claro es que mcleod hará lo que pueda, y además lo que le de la gana, que para eso es su tiempo :-D

zx81
Mensajes: 56
Registrado: 08 Ene 2018, 16:55

Re: Proposición ZXUno+

Mensaje por zx81 » 23 Ene 2018, 18:42

Uto escribió:
zx81 escribió:
Uto escribió:También se ha dicho en algún sitio de este foro que poner un Z80 real limita la velocidad máxima, porque no hay Z80 reales a 28Mhz.
Como todo en esta vida, depende del objetivo que busques. El mío es tener un clon del Spectrum 48k (si lo tengo del 128k también, miel sobre hojuelas) que sea indistinguible del original en todos los sentidos posibles. Con 3'5 Mhz me bastan (3'5469 Mhz para el 128k).

En mis objetivos no están el CPC, el MSX, los Timex, el Sam Coupé, los modos ULA+, el DivMMC o el Space Invaders. Respeto a quien sí lo quiera, pero yo prefiero tener UN solo core que sea perfecto, a tener cuatro docenas a medias.

Esta es mi opinión. Si no le gusta, tengo otras... :)
Mi comentario era solo para apuntar a ese detalle, no pretendía decir que eso sea malo o bueno :-)

Tampoco tengo objetivos la verdad, si me pongo a pensar quizá tenga deseos, que probablemente vayan más por el tema de mejorar el CPC que mejorar el Spectrum, pero vamos, ya digo que son deseos, porque como de VHDL ni papa, no puedo tener objetivos :lol: . Bueno sí, podría tener el objetivo de crear un core de una maquina que haga un bip, y luego ya el core de una máquina que haga un bip cuando pulse una tecla. Creo que eso serían objetivos razonables para mi :lol:

Lo que está claro es que mcleod hará lo que pueda, y además lo que le de la gana, que para eso es su tiempo :-D
Bueno, en sí mismo, si para llegar a un objetivo concreto hay que cumplir penitencia, se cumple (ya me estoy leyendo un libro sobre VHDL). Estoy como tú, ni VHDL, ni electrónica, ni nada. Lo bueno de esto es que gracias a mcleod, Kyp, jepalza y tantos otros tenemos montones de ejemplos de los que partir. Y oye, si empiezas con el VHDL y consigues que "pulsando una tecla algo haga beeeep" ya es un montón de faena conseguida. A ver si encuentro el "VHDL for dummies". :D

Y no, esto no va de presionar a nadie. Es hablar por hablar. Lo difícil en estas cosas es conseguir pasar del "hay que" al "voy a". Los miembros del ZX-Uno ya cumplieron su parte con matrícula de honor y los que han ido añadiendo cores, también tienen su mérito. Pero sé por experiencia propia que llega un punto en que es más divertido liarse con otras cosas que seguir insistiendo machaconamente en el mismo clavo. A veces tienes que dejarlo una temporada para luego volver con ánimos renovados.

Pero, me temo, la única manera de tener un core de Spectrum cuasi-perfecto es ser un cansino histórico (me refiero a ponerse al tajo, no a dedicarse a escribir cartas a los reyes majos ni a quejarse de esto o de lo otro).

Cualquier día de estos, me lío la manta a la cabeza, instalo el ISEWebpack ese y me pongo a hacer el ridículo con el VHDL. Porque, voluntad la que quieras, pero con los conocimientos que tengo solo puedo hacer eso, el ridi....

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 24 Ene 2018, 02:52

zx81 escribió:¿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...
Aun no, porque que el az80 llegue a funcionar bien (wait incluido) es algo que se ha conseguido hace relativamente poco tiempo.
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. :D
Vale, pero yo no. Y el ULAplus y el DivMMC molan demasiado como para dejarlos atrás :)
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.
zx81 escribió: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.
Confirmo, la T24-04022017.
Actualiza ese core. ¡Tiene casi un año! Los avances que estoy haciendo los grabo en la versión EXP25. EDITO: ya veo que lo has hecho ;)
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á)
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).
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.

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.

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 :D
Adjuntos
scroll17.tap
(8.95 KiB) Descargado 234 veces
tmeter.TAP
(2.53 KiB) Descargado 226 veces
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 24 Ene 2018, 08:41

mcleod_ideafix escribió: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 ;)
Me respondo a mi mismo. Pues veo que no...

Código: Seleccionar todo

if (spectrumModel.codeModel == MachineTypes.CodeModel.SPECTRUM128K) {
  if ((port & 0x8002) == 0) {
En ese caso, entonces lo que entiendo que pasa es que JSpeccy no implementa el que se pueda conmutar la página de pantalla en cualquier momento. Las letras las pinta esa demo en la parte de paper a base de cambiar a toda velocidad (varias veces dentro de un scanline) de la pantalla normal a la shadow (que lo que tiene es una pantalla en blanco), pero el truco consiste en usar un puerto cuyo valor es tal que afecta tanto al puerto FE como al puerto 7FFD (dado que ambos se decodifican parcialmente).
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 24 Ene 2018, 15:05

mcleod_ideafix escribió:Por cierto, y en aras de colaborar para que JSpeccy sea aún más exacto...
Prueba también esto otro. Es un programa que escribí para gastar una broma, pero en JSpeccy parece que hace mucho más que impedir que NMI funcione: no puedo reiniciar el equipo, ni hacer un reinicio total... y hasta el mensaje que debería aparecer con FLASH, ¡aparece sin él!
Adjuntos
nonmi.tap
(235 Bytes) Descargado 234 veces
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

zx81
Mensajes: 56
Registrado: 08 Ene 2018, 16:55

Re: Proposición ZXUno+

Mensaje por zx81 » 24 Ene 2018, 16:53

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. :D
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 :D
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.

zx81
Mensajes: 56
Registrado: 08 Ene 2018, 16:55

Re: Proposición ZXUno+

Mensaje por zx81 » 24 Ene 2018, 17:00

mcleod_ideafix escribió:
mcleod_ideafix escribió:Por cierto, y en aras de colaborar para que JSpeccy sea aún más exacto...
Prueba también esto otro. Es un programa que escribí para gastar una broma, pero en JSpeccy parece que hace mucho más que impedir que NMI funcione: no puedo reiniciar el equipo, ni hacer un reinicio total... y hasta el mensaje que debería aparecer con FLASH, ¡aparece sin él!
Eso es una consecuencia de cómo está codificado el core Z80 y pasa eso porque petas el emulador con un error de Stack Overflow. Cuando elegí cómo tratar las secuencias no-muy-habituales de DD-FD-DD-FD-DD-FD lo más cómodo era llamar recursivamente al método decodeOpcode. Y claro, en una secuencia potencialmente quasi-infinita de DD-FD acabas desbordando la pila y leche que te crió. Era consciente de que eso podía pasar, pero es el primer programa que lo demuestra... :D

Si ejecutas el emulador desde un CMD.EXE, verás el log del error. Única solución, parar el emulador y volver a arrancarlo. Tendré que revisar eso, porque hay lugares más peligrosos que una máquina Java....

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 24 Ene 2018, 18:15

zx81 escribió: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).
Ops! Cierto! Fallo mio, al mirar solo los colorines y no el texto de los colorines :D
zx81 escribió:Miel sobre hojuelas. ¿esto es así también en el core del +2?. ¿50.02 Hz?.
En el ZX-UNO, la ULA del 128K genera 311 lineas, a 228 T-estados de CPU por linea. Lo que varía es la frecuencia de pixel, que no son 17.7345 / 2.5 = 7.0938 MHz (porque no puedo sintetizar esa frecuencia con el cristal que tengo), sino que tengo que partir de una frecuencia maestra de 28.448275862068965517241379310345 MHz . De ahí, la frecuencia de pixel (que es la cuarta parte) resulta ser de 7.1120689655172413793103448275862 MHz. Con esa frecuencia, el tiempo de exploración de una linea (456 ciclos de esa frecuencia) es de 64.11636363.... microsegundos, frente a los 64.2815 microsegundos que tarda en la máquina original.
Como se puede ver, los tiempos son diferentes, pero lo más curioso es que el tiempo que se tarda en el Spectrum 128K original está más alejado del tiempo nominal de 64 microsegundos que lo que se tarda en el ZX-UNO. Esta deriva de 281.5 nanosegundos en la máquina original es lo que hacía que algunas teles no tragaran bien con la señal del 128K, pero sí con la del Spectrum 48K.

En el Spectrum 128K original, el sincronismo vertical se produce cada 456*311 ciclos de reloj. Esto es, a una frecuencia de 7093800/(456*311) = 50.021154 Hz. En el ZX-UNO con ULA de 128K y opción de frecuencia -f1 (que es la del 128K) tienes: 7112068.9655172413793103448275862/(456*311) = 50.142 Hz .
Aparentemente, las teles perdonan más una deriva en la frecuencia vertical que en la frecuencia horizontal, o si no las teles, el codificador PAL integrado en ZX-UNO. Por esa razón se dejó esa frecuencia para el modo de 128K.

En realidad, que la máquina genere sincronismos verticales a 50 Hz, 50.08 Hz o lo que sea, es irrelevante. A efectos de mantener las temporizaciones, lo relevante es que la relación entre la frecuencia de la CPU y la frecuencia de pixel sea la misma, y que el número de ciclos de reloj por scan y frame se mantengan. Gracias a esa irrelevancia, ZX-UNO puede configurarse para adaptarse a un monitor VGA que necesite más de 50 Hz de frecuencia vertical para poder dar imagen, a base de acelerar todo el sistema (ULA, CPU, AY.... todo!). El efecto es, obviamente, que lo notas todo más o menos acelerado, pero al mantenerse la relación de timings en todo momento, los juegos, demos, y demás virguerías que dependan de ello, no se ven alterados. Es más: el programa no tiene "conciencia" de que está siendo ejecutado en una máquina ligeramente acelerada.
zx81 escribió:Siempre he creído, por ignorancia, que la imagen PAL estándar era la interlazada, que lo de la imagen progresiva era muy moderno
No sé si el PAL progresivo es más moderno que el entrelazado, o son coetáneos, pero sí es cierto que la señal PAL por excelencia es la entrelazada. Pero no es así como se implementó ni en el Spectrum ni en otros muchos micros.
zx81 escribió: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).
Esas demos parpadean como locas con un Spectrum original (o un ZX-UNO) conectado a una CRT. Conectado a una tele LCD, depende de que la tele acepte la señal progresiva del Spectrum y decida "desentrelazarla" por su cuenta. Vamos, que hay teles que venga lo que venga por la entrada de video, lo toman como entrelazado y lo convierten en progresivo, y otras teles que nanay. En el repositorio hay una demo llamada SLIDE512 o algo así, que aprovecha este desentrelazado inteligente que hacen algunas teles con la señal del Spectrum para renderizar una imagen de 512x384 pixeles reales. Uso el modo Timex HiRes que te da imágenes de 512x192 pixeles, y tengo dos de ellas en las páginas 5 y 7. En cada retrazo vertical las intercambio, y la tele hace el resto.
Como la señal del Spectrum no es entrelazada, el tren de pulsos que forma el sincronismo vertical no proporciona la información de si el campo que viene a continuación es el par o el impar. Esto significa que en las teles que desentrelazan "porque sí", hay un 50% de posibilidades de que las dos mitades de la imagen aparezcan en el orden correcto, y un 50% de que no. En el slideshow hay una tecla, la S, para cambiar el orden de los campos.
zx81 escribió: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.
Son varios factores: temperatura, tolerancia del cristal, envejecimiento del cristal (a fin de cuentas un cuarzo funciona porque realmente vibra, mecanicamente hablando, a esa frecuencia), envejecimiento de los semiconductores y condensadores que forman parte del oscilador, etc.

PD: enhorabuena por haber resuelto el pequeño bug del puerto 7FFD :)
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

zx81
Mensajes: 56
Registrado: 08 Ene 2018, 16:55

Re: Proposición ZXUno+

Mensaje por zx81 » 24 Ene 2018, 18:43

mcleod_ideafix escribió:
zx81 escribió:Miel sobre hojuelas. ¿esto es así también en el core del +2?. ¿50.02 Hz?.
En el Spectrum 128K original, el sincronismo vertical se produce cada 456*311 ciclos de reloj. Esto es, a una frecuencia de 7093800/(456*311) = 50.021154 Hz. En el ZX-UNO con ULA de 128K y opción de frecuencia -f1 (que es la del 128K) tienes: 7112068.9655172413793103448275862/(456*311) = 50.142 Hz .
Como decía el gran Alvaro de la Iglesia en una de sus novelas, mal de muchos, consuelo de tía Fuencisla. :D

Andaba yo jodido porque en ZXBaremulator había tenido que elevar la frecuencia de la CPU hasta los 3546996 Hz, 96 ciclos por segundo por encima del original teórico y tú has tenido que conformarte con 8568 ciclos más por segundo.

Mi problema es que, en la PI, no hay dificultad en programar un timer para que salte cada 19968 microsegundos que dura un frame del 48k. Pero el frame en el 128k dura 19991'541 usecs (con 3 millones de decimales más detrás). Por razones un poco rebuscadas, y atendiendo a que el timer solo es de 1 Mhz, the tenido que dejarlo en 19991 usecs. Qué puñetero es todo esto, joer... :D

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 24 Ene 2018, 19:12

zx81 escribió:Andaba yo jodido porque en ZXBaremulator había tenido que elevar la frecuencia de la CPU hasta los 3546996 Hz, 96 ciclos por segundo por encima del original teórico y tú has tenido que conformarte con 8568 ciclos más por segundo.
El Spectrum no conoce el tiempo real. Su unidad de medida del tiempo es "lo que dura un ciclo de reloj de la ULA". Llamemos a ese tiempo, U. Lo que valga U en nanosegundos es irrelevante, aunque obviamente tiene un valor nominal, que es 1000/7 nanosegundos en el 48K, y 2500/17.734475 nanosegundos en el 128K, pero si te alejas de estos valores, y siempre y cuando que la señal de TV resultante sea compatible con el aparato con que vas a usarla, no pasará nada malo (obviamente, tú vives en un mundo donde sí existe el tiempo real y notas si el Spectrum está acelerado o no). Lo relevante es que cualquier cosa que ocurra en el interior de las tripas del Spectrum ocurrirá en un periodo de tiempo que será un múltiplo entero del valor de U.

- Periodo de reloj de la CPU : 2*U
- Periodo de reloj del AY-3-8912 : 4*U.
- El tiempo que se tarda en pintar un scanline en pantalla (completo con sus sincronismos horizontales y todo) :
* 448*U en el 48K
* 456*U en el 128K
- El tiempo que se tarda en pintar un frame completo:
* 448*312*U en el 48K
* 456*311*U en el 128K
- Duración de una interrupción: 64*U
- Momento en el que se dispara la interrupción, medida desde el comienzo del frame:
* 248*448*U en el 48K
* 248*456*U en el 128K

Y así con cualquier otro evento que ocurra en el interior de la máquina.

Ah! Se me olvidaba una cosa respecto al A-Z80. Hay una razón de peso por la cual no puedo usarlo en un Spectrum 48K o 128K. El A-Z80 tiene una discrepancia de medio ciclo de reloj de CPU al comienzo de cada ciclo de bus de memoria. Me explico: esta implementación del Z80 saca el contenido del bus de direcciones medio ciclo después de que comience el ciclo T1 de un ciclo de memoria. Eso fastidia por completo al circuito de detección de contención, que necesita detectar si la dirección de memoria puede provocar contienda una vez que dicha dirección está en el bus, pero ANTES de que baje la señal de petición de acceso a memoria. En el A-Z80, y a causa de esta discrepancia, el bus de direcciones muestra su valor A LA VEZ que se activa la señal de petición de acceso a memoria, con lo que el circuito de contención nunca detecta dicha condición y no se activa.
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Responder