Proposición ZXUno+

Dudas, cuestiones, sugerencias y peticiones en general sobre el proyecto / Questions and requests about the project
azesmbog
Mensajes: 319
Registrado: 17 Feb 2016, 23:07

Re: Proposición ZXUno+

Mensaje por azesmbog » 25 Ene 2018, 20:14

Sorgelig еще 2 года назад попробовал core A-Z80 в своих ядрах на MiST, и с его слов ядро очень сырое и много недостатков, он писал автору bugs-reports, но то так и не ответил. Поэтому он вернулся на Т80. Это же неспроста? И я склонен ему верить.
Но что тут тест идет ровно - меня это радует, не зря значит я его рисовал :)

Avatar de Usuario
Kyp
Mensajes: 240
Registrado: 18 May 2016, 20:16

Re: Proposición ZXUno+

Mensaje por Kyp » 25 Ene 2018, 20:21

Hace unos meses intenté usar el a-z80 pero no funcionaba con las FPGAs de Xilinx porque tenía partes escritas en System Verilog y el WebISE no soporta ese lenguaje de descripción. Hace poco lo portó a Verilog y entonces ha sido cuando he podido probarlo. De todas formas es un core mucho más farragoso (a ver como traduce eso Google Translator :D) y ocupa muchos mas slices, un 15% o un 20% más. Aun así, mi descripción de Spectrum 48K + DivMMC que es mucho más sencilla que la oficial, ocupa ya un 63% de la FPGA. Antes no llegaba al 50%.

azesmbog
Mensajes: 319
Registrado: 17 Feb 2016, 23:07

Re: Proposición ZXUno+

Mensaje por azesmbog » 25 Ene 2018, 20:26

да, но в примере у автора есть ZXSpectrum под DE1 ( у меня работает), и под nexus3 - это то точно для ISE ?
а в процентах - не суть важно, ну хоть пусть все 99% ядро - лишь бы работало правильно. Но запас пока есть то

Avatar de Usuario
Kyp
Mensajes: 240
Registrado: 18 May 2016, 20:16

Re: Proposición ZXUno+

Mensaje por Kyp » 25 Ene 2018, 20:30

A lo mejor el autor dispone de la suite de pago (¿Vivado?) que si soporta system verilog. Los aficionados nos tenemos que conformar con la gratuita (WebISE).

azesmbog
Mensajes: 319
Registrado: 17 Feb 2016, 23:07

Re: Proposición ZXUno+

Mensaje por azesmbog » 25 Ene 2018, 20:34

Вернее не точно объяснил. Там два проекта
ZXSpectrum и BASIC для DE1, и только BASIC для nexus3 (xc6slx16) . Возможно в BASIC версии не все части ядра использованы ?
http://baltazarstudios.com/sinclair-zx- ... /#more-952
https://bitbucket.org/gdevic/a-z80/downloads

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 » 25 Ene 2018, 22:36

Kyp escribió:A lo mejor el autor dispone de la suite de pago (¿Vivado?) que si soporta system verilog. Los aficionados nos tenemos que conformar con la gratuita (WebISE).
Vivado también tiene una versión gratuita, pero Vivado sólo funciona para la familia -7 (Spartan 7, Kintex 7, Artix 7, Virtex 7...) Si trabajas con la Spartan 6, tienes que usar ISE sí o sí.
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
aowen
Mensajes: 178
Registrado: 07 Oct 2015, 13:32

Re: Proposición ZXUno+

Mensaje por aowen » 26 Ene 2018, 22:40

Radastan escribió:Let's see, I think that by now it is more than seen that the ZXU is not squeezed to the fullest or almost. The point is that with all the experience acquired we should move on to an evolution of the plate. It is clear that the 512K does not give more than if, many have the expansion of 2 MB, to cite an example. Idem in capacity of the FPGA, there are cores that do not fit even with a shoehorn.

My proposal:
- Move to a larger FPGA
- Having two slots: one for video and another for extensions
- Two joystick ports
- Four USB ports controlled by PIC
- 2 MB of RAM, I do not think we need more. Better SDRAM?

My idea of ​​plate:
- Forgetting the raspberry format: making customized cases is already economical
- For the video output there would be a connector like the expansion one, to which a plate would be connected with the corresponding video output. So we do not have to pay HDMI rights ... there is no connector ... but it is a separate insert.
- Enter a tiny PIC, just enough to control USB. In this way the keyboard, mouse, and even a pendrive, could go by USB. We can put four USB ports and we would have even for USB commands. All cores could have FAT32 access without browning and without occupying FPGA space.

I'm not talking about a radical reform, the PIC frees us from the most cumbersome and makes life easier, while the FPGA allows us to put bigger cores. And of course keeping everything that has already been achieved with the ZXUno.

