Cacharreando con el prototipo 2 del ZX-Uno

[Quest]

Antes de pasar a comentar sobre lo que teníamos en marcha de las ROMs y demás, quería comentar que pasa algo raro desde ayer por la mañana en las pruebas que he estado haciendo, pero que achacaba a algún problemilla en mi generamcs / mi versión de esxdos / mi aa000.asm modificado, etc. Pero estoy viendo que grabando un .mcs limpio de los del repositorio (prom_av.mcs por ejemplo) sin tocar, directamente con impact, también pasa lo mismo, y no quiero ni pensar que se trate de algún fallo en mi ZX-UNO (spi, ram, fpga o soldaduras..), a ver qué opinas, con el prom_av.mcs último del svn recién grabado:

- Al intentar arrancar con la rom "48K CargandoLeches" da CRC error

- Con cualquier rom y Esxdos activado, el menú NMI no sale, se cuelga el ZX-UNO. Sin embargo la inicialización de ESXDOS parece ir bien, reconoce la SD, partición, etc. Si intentas usar algún comando de ESXDOS (por ejemplo .ls), da: "C SIN SENTIDO EN BASIC, 0:1".

- Con algunas roms, el reset normal (ctrl+alt+supr) no lo hace bien, y a cambio sale la pantalla de inicio del logo del ZX-UNO, pero con el paper en blanco en vez de en negro, y se queda ahi, no nace nada más. Si en ese momento le das a EDIT para entrar, parece como si entrara a una bios corrupta, se cuelga al darle a la flecha derecha y con colores raros. Un reset total (ctrl+alt+retroceso) lo hace bien y entra bien. Esto me está pasando por ejemplo con la rom del 48k. Con la del Basic SE IV directamente el ZX-UNO se queda seco (seguimos hablando de un reset normal). Con la del +3e resetea bien.

- Pruebo a actualizar ESXDOS desde la BIOS con audio, lo actualiza y entonces ya funciona perfectamente ESXDOS. Si vuelvo a grabar el .mcs, otra vez ESXDOS corrupto.

- Pruebo a actualizar la rom de "48k CargandoLeches" desde la bios con audio, lo actualiza y entonces ya no da CRC error, funciona bien.

- Pruebo a grabar las roms de 48k normal y Basic SE V desde la bios con audio, lo actualiza, pero no se solventan los problemas del reset normal. Entonces pruebo a grabar la BIOS desde la propia BIOS con audio, lo actualiza bien, pero siguen sin desaparecer los problemas de reset de las dos roms anteriores.

- Todas las roms de los juegos van bien.

- El upgrade machine como es muy largo de hacer en audio normal no lo he hecho, lo he intentado hacer en carga rápida con un wav de cargandoleches pero al empezar el segundo bloque da error.

Pensé que podría haber algún problema con la grabación de la SPI desde impact, pero graba y verifica bien, sin errores. No se qué puede pasar. El test de RAM de la BIOS también es correcto. ¿Alguna idea? ¿Os pasa algo parecido a vosotros con estos .mcs?

Ya está. He arreglado el bug. También he podido comprobar que funciona el upgrade BIOS (el de machine y ESXDOS están sin probar, pero pueden funcionar). Muchas gracias por todo el betatesting que estás haciendo. Por cierto, pásame el set de ROMs que usas (con el generamcs.bat me vale), que lo pongo como oficial. El que uso yo es bastante limitado.

Para eso es esta fase de prototipos, betatesting a saco (aprovechando que desafortunadamente ahora tengo bastante tiempo libre).

Voy a preparar el generamcs.bat y aa000.asm en condiciones (lo tengo alcgo chapucero) y te lo paso. De todas maneras visto el listado de roms que has puesto, debajo te comento más.

He creado un listado de ROMs lo más extenso posible y lo he subido al repositorio. Si veis que falta alguna importante me lo decís y actualizo la lista. Este mismo listado está en el repositorio, en firmware/roms/listadoROMs.txt

Genial! Cuanto más completo mejor.

Faltan algunas, que voy a preparar para añadirlas a la lista, los tengo por aquí por el disco duro (pentagon, timex 2068, etc) . Además, si te parece bien, puedo calcular todos los checksums de los taps resultantes y añadirlos al txt para el que quiera meterlos al .asm de forma mucho más rápida.

Por cierto, al margen de esto, algún consejo para sintetizar más rápido? Para cada pequeño cambio que hago en el vhdl del teclado (a lo loco, porque no me entero ni de lo que veo) se tira más de 10 minutos para sintetizar y luego algún minuto más para generar el bit... y lo estoy haciendo en un i5 4690k, que no es precisamente lento. Algo se tiene que poder hacer para no esperar tanto entre prueba y prueba...

[antoniovillena]

Te comento lo mismo que he comentado a otros:

• El bitstream de un led o cualquiera de los de jepalza como el ladybug son autónomos. Es decir, cargas el .bit (o te generas un .mcs del mismo) y funciona.
• Sin embargo el ZX-Uno es más complejo. Además del bitstream en la SPI Flash se almacenan las ROMs y el firmware. Es necesario que cargues algún .mcs con todo incluido. Yo los tengo generados en firmware/roms/prom_es.mcs y en firmware/roms/prom_av.mcs pero puedes generarlos tú mismo a partir del bitstream que quieras con firmware/roms/generamcs.bat.
• Si te llega a funcionar, haz el test de memoria de la BIOS por si ha alguna soldadura mal hecha.
• El sistema del ZX-Uno es sencillo. Son 3 chips básicos: FPGA, SPI Flash y RAM. Los dos primeros los puedes testear con el cable JTAG. Si el cable JTAG te graba bien tanto los .bit como los .mcs pero luego te falla el sistema, lo más probable es una mala soldadura entre FPGA y RAM.
• Una vez te funcione todo lo anterior, ya sólo queda probar teclado, audio, EAR, tarjeta SD, video RGB y video compuesto. Cualquier fallo aquí se detecta fácilmente.
• Si se te jode el microUSB, Superfo tuvo la precaución de poner el conector J12.

-- Actualizado 08 Feb 2015, 17:46 --

Antes de pasar a comentar sobre lo que teníamos en marcha de las ROMs y demás, quería comentar que pasa algo raro desde ayer por la mañana en las pruebas que he estado haciendo, pero que achacaba a algún problemilla en mi generamcs / mi versión de esxdos / mi aa000.asm modificado, etc. Pero estoy viendo que grabando un .mcs limpio de los del repositorio (prom_av.mcs por ejemplo) sin tocar, directamente con impact, también pasa lo mismo, y no quiero ni pensar que se trate de algún fallo en mi ZX-UNO (spi, ram, fpga o soldaduras..), a ver qué opinas, con el prom_av.mcs último del svn recién grabado:

- Al intentar arrancar con la rom "48K CargandoLeches" da CRC error

Esto es culpa mía. He actualizado leches.rom, puesto que el proyecto tenía una ROM más reciente, pero se me olvidó cambiar los CRCs del aa000.asm.

- Con cualquier rom y Esxdos activado, el menú NMI no sale, se cuelga el ZX-UNO. Sin embargo la inicialización de ESXDOS parece ir bien, reconoce la SD, partición, etc. Si intentas usar algún comando de ESXDOS (por ejemplo .ls), da: "C SIN SENTIDO EN BASIC, 0:1".

Esto es porque todas tienen DisableNMI excepto "ZX +3e DivMMC". Anteriormente esto lo hacíamos manualmente desde la BIOS. La opción sigue ahí, pero por defecto está en Auto, así que en cada ROM por separado se decide si se activa o no la NMI. Fíjate en las constantes de aa000.asm y en el primer parámetro de GenRom por si quieres cambiarlo.

- Con algunas roms, el reset normal (ctrl+alt+supr) no lo hace bien, y a cambio sale la pantalla de inicio del logo del ZX-UNO, pero con el paper en blanco en vez de en negro, y se queda ahi, no nace nada más. Si en ese momento le das a EDIT para entrar, parece como si entrara a una bios corrupta, se cuelga al darle a la flecha derecha y con colores raros. Un reset total (ctrl+alt+retroceso) lo hace bien y entra bien. Esto me está pasando por ejemplo con la rom del 48k. Con la del Basic SE IV directamente el ZX-UNO se queda seco (seguimos hablando de un reset normal). Con la del +3e resetea bien.

Esto se debe a que el reset normal sólo resetea el Z80 y no toda la máquina. Por ponerte un ejemplo, si pulsas reset en un +2A mientras está mapeada la ROM del 48K lo que arranca es la ROM de 48K. Yo este reset no lo uso, la verdad es que deberíamos buscarle una solución entre McLeod y yo, pero de momento se queda así.

- Pruebo a actualizar ESXDOS desde la BIOS con audio, lo actualiza y entonces ya funciona perfectamente ESXDOS. Si vuelvo a grabar el .mcs, otra vez ESXDOS corrupto.

Pues debes haber corrompido algo en tu .mcs. A mí sí que me funciona el ESXDOS (o lo mismo he metido la pata al subir tantas ROMs y renombrar algunas).

- Pruebo a actualizar la rom de "48k CargandoLeches" desde la bios con audio, lo actualiza y entonces ya no da CRC error, funciona bien.

Lo que te dije antes, coge el CRC del TAP, se lo pasas al aa000.asm y problema resuelto.

- Pruebo a grabar las roms de 48k normal y Basic SE V desde la bios con audio, lo actualiza, pero no se solventan los problemas del reset normal. Entonces pruebo a grabar la BIOS desde la propia BIOS con audio, lo actualiza bien, pero siguen sin desaparecer los problemas de reset de las dos roms anteriores.

Es el problema del reset que te comenté antes.

- Todas las roms de los juegos van bien.

Pensé que podría haber algún problema con la grabación de la SPI desde impact, pero graba y verifica bien, sin errores. No se qué puede pasar. El test de RAM de la BIOS también es correcto. ¿Alguna idea? ¿Os pasa algo parecido a vosotros con estos .mcs?

No hay ningún problema. Todo lo que comentas es coherente. No funciona todo al 100%, pero sabemos lo que falla y lo que no.

Ya está. He arreglado el bug. También he podido comprobar que funciona el upgrade BIOS (el de machine y ESXDOS están sin probar, pero pueden funcionar). Muchas gracias por todo el betatesting que estás haciendo. Por cierto, pásame el set de ROMs que usas (con el generamcs.bat me vale), que lo pongo como oficial. El que uso yo es bastante limitado.

Para eso es esta fase de prototipos, betatesting a saco (aprovechando que desafortunadamente ahora tengo bastante tiempo libre).

Yo desgraciadamente sólo le puedo dedicar los fines de semana, ya que me ha salido trabajo desde hace una semana.

Voy a preparar el generamcs.bat y aa000.asm en condiciones (lo tengo alcgo chapucero) y te lo paso. De todas maneras visto el listado de roms que has puesto, debajo te comento más.

He creado un listado de ROMs lo más extenso posible y lo he subido al repositorio. Si veis que falta alguna importante me lo decís y actualizo la lista. Este mismo listado está en el repositorio, en firmware/roms/listadoROMs.txt

Genial! Cuanto más completo mejor.

Faltan algunas, que voy a preparar para añadirlas a la lista, los tengo por aquí por el disco duro (pentagon, timex 2068, etc) . Además, si te parece bien, puedo calcular todos los checksums de los taps resultantes y añadirlos al txt para el que quiera meterlos al .asm de forma mucho más rápida.

Perfecto, muchas gracias. Yo el hash que le he puesto es el que incluye el formato ZIP (creo que es ALDER32) que no tiene nada que ver con el CRC16 que usamos en el firmware. Pero tienes razón, una columna con el CRC del firmware sería lo suyo en este listado.

Por cierto, al margen de esto, algún consejo para sintetizar más rápido? Para cada pequeño cambio que hago en el vhdl del teclado (a lo loco, porque no me entero ni de lo que veo) se tira más de 10 minutos para sintetizar y luego algún minuto más para generar el bit... y lo estoy haciendo en un i5 4690k, que no es precisamente lento. Algo se tiene que poder hacer para no esperar tanto entre prueba y prueba...

Cómprate un ordenador más potente La síntesis es así de lenta, a lo mejor McLeod te puede dar algún consejillo para que haga una síntesis menos óptima pero más rápida.

[Quest]

Gracias por responder a todo tan rápido

- Con cualquier rom y Esxdos activado, el menú NMI no sale, se cuelga el ZX-UNO. Sin embargo la inicialización de ESXDOS parece ir bien, reconoce la SD, partición, etc. Si intentas usar algún comando de ESXDOS (por ejemplo .ls), da: "C SIN SENTIDO EN BASIC, 0:1".

Esto es porque todas tienen DisableNMI excepto "ZX +3e DivMMC". Anteriormente esto lo hacíamos manualmente desde la BIOS. La opción sigue ahí, pero por defecto está en Auto, así que en cada ROM por separado se decide si se activa o no la NMI. Fíjate en las constantes de aa000.asm y en el primer parámetro de GenRom por si quieres cambiarlo.

Precisamente para descartar eso que dices, forcé a Enabled las dos opciones de divMMC en la BIOS, para todas las roms, con idéntico resultado. Además, como digo, pasa en todas las las roms, incluida la del ZX +3e divMMC, y además insisto en que los comandos ESXDOS tampoco funcionan (los del puntito). Lo de las constantes del .asm y el parámetro de GenRom ya lo sabía y lo había tenido en cuenta. Además, como decía más abajo, grabando en bios el esxdos via audio solucionaba el problema.

- Pruebo a actualizar ESXDOS desde la BIOS con audio, lo actualiza y entonces ya funciona perfectamente ESXDOS. Si vuelvo a grabar el .mcs, otra vez ESXDOS corrupto.

Pues debes haber corrompido algo en tu .mcs. A mí sí que me funciona el ESXDOS (o lo mismo he metido la pata al subir tantas ROMs y renombrar algunas).

Para descartar eso, había grabado 2 .mcs que no hice yo, sino las que vienen en el svn, recién bajadas, y también con una copia que tenía en el disco duro que ya me había funcionado antes. De ahí mi preocupación.

Voy a seguir investigando. Mientras escribía este post había dejado grabando otra vez el último .mcs y ahora ni arranca el ZX-UNO, parpadea el led un par de veces y se queda fijo sin dar imagen voy a ver si lo desconecto todo, lo reconecto con cables nuevos y grabo otra vez el mcs limpio. Espero que no haya petado mi prototipo. Ahora me arrepiento de las pruebas que hice ayer con mi teclado virtual ps/2 metiendo señales a 5v, menos mal que mcleod me avisó y lo corregí, pero ya había hecho 3 o4 pruebas con el código viejo a 5v... espero que no petara nada a raíz de eso..

[antoniovillena]

Ya he empaquetado el portátil. Miro lo del esxdos durante la semana aunque pruebas reales sólo puedo hacer el sábado que viene. Es raro, lo que se graba con aa000 debe ser idéntico a hacerlo por bios y puerto ear.

Prueba una versión más antigua porque igual he metido yo la pata generando un mcs erróneo.

[mcleod_ideafix]

Por cierto, al margen de esto, algún consejo para sintetizar más rápido? Para cada pequeño cambio que hago en el vhdl del teclado (a lo loco, porque no me entero ni de lo que veo) se tira más de 10 minutos para sintetizar y luego algún minuto más para generar el bit... y lo estoy haciendo en un i5 4690k, que no es precisamente lento. Algo se tiene que poder hacer para no esperar tanto entre prueba y prueba...

Una de las razones por las cuales existe la plaquita addon con el Z80 es para que las pruebas se puedan sintetizar más rapidamente, al no tener que sintetizar e integrar todo el Z80 dentro de la FPGA (que es de las cosas que más tiempo consumen en ser posicionadas y ruteadas).

Aparte de eso, prueba con la última versión del ISE Webpack que hay (Vivaldo no, porque no soporta Spartan 6 que yo recuerde) a ver si han mejorado algo el tema del P&R.
Por lo demás, me temo que no hay mucho más que hacer. Con 10 minutos de síntesis y P&R ya nos podemos dar con un canto en los dientes, porque alguno de mis compañeros tarda 2 horas en sintetizar (circuitos más complejos en FPGA's más tochas, eso sí) y la gente que trabaja en estas cosas de forma más... ehm... profesional, puede llevarse días enteros para sintetizar un circuito

[garvidal]

Te comento lo mismo que he comentado a otros:

• El bitstream de un led o cualquiera de los de jepalza como el ladybug son autónomos. Es decir, cargas el .bit (o te generas un .mcs del mismo) y funciona.
• Sin embargo el ZX-Uno es más complejo. Además del bitstream en la SPI Flash se almacenan las ROMs y el firmware. Es necesario que cargues algún .mcs con todo incluido. Yo los tengo generados en firmware/roms/prom_es.mcs y en firmware/roms/prom_av.mcs pero puedes generarlos tú mismo a partir del bitstream que quieras con firmware/roms/generamcs.bat.
• Si te llega a funcionar, haz el test de memoria de la BIOS por si ha alguna soldadura mal hecha.
• El sistema del ZX-Uno es sencillo. Son 3 chips básicos: FPGA, SPI Flash y RAM. Los dos primeros los puedes testear con el cable JTAG. Si el cable JTAG te graba bien tanto los .bit como los .mcs pero luego te falla el sistema, lo más probable es una mala soldadura entre FPGA y RAM.
• Una vez te funcione todo lo anterior, ya sólo queda probar teclado, audio, EAR, tarjeta SD, video RGB y video compuesto. Cualquier fallo aquí se detecta fácilmente.
• Si se te jode el microUSB, Superfo tuvo la precaución de poner el conector J12.

Ok, gracias.

He cargado el bitstream de jeplaza con el spectrum a secas, y me ha funcionado, aunque el vídeo me lo sigue sacando mal, sale en blanco y negro con bastantes fallos, pero el spectrum "arranca" y además el teclado me funciona, lo que al menos me da muestras de que no voy mal encaminado. El tema del vídeo es lo que me preocupa, pero seguiré mirando que puede ser. Mi televisión es una televisión de tubo con mil años de antigüedad, y le estoy metiendo la imagen a través del euro conector, puede incluso ser el cable rca... bueno, y que me haya cepillado algún componente, aunque he comprobado todas las patillas del AD724 y su alimentación y parece estar bien.

Seguiré haciendo pruebas.

[Quest]

Ya he empaquetado el portátil. Miro lo del esxdos durante la semana aunque pruebas reales sólo puedo hacer el sábado que viene. Es raro, lo que se graba con aa000 debe ser idéntico a hacerlo por bios y puerto ear.

Prueba una versión más antigua porque igual he metido yo la pata generando un mcs erróneo.

Ok, yo también revisaré si haciendo un mcs propio con un esxdos bueno consigo que funcione (primero tengo que hacer que me arranque el ZX-UNO, que me lo ha dejado muerto la última grabación de mcs que he hecho y me temo lo peor...)

Por cierto, se me olvidó comentar que la ultimísima versión de bios que has subido al svn (creo que la que saca la rom de arranque al inicio) no va bien, en el manu "Main" hay corrupción de strings en la parte de abajo, donde deberia salir enable/disable salen otras cosas y al pulsar salen carácteres extraños. grabando una versiòn anterior eso no ocurre.

Ah! y otra cosa que me acabo de acordar. En la BIOS hay muchos carácteres del teclado que no hay manera de poder sacar. por ejemplo el del signo "+" entre otros. No se qué mapeado lleva pero da igual las combinaciones de teclas que pruebo, que no salen (salen otras letras a cambio que no corresponden.

Siento tanto post seguido y tanto rollo en cada uno, pero es que estoy aprovechando ahora que puedo usar el tiempo en esto para comentar todo lo que veo y probar todo lo que se me ocurre. Cuando consiga curro (y me recupere bien de salud) quizá tenga menos tiempo.

EDITO: por cierto garvidal, veo que ya lo tienes montado y funcionando genial, enhorabuena! ahora a testear a saco

[antoniovillena]

Garvidal prueba a presionar la fpga por el lado más cercano a la sram y alimentar justo después. Lo más probable es que sea una mala soldadura hacia el chip de sram. Si presionando funciona, repasa los pines de la zona que has presionado

[antoniovillena]

Quest, como veo que ya tienes manejo puedes pedirle a mcleod permisos de la carpeta firmware.

La BIOS lleva el mismo mapeado que el bitstream. Es básicamente un spectrum con acceso a 512k de RAM y a la spi flash, por lo que accede a las mismas 40 teclas que el gomas

[Quest]

La BIOS lleva el mismo mapeado que el bitstream. Es básicamente un spectrum con acceso a 512k de RAM y a la spi flash, por lo que accede a las mismas 40 teclas que el gomas

Ya, pero tu ve a la BIOS, a renombrar una rom, y pulsa, por ejemplo, SYMBOL+K (para conseguir un signo "+") y te sale una "p". Si pulsas el "+" del teclado numérico, lo mismo, sale una "p". Cuando arrancas con una rom de spectrum, ahí si que sale bien el carácter, no en la BIOS. Por eso lo decía. Pasa con más caracteres.