Proposición ZXUno+

Dudas, cuestiones, sugerencias y peticiones en general sobre el proyecto / Questions and requests about the project
Avatar de Usuario
antoniovillena
Mensajes: 2599
Registrado: 27 Sep 2015, 20:41

Re: Proposición ZXUno+

Mensaje por antoniovillena » 17 Ene 2018, 15:33

BCH escribió: Yo habia probado (hace ya mucho tiempo) unos MX25L3235 y no me habian funcionado...
Vaya. Menos mal que solo me he gastado 2 euros. De todas formas probaré a ver si esta memoria usa otros comandos distintos.

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

Re: Proposición ZXUno+

Mensaje por zx81 » 17 Ene 2018, 17:29

mcleod_ideafix escribió:
zx81 escribió:El core de ZX-Spectrum, que es lo que a mi me interesa, no pone en su sitio los ciclos de contención, ni el bus flotante saca lo que debe cuando debe.
¿Qué tests has usado para comprobar esto?
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).

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.

El IR_Contention de Mark Woodmass (el autor de Specemu). Empieza cojonudamente bien, pero acaba francamente mal. Si no me equivoco, comprueba la contención que se produce por algunos contenidos del par IR que quedan en el bus, nunca he entendido muy bien porqué, solo puedo especular. Esto afecta en teoría al Z80, que es quien los pone. De este mismo autor también hay un test del Z80, que falla en algunas instrucciones del Z80 "conocido" y en todos los tests relacionados con el registro WZ (o memptr, como prefieras).

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. 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' o en el 14337, como debería ser en un 'late-timing'. No obstante, ya me gustaría a mi poder probar ese test en un 48k real. Ese programa va en el paquete zxtest3.

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.
mcleod_ideafix escribió:
zx81 escribió:Las páginas en contienda solo son la 5 y la 7, pero eso afecta a programas que no se ejecutan como lo hacen en el real
Eso está hecho aposta. Las únicas páginas que necesitan tener contienda son la 5 y la 7. El resto no tiene por qué tenerlas. Poner contienda al resto de páginas es trivial de todas formas, pero como no conozco ninguna demo, juego o utilidad que necesite contienda en las páginas 4, 5, 6 y 7, pues dejé la contienda sólo en 5 y 7.
Aquí ya entramos en opiniones y ya sabemos lo que pasa con ellas y los culos. Mi humilde y modesta opinión, es que estamos emulando (en mi caso) o replicando (en el del zx-uno) un comportamiento preexistente. Se puede replicar o no, pero si no lo haces... ya no es lo mismo. Si me esfuerzo por llegar hasta el absurdo es porque ambos sabemos que para emular el 95% de los juegos no hace falta ser un pijotero, se puede hacer casi con lo básico. Pero para esa emulación (YO) no me curro un emulador bare-metal ni monto un cisco con una FPGA. Si llego a ese extremo es para conseguir una emulación que sea ridícula y absurdamente precisa. El ideal es que sea indistinguble del real, cuanto te acerques a esa meta y con lo que cada uno se conforme, es otra cuestión. Y digo por experiencia, que del 5% restante, para emular el 3% hay que hacer un esfuerzo titánico y para el otro 2% hay que sudar tinta china como los calamares y tener pesadillas nocturnas durante meses. Si el 128k tiene contención en las páginas 1,3,5 y 7 es ahí donde la pongo.
mcleod_ideafix escribió:
zx81 escribió:o no permite ver las diferencias de ejecución entre el 128k/+2 y los +2a/+3
Los timings del +2A/+3 no están implementados, sólo los de 128K/+2. No conozco ningún juego o demo que los necesite.
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.
mcleod_ideafix escribió:
zx81 escribió:Los tiempos tampoco tengo claros que sean totalmente precisos entre máquinas.
Esto... ¿qué significa?
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. Una imagen PAL interlazada es de 50 Hz, pero el 48k tiene una frecuencia de cuadro de 50.08 Hz y el 128k de 50.02 Hz. Esa mínima diferencia hace que demos que muestran una imagen interlazada estable, como paralaktika y mescaline, en el ZX-Uno no sean estables. O que la línea de scroll del menú de Dan Dare no se vea bien, al menos en mi TV, que tampoco me parece que gestione bien los 50 Hz interlazados, pero ese es otro tema. Si el cuadro dura lo que dura un cuadro PAL estándar, el Spectrum está funcionando ligeramente más lento, especialmente en el 48k (le faltarán 5600 ciclos de reloj por segundo). Pero, repito, esta es una suposición mía muy difícil de contrastar, salvo por lo que veo en pantalla, que no me cuadra.
mcleod_ideafix escribió:
zx81 escribió:Y eso por no hablar de meterle mano al core Z80 para arreglar las 52 diferencias que me han salido en los test de CPU que creó Patrik Rak, el autor del emulador ZXDS.
Y más que habrá :D El core de Z80 que tenemos es... eso, el que tenemos. Tampoco implementa bien la señal WAIT (por eso no implemento el +2A/+3). Escribir un core de un procesador en FPGA es más complejo que hacerlo para un emulador. Sobre todo porque la depuración es mucho más compleja y tediosa que cuando depuras software. Lo he intentado un par de veces, partiendo de cero, pero las dos aproximaciones que he usado se han dado de bruces con la limitación de espacio en la FPGA. En emulación uno se preocupa de que el sistema sea lo suficientemente rápido como para mover todos los elementos que se emulan. En FPGA no hay esa preocupación, pero sí hay otra: que el chip sea lo suficientemente grande como para que quepan todos los módulos.
Esa es otra historia que yo no sabía y que explica razonablemente algunas cosas. Solo de pensar en sintetizar desde cero un Z80 me pone los pelos como escarpias. Y me pregunto, a la sazón, si el primero que lo consiga al 100% no le caerá una demanda de Zilog, que aún vende el chip y, si se lo compras, seguro que te lo vende en VHDL o Verilog para que lo metas en una FPGA donde quepa.
mcleod_ideafix escribió:
zx81 escribió:Me pregunto (y pregunto) si sería posible y si hay suficientes pines libres como para poner una sintetización de un FDC 765 y conectar de manera externa algo similar a una Gotek. Molaría tela marinera tener un +3 funcional sin cosas raras tipo ESXDOS ni +3e.
¿Quieres decir conectar un FDC765 de verdad a los pines del conector de expansión? ¿o sintetizar un core de FDC765 completo dentro de la FPGA? Lo primero es perfectamente posible. Lo segundo... no conozco ningún core completo de FDC765. Wilco2009 estaba precisamente sobre el tema.
Reconozco que cuando escribí esto pensaba en Wilco.... :D
Me refiero a sintetizar el FDC (no sé bien qué hace el famoso separador de datos) y meterlo en el ZX-Uno como parte integral, para poder conectarle una Gotek directamente. No sé cómo quedó Wilco al respecto, ni el nivel de complejidad del tema.

Mi visión del ZX-Uno es el de tener una reproducción quasi perfecta del Spectrum (lo del teclado tiene mal arreglo y un teclado PS2 o, peor aún, un USB no mejoran el asunto), que me sirva de referencia de implementación dado que, por ejemplo, no dispongo de un 48k funcional. Una implementación en FPGA es capaz de hacer cosas mucho más allá de lo que es capaz de hacer un "emulador tradicional". Eso sí, nadie ha dicho que sea fácil. El día se se consiga todo el mundo dirá aquello de lo hicieron porque no sabían que era imposible.

Aclaro una cosa para evitar suspicacias: NO ME ESTOY QUEJANDO NI CRITICANDO NADA- El trabajo del equipo del ZX-Uno me parece absolutamente bruthal y lo conseguido está muy cerca de ser perfecto. Ya quisiera yo poder dar soluciones en FPGA en lugar de lanzar lo que podría parecer una diatriba contra el aparato. Nada más lejos de la realidad así que, por favor, que nadie se ofenda o moleste por alguna parte de este ladrillo. ;)

zxpope
Mensajes: 11
Registrado: 02 Ene 2018, 02:12

Re: Proposición ZXUno+

Mensaje por zxpope » 17 Ene 2018, 21:51

hola a todos,
hola "zx81",

gracias por tu detallado y extenso mensaje.
desconocia estos detalles tan oscuros de la máquina, y he disfrutado leyendolo.
es un placer redescubrir el spectrum, 30 años mas tarde.

estaba pensando... si no seria interesante, perdonad el atrevimiento, quedar un sábado
y hacer una serie de ponencias donde cada uno explicara en aquello que se ha especializado.

Esa puesta en común permitiria a todos tener una vision general y conocimiento de lo que otros hacen,
(a parte de poner cara a todos esos nicks que aparecen por aquí)

Para animar la participación, podriamos invitar a Sir Clive, a alguno de los autores de ZXNEXT,
o a otra personalidad relevante.... ;-)

salud,
zxpope

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

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 22 Ene 2018, 19:15

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.
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.
zx81 escribió:El IR_Contention de Mark Woodmass (el autor de Specemu). Empieza cojonudamente bien, pero acaba francamente mal. Si no me equivoco, comprueba la contención que se produce por algunos contenidos del par IR que quedan en el bus, nunca he entendido muy bien porqué, solo puedo especular. Esto afecta en teoría al Z80, que es quien los pone. De este mismo autor también hay un test del Z80, que falla en algunas instrucciones del Z80 "conocido" y en todos los tests relacionados con el registro WZ (o memptr, como prefieras).
Todo esto es cosa del core T80, así que se va a quedar de momento así :D
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
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á.
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?
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?
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.
zx81 escribió:Esa es otra historia que yo no sabía y que explica razonablemente algunas cosas. Solo de pensar en sintetizar desde cero un Z80 me pone los pelos como escarpias. Y me pregunto, a la sazón, si el primero que lo consiga al 100% no le caerá una demanda de Zilog, que aún vende el chip y, si se lo compras, seguro que te lo vende en VHDL o Verilog para que lo metas en una FPGA donde quepa.
La patente por el Z80 hace tiempo que expiró. Hay webs donde han estado estos últimos años haciéndole ingeniería inversa al Z80 para ver cómo funciona realmente (por ejemplo, se descubrió que su ALU es de 4 bits), y de hecho el diseño de Goran Devic está basado, además de en trabajo suyo original, en lo que se descubrió en estas otras webs.
zx81 escribió:Me refiero a sintetizar el FDC (no sé bien qué hace el famoso separador de datos) y meterlo en el ZX-Uno como parte integral, para poder conectarle una Gotek directamente. No sé cómo quedó Wilco al respecto, ni el nivel de complejidad del tema.
Pues habrá que esperar a que Wilco2009 o alguna otra persona, sean capaces de describir por hardware lo que hace el FDC. En cuanto al separador de datos, hay una versión hecha con componentes discretos, en donde entre otras cosas hay una pequeña PROM de 16 o 32 bytes, y algo de lógica. Hay algo sobre dicho separador de datos en esta web: http://www.worldofspectrum.org/BackToThePlus3/
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
brunosilva
Mensajes: 309
Registrado: 18 Jun 2016, 19:54

Re: Proposición ZXUno+

Mensaje por brunosilva » 22 Ene 2018, 22:41

"La patente por el Z80 hace tiempo que expiró."

hum... who made/designed the z80?

its not possible to try to reach him/them and try to get the "source"? i dont even know how it works :)

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

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 23 Ene 2018, 00:34

brunosilva escribió:i dont even know how it works :)
This is the best source I can tell, for those that want to really know how the thing works...
http://baltazarstudios.com/z80-ground/
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

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

Re: Proposición ZXUno+

Mensaje por mcleod_ideafix » 23 Ene 2018, 00:47

brunosilva escribió:"La patente por el Z80 hace tiempo que expiró."
More precisely, these patents: US4332008, US4486827 and US4605980. The most recent was issued in 1986. According to this Terms of patent in the United States, these patents expired after 17 years, so, from year 2003, the Z80 design is not subjected to them.

There are websites that have reverse engineered the Z80, even discovered and marked the transistor traps put there by the designers to fool copiers, and have put all that work online without Zilog making any statement against it. Zilog haven't made any statement or started any legal actions whatsoever.

There are small private companies that make profit by selling optimized FPGA designs of later processors, such as the 8088, without Intel endorsement, and nothing has happened.
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
brunosilva
Mensajes: 309
Registrado: 18 Jun 2016, 19:54

Re: Proposición ZXUno+

Mensaje por brunosilva » 23 Ene 2018, 00:51

hum...

has anyone asked zilog (https://www.zilog.com/ ?) if they could open their sources for this old processor? :)

mos probably the answer will be NO... but who knows if they like and follow the zx scene?

Avatar de Usuario
yombo
Mensajes: 486
Registrado: 05 Oct 2015, 14:10

Re: Proposición ZXUno+

Mensaje por yombo » 23 Ene 2018, 01:04

brunosilva escribió:hum...

has anyone asked zilog (https://www.zilog.com/ ?) if they could open their sources for this old processor? :)

mos probably the answer will be NO... but who knows if they like and follow the zx scene?
I guess the Zilog company still makes money by selling Z80's so likely they won't give that info.

I guess also they don't care what their Z80's are used for.

:homer:

Avatar de Usuario
brunosilva
Mensajes: 309
Registrado: 18 Jun 2016, 19:54

Re: Proposición ZXUno+

Mensaje por brunosilva » 23 Ene 2018, 01:17

@yombo - you're right... I did a search in zilog's site and it didn't return any values... because the search doesn't work...

they updated Z80 CPU User Manual in 2016... :X small revisions but they updated...

Responder