Opinions about it ....
First off sorry about the Google translate version, but my Spanish is virtually non-existent. My take on it is that the Uno is a "Goldilocks" FPGA board. Not too big, not too small, but just right. If you want an FPGA version of the old 16-bits, that's what MiST is for. If you revise the design without retaining compatibility, you reduce the potential size of the user base. I consider the Uno a proven design, which is why I want to use it as the basis for the Chloe 280SE. The FPGA may seem small when a lot of gates are used to provide cycle accurate behavior. If you throw out that requirement you can design a much more powerful machine that will still fit within the FPGA size. This is my plan for the Chloe now. I'm hoping to get a DVI-I connector on the Chloe board in addition to composite out. That gets you HDMI and VGA support via one port. I agree on adding a second joystick port. But adding that and DVI will reduce the available number of GPIO pins. I don't think USB is a good fit for FPGA. So long as gamers want responsive devices, you will always be able to get wired PS/2 keyboards and mice. I don't think there's a need for more RAM (except for the TZX module, and personally I don't care about tape). The aim of the Chloe is to be a superset of the standard Uno board in a custom case. That will enable it to run any existing (or future) Uno core. And the Chloe core itself should work on a standard Uno board (albeit without DVI-I or a second joystick port).

You'd be surprised what you can do in a 32K frame buffer with a well thought out video mode:

Imagen

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

Re: Proposición ZXUno+

Mensaje por zx81 » 27 Ene 2018, 18:29

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!
Modificando los cores Z80 para evitar ese problema me he encontrado con un error en el tu "broma" o con algo que no veo bien como funciona.

Según creo, la NMI se comprueba en el último ciclo de máquina de la instrucción en curso. Como es una señal activada por flanco negativo, cuando se produce la CPU la almacena en un latch a la espera de que pueda atenderla.

Al final de la instrucción se mira por este orden:

- BUSRQ
- NMI
- INT

Tu programa llena de 0xFD la RAM entre 0x5B00 y 0xFFFF y luego pone en los tres últimos bytes un JMP 0x5B00. Ese es el primer "fallo" del programa, porque el Z80 la trata como una instrucción larguísima acabada en un JMP. Al final del JMP se mira la NMI y se salta a 0x0066 poniendo PC en la pila. Luego la rutina de la ROM guarda con PUSH AF y HL. La pega de eso es que el registro SP está apuntando 32744, lo que machaca 6 de los 0xFD que habías puesto tú. Y pone lo que hay en PC (0x5B00) y lo que hubiera en AF y HL. Cuando la secuencia de 0xFD llega a esas direcciones lo que ejecuta es un truño que a saber lo que acaba haciendo, podría mirarlo pero no creo que merezca la pena. Y la NMI funciona, ya lo creo que funciona.

La única manera de hacer eso es en el +2a/+3. Llenas las páginas de 0 a 3 con 0xFD, y al final, pones el modo All-ram. Ahí sí se acabó la NMI.

Eso suponiendo que detrás de la NMI haya un latch que resetea la CPU al atender la NMI. Si no, ya no sé cuando y como muestrea NMI.

P.D.: Me extrañaba mucho que el asunto no se volviera loco y empezara a ejecutar cosas al estilo Belén Esteban. Tanto me extrañaba que me he entretenido en ver lo que ejecutaba (y no podía con el depurador de Fuse porque peta al intentar desensamblar una caterva de 0xFD). Y lo que me sale es casi diabólico:

Código: Seleccionar todo

NOP
LD E, E
LD C, B
JMP 0x5B00
Da igual donde pulses NMI porque saltará en el JMP y la dirección de RETN que meterá en la pila será la de 0x5B00. Como no se trabaja con registros y el único que se toca es el B, y ese no está implicado en la rutina de manejo de NMI de la ROM, siempre mete lo mismo. Pero el registro A tiene el valor 0xC3 (JMP) que es exactamente lo que necesita después para poder ejecutar la dirección de vuelta de RETN. Y como en la variable del sistema NMIADD hay un FDFD, no es cero y por tanto no salta a la dirección cero de la ROM. En resumen, que es un programa que da el pego porque parece que no hace nada, pero la NMI sí funciona y si tienes un Multiface o el propio DivIDE en ZX-Uno, que usan la NMI funcionan.
O es el código más ingenioso de la historia, o el día que lo parió, mcleod debió haber hecho una primitiva en su lugar, ahora estaría doblao a piñas coladas en Copacabana rodeado de pibones para el resto de su vida. :mrgreen:

Avatar de Usuario
Kyp
Mensajes: 240
Registrado: 18 May 2016, 20:16

Re: Proposición ZXUno+

Mensaje por Kyp » 02 Feb 2018, 14:15

He subido los fuentes a mi OneDrive (zxkyp05): https://1drv.ms/f/s!Aj2oYYIgITnQkDHmZ42kBXE9-6ob
Ya funciona el bus flotante. La contienda parece estar bien pero ahora no me salen en su sitio los datos del ULATEST3. Por lo demás parece que funciona bien, incluido el test de azesmbog.

Avatar de Usuario
Radastan
Mensajes: 389
Registrado: 05 Oct 2015, 14:39

Re: Proposición ZXUno+

Mensaje por Radastan » 10 May 2018, 11:16

Yo no es por insistir, pero a raíz del hilo de los softcores es evidente que lo del ZXDos/ZXUno+ es cada vez más demandado.

Si la LX45, o la FPGA que sea, es factible para ello, creo que es el momento de ir planteando de forma seria la siguiente generación.

Responder