ZX-Uno: Camino hacia la versión 3 (definitiva)

[jjmarin]

Vaya, creo se me ha despistado el enlace del socz80 original:
- http://sowerbutts.com/socz80/

[Dustin]

Buenas,

No es por enredar más , pero existe un proyecto denominado FPGAmstrad, aunque parece que le faltan algunas cosas, tiene una lista bastante larga de juegos que funcionan.



Saludos

[Quest]

Buenas,

No es por enredar más , pero existe un proyecto denominado FPGAmstrad, aunque parece que le faltan algunas cosas, tiene una lista bastante larga de juegos que funcionan.
Saludos

Ya, estuve días intentando hacerlo funcionar... pero no hay manera. Lo malo es que la mayoría de los archivos fuente del proyecto son en formato esquema (SCH), y no en lenguage HDL (vhdl/verilog), y no tengo ni idea, y además requiere una SDRAM (nosotros tenemos SRAM), porque estaba intentando portar la version más cercana, para la placa nexys2 que monta una spartan-3e. Ha llegado a punto muerto, no tengo idea.

Esto es lo máximo que he conseguido sacar por pantalla (después de conseguir sintetizar sin errores pero con muchos warnings):



El problema es que todos los cores "buenos" están hechos para Altera (por eso portaron tantos sistemas buenos a MiST), y no para Xilinx. Parece como si le tuvieran tirria
Y el desarrollo bueno de Amstrad, pues eso, para Altera.

Por cierto, que ya he hecho funcionar un par de cores más, uno de Pacman arcade (con los colores mal, tengo que mirarlo) y un Vic-20, que como no tiene manera de cargarle nada (ni entrada de cassette, ni SD, ni na) pues sirve como curiosidad, o para cacharrear un poco con el Basic.

-- Actualizado 20 Ago 2015, 13:17 --

En la última versión no hay botones extra en el puerto de joystick. Intentaré sacar un pin de donde sea para que funcionen los pads de la SMS (con el segundo botón en el pin 9), porque sería una pena no poder jugar a la NES o a la SMS con los nuevos sistemas que has portado por no tener dicho botón.

Pues sí que es una pena, supongo que las 2 señales que se han quitado del puerto de joystick se han utilizado para las 2 nuevas líneas de direcciones de la nueva huella de SRAM para que admita hasta 2Mb...

Lo malo es que mirando el esquema, no veo que se pueda sacar de ningún sitio. Sólo del conector de expansión. No se qué funcionalidades de expansión podríamos perder si quitamos 1 o 2 señales de ahí.

No obstante habría que saber, de la gente que vaya a apoyar el crowfunding para hacerse con uno, cuántos lo usarán tal cual, y cuántos querrán algun tipo de expansión (supongo que la mayoría no necesitará ampliaciones, además ni siquiera se sabe cuáles, pero nunca se sabe...)

[radastan]

¿Y cabría en el ZX Uno el CPC Trex?

http://www.symbos.de/trex.htm

[EdgeM]

El problema que tenía el Rex era el tema de las Compact Flash. Si se consigue que funcione con SD sería una maravilla

[Metalbrain]

¿Y cabría en el ZX Uno el CPC Trex?

http://www.symbos.de/trex.htm

Pa mi que ni de coña, teniendo en cuenta esto:
24MHZ Z80 * 576KB RAM * 256KB ROM

Y aparte, tiene el problema de que solo está para Altera, no para Xilinx

[mcleod_ideafix]

Y aparte, tiene el problema de que solo está para Altera, no para Xilinx

Si tiene el código fuente se puede portar, pero el problema es ese: los requerimientos de memoria, y la necesidad de un slot físico de CF. No hay nada de esto en el ZX-Uno.
Lo que no quita que, si el core está bien modularizado, se pueda coger lo que se necesite para tener un CPC6128 aunque sea con carga por cassette.

[wilco2009]

¡¡¡ Menuda pasada Quest!!!

¡Qué envidia esa maestria que has adquirido en pocos días!.

Por otro lado, estoy un tiempo sin entrar por aquí y esto cambia que da gusto.
Ya estoy sacando la cartera para cuando salga la versión definitiva poner el dinero sobre la mesa. Me quito el sombrero ante el equipo del ZX-UNO.

[Quest]

Bueno, voy a volver a centrar el tema en lo importante del ZX-UNO, el core de spectrum.

Creo que lo de los otros cores se me ha ido un poco de las manos y he descuidado un poco el tema familiar.

Sobre todo voy a comentar cosillas para Mcleod (core) y para Antonio (bios).

Para ir resolviendo viejos temas que estaban pendientes con el core principal (actual test18), que habían estancado el tema un poco, he estado haciendo algunas pruebas, sobre todo con el problema que tuve con el test18 y su inestabilidad (ver aqui: http://zonadepruebas.com/viewtopic.php? ... 310#p58984 y aqui: http://zonadepruebas.com/viewtopic.php? ... 330#p59135 entre otros mensajes)

- He encontrado la causa. Es un tema muy tonto, no tiene nada que ver con el core, sino con la versión del ISE. Yo estuve sintetizando con 12.1 y ahí estaba el problema. Ahora tengo instalados tanto 12.4 como 14.7 (sobre todo para tener más abanico para la edición de otros cores) y me ha dado hoy por sintetizar con las nuevas versiones exáctamente el mismo test18 que me daba problemas, y... se han solucionado. Recomiendo totalmente evitar la versión 12.1, que además es MUY lenta sintetizando (me tardaba 10 minutos, mientras que las nuevas me tardan sólo 2 minutos!!!, incluida la generación del bitstream).

Por tanto, tema del test18 zanjado. Es perfectamente estable, y funcionan perfectamente todas sus mejoras.

----

Ahora pasamos al tema BIOS:

- Antonio, ya se que tienes poco tiempo últimamente pero hay algo que llevamos arrastrando desde hace casi 3 meses, y al menos deberíamos dejarlo como estaba antes de los últimos cambios, a no mucho tardar. ¿Por qué? porque ahora mismo la BIOS que hay está mal. Es decir, si ahora mismo alguien se baja el repositorio y trata de cargar en el ZX-UNO lo que hay, se va a encontrar con que hay corrupciones. Si entras a bios y cambias cualquier cosa (o no cambias nada, da igual) y le das a salir guardando cambios, adiós. Flash corrupta y brick. Da igual lo que hagas, cualquier intento de grabación, corrompe la flash. Por eso estoy usando BIOS más antiguas. Además, aunque no grabes nada, hay corrupciones de strings, caracteres, etc al navegar por los menús. ¿Qué te parece volver a la 227 de forma oficial, y continuar a partir de ahí? Esa funcionaba de fábula.

- Por cierto, he visto los últimos cambios que has hecho en los esquemas Altium del ZX-UNO v3 para añadir el pin del josystick. El pin 39 (IO_L65P_INIT_B_2) ¿Es seguro ponerlo así ahora? No entiendo mucho del tema, pero he leído que durante el periodo de configuración debe poder ponerse en alto, mediante pullup en placa. Antiguamente ese pin estaba puesto en alto de forma fija. Se supone que después del periodo de configuración sí se puede usar como un pìn I/O más. No se si a partir de ahora puede dar algún problema o no, imagino que no, pero por asegurarnos...

De paso comentar que cuando estén la v3, lo que hay hecho para la anterior no va a funcionar (por si llegado el momento a alguien se le ocurre meter bits/mcs sin modificar los fuentes) porque veo que el pineado de la SRAM ha cambiado totalmente, no sólo ha añadido 2 líneas de dirección más, sino que ha cambiado todos los pines que van a ella. También han cambiado los pines del joystick.
---

De momento no se me ocurren más cosas. Iré actualizando si veo algo más.

[antoniovillena]

- Antonio, ya se que tienes poco tiempo últimamente pero hay algo que llevamos arrastrando desde hace casi 3 meses, y al menos deberíamos dejarlo como estaba antes de los últimos cambios, a no mucho tardar. ¿Por qué? porque ahora mismo la BIOS que hay está mal. Es decir, si ahora mismo alguien se baja el repositorio y trata de cargar en el ZX-UNO lo que hay, se va a encontrar con que hay corrupciones. Si entras a bios y cambias cualquier cosa (o no cambias nada, da igual) y le das a salir guardando cambios, adiós. Flash corrupta y brick. Da igual lo que hagas, cualquier intento de grabación, corrompe la flash. Por eso estoy usando BIOS más antiguas. Además, aunque no grabes nada, hay corrupciones de strings, caracteres, etc al navegar por los menús. ¿Qué te parece volver a la 227 de forma oficial, y continuar a partir de ahí? Esa funcionaba de fábula.

Me parece bien. He revertido el repositorio a la revisión 0.227.

- Por cierto, he visto los últimos cambios que has hecho en los esquemas Altium del ZX-UNO v3 para añadir el pin del josystick. El pin 39 (IO_L65P_INIT_B_2) ¿Es seguro ponerlo así ahora? No entiendo mucho del tema, pero he leído que durante el periodo de configuración debe poder ponerse en alto, mediante pullup en placa. Antiguamente ese pin estaba puesto en alto de forma fija. Se supone que después del periodo de configuración sí se puede usar como un pìn I/O más. No se si a partir de ahora puede dar algún problema o no, imagino que no, pero por asegurarnos...

Ese pin tiene un pull-up interno porque he probado a quitar la resistencia en mi prototipo actual y sigue funcionando. Es un pull-up débil (resistencia alta) que en el datasheet recomiendan reforzar con una resistencia externa de valor más bajo. Si con pista que iba a dicha resistencia (cuando quité la resistencia) funcionaba, creo que con la pista actual que va al conector DB9 también funcionará. La única forma de asegurarse es hacer otro prototipo, pero no quiero retrasar más el proyecto. Así que o renunciamos al segundo disparo o tenemos una pequeña posibilidad de que dé problemas al arranque, y yo he optado por lo segundo.

De paso comentar que cuando estén la v3, lo que hay hecho para la anterior no va a funcionar (por si llegado el momento a alguien se le ocurre meter bits/mcs sin modificar los fuentes) porque veo que el pineado de la SRAM ha cambiado totalmente, no sólo ha añadido 2 líneas de dirección más, sino que ha cambiado todos los pines que van a ella. También han cambiado los pines del joystick.

Es cierto. Estos cambios los ha hecho Superfo y si ha sacrificado la compatibilidad es porque para mantenerla el ruteado se complicaba bastante. Para los que tenemos los prototipos es un rollo porque en un momento dado sólo se generarán los .mcs de la v3 y tendríamos que recompilar con el antiguo .ucf. En algún momento he dicho que la versión final (v3) iba a ser totalmente compatible con el prototipo v2. Me equivoqué, lo siento. Es más, puede que en el futuro haya algún core que explote la mayor velocidad (10ns) de la nueva SRAM y no funcione en el prototipo v2. Procuraremos que al menos siempre haya una versión actualizada que funcione en la v2 (con la SRAM de 45ns).