Proposición ZXUno+
Re: Proposición ZXUno+
Sorgelig еще 2 года назад попробовал core A-Z80 в своих ядрах на MiST, и с его слов ядро очень сырое и много недостатков, он писал автору bugs-reports, но то так и не ответил. Поэтому он вернулся на Т80. Это же неспроста? И я склонен ему верить.
Но что тут тест идет ровно - меня это радует, не зря значит я его рисовал
Но что тут тест идет ровно - меня это радует, не зря значит я его рисовал
Re: Proposición ZXUno+
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 ) 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%.
Re: Proposición ZXUno+
да, но в примере у автора есть ZXSpectrum под DE1 ( у меня работает), и под nexus3 - это то точно для ISE ?
а в процентах - не суть важно, ну хоть пусть все 99% ядро - лишь бы работало правильно. Но запас пока есть то
а в процентах - не суть важно, ну хоть пусть все 99% ядро - лишь бы работало правильно. Но запас пока есть то
Re: Proposición ZXUno+
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).
Re: Proposición ZXUno+
Вернее не точно объяснил. Там два проекта
ZXSpectrum и BASIC для DE1, и только BASIC для nexus3 (xc6slx16) . Возможно в BASIC версии не все части ядра использованы ?
http://baltazarstudios.com/sinclair-zx- ... /#more-952
https://bitbucket.org/gdevic/a-z80/downloads
ZXSpectrum и BASIC для DE1, и только BASIC для nexus3 (xc6slx16) . Возможно в BASIC версии не все части ядра использованы ?
http://baltazarstudios.com/sinclair-zx- ... /#more-952
https://bitbucket.org/gdevic/a-z80/downloads
- mcleod_ideafix
- Mensajes: 831
- Registrado: 27 Sep 2015, 00:14
- Ubicación: Jerez de la Frontera
- Contactar:
Re: Proposición ZXUno+
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í.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).
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA
Re: Proposición ZXUno+
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).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 ....
You'd be surprised what you can do in a 32K frame buffer with a well thought out video mode:
Re: Proposición ZXUno+
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.mcleod_ideafix escribió: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!mcleod_ideafix escribió:Por cierto, y en aras de colaborar para que JSpeccy sea aún más exacto...
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
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.
Re: Proposición ZXUno+
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.
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.
Re: Proposición ZXUno+
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.
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.