Cacharreando con el prototipo 2 del ZX-Uno

[celestinox]

Hola. Feliz año nuevo.

Imagino que este es el hilo apropiado, ya que los anteriores sobre la ZXUNO v1 están cerrados, y creo que no es plan de abrir un nuevo hilo, ¿o quizás si?. Si el administrador lo considera oportuno, creo un hilo.

Me he hecho una PCB casera que ataca a un adaptador TQFP 144 a DIP de los chinos. Me he basado en el esquemático zxuno 0.13_250. La verdad es que el PCB es una chapucilla, pero mientras espero poder adquirir el ZXUNOv2 (estoy en la lista de la 3ª tanda) ,me distraigo cacharreando con esto. A ver si algún día esto me sirve para estudiar VHLD. La placa tiene pistas mas gruesas que las originales del ZXUNO por que es lo que puedo hacer con mi fresadora y ya que me defiendo un poco con Eagle me animé a hacerlo. Para poder enrutar he eliminado todo lo referente al bus de expasión, es decir todas las señales EXT***, por que doy por hecho que para funcione no son necesarias. La placa la he adaptado a los conectores de los que yo disponía, por tanto tiene diferentes conectores de audio, video , PS2 y alimentación.

Continúo, he ido soldando vías con hilo de 0,17 mm de diámetro, lo cual ha sido todo un sufrimiento ya que me han fallado muchas. Luego he soldado reguladores, microUSB, resistencias y LEDS. Finalmente la flash SPI, oscilador etc, es decir dejo para después el vídeo y la memoria RAM.

Con esto y tras comprobar que no hay cortos ni pistas comunicadas o cortadas (que algunas había) compruebo las alimentaciones y que llegan a los correctos pines de la FPGA y programo el test1. Todo correcto el led parpadea.
Como quiero seguir avanzando me animo a soldar en ad724, pero las resistencias que tengo para las señales RGB son del 5%, así que las uso. Tras completar la parte de vídeo, añado la RAM, y procedo a cargar el test2. Pruebo, y veo que la señal casi no se vé, la alimentación la tomo de un cargador de los chinos. Me doy cuenta de que no he colocado condensadores, así que sueldo todos los condensadores de alimentación. La cosa mejora bastante. Cojo otro modelo de cargador USB que hace menos ruido, y veo que la imagen mejora aún mas. Luego pruebo a alimentar desde una toma USB del pc y la imagen se ve mejor, se ve que algunos colores la carta de ajuste están algo saturados, imagino que si cambio las resistencias RGB a 1% esto mejorará.

Animado procedo a seguir con la carga del test3, y test4 que parecen responder bién. El problema viene con el test5 y siguientes, ya que algo tengo mal. Hace un efecto de pantalla negra y lineas verticales rojas muy similar al reset del spectrum48, pero luego cambian los colores y no veo la utilidad de testeo de mcleod_ideafix ni nada. Tras esperar un buen rato (unos 2 o 3 minutos) el patrón cambia con unas bandas verticales del tamaño de una columna de texto, negras y rojas.

¿a alguien se le ocurre algo? En cuanto pueda subo un video a youtube.

Un saludo.

[mcleod_ideafix]

¿a alguien se le ocurre algo? En cuanto pueda subo un video a youtube.

Un saludo.

Coge el código fuente del test5 y cárgalo en el ISE Webpak de Xilinx. En el fichero rom.v busca esta línea:

Código: Seleccionar todo

$readmemh ("ram128k_tester_hex.txt", mem, 0);

Y cambiala por esta otra:

Código: Seleccionar todo

$readmemb ("rom_tester_48k.txt", mem, 0);

Graba los cambios y dale a "Generate bitfile" para que haga de nuevo todo el proceso de síntesis, translate, map, place & route, y generación del bitfile. Carga el nuevo bitfile en la Spartan, a ver qué ves en pantalla.

[antoniovillena]

Supongo que tienes el mismo modelo de spartan 3 que en la v1. Lo más probable es que tengas mal soldado uno de los pines de la fpga que conectan con la RAM. Repásalos y si no mejora ya se nos ocurrirá otra cosa. Y pon fotos del invento, que tengo curiosidad por verlo

[celestinox]

Gracías por las respuestas.

este es el video:

Video PCB casero ZXUNO

mcleod haré lo que dices sobre el archivo de la ROM.

Como empezé a dudar de la FPGA, monté otro adaptador con otra FPGA. Obtengo el mismo fallo. Estoy pensando que hay algo en mi PCB.

[mcleod_ideafix]

Por lo que veo del test de relleno de memoria en tu video, la memoria no parece que esté bien soldada. Mira los pines del bus de direcciones. Cuando hagas el test5 con la ROM que te he puesto, lo podremos ver más claro (espero).

[celestinox]

Bien , he creado como me has dicho el .bit con ROM 48k




Me gustaría subir fotos, pero no tengo un servidor en el que alojarlas. Imagino que cada cual usa el suyo, y no hay uno compartido.

He revisado varias veces las lineas de datos y direcciones, por si hubiera alguna pegada (como ya me ha pasado entre xda10 y xd7 (creo) que son contiguas. Me falta comprobar que el esquema del zxuno y el mio de eagle no tengan diferencias en lo que respecta a las direcciones de datos y memoria (buses). Lo revisaré.

Un saludo.

[mcleod_ideafix]

Por lo que veo en el video, las líneas de datos están bien, pero las de direcciones no. ¿Puedes hacer una foto, que no video, a alta resolución, de lo que se ve en pantalla?
PD: cuando escribas un post, mira más abajo del cuadro de edición, que hay dos pestañas: Opciones y Subir adjunto. Mientras buscas un alojamiento para fotos, puedes usar esa opción. Admite ficheros gráficos y archivos ZIP.

[Pachuquin]

Celestinox, vaya currada. Eres un crack.

[celestinox]

Por lo que veo en el video, las líneas de datos están bien, pero las de direcciones no. ¿Puedes hacer una foto, que no video, a alta resolución, de lo que se ve en pantalla?
PD: cuando escribas un post, mira más abajo del cuadro de edición, que hay dos pestañas: Opciones y Subir adjunto. Mientras buscas un alojamiento para fotos, puedes usar esa opción. Admite ficheros gráficos y archivos ZIP.

La verdad es que se vé como en el vídeo, el tercio inferior de la pantalla cambia entre dos estados, y no parece que sea por que esté aplicandose atributo FLASH, por eso he hecho varias fotos.

Un saludo y gracias.

-- Actualizado 03 Ene 2015, 02:39 --

Supongo que tienes el mismo modelo de spartan 3 que en la v1. Lo más probable es que tengas mal soldado uno de los pines de la fpga que conectan con la RAM. Repásalos y si no mejora ya se nos ocurrirá otra cosa. Y pon fotos del invento, que tengo curiosidad por verlo

Unas fotos del engendro.

[mcleod_ideafix]

Vamos a ver:
Ahora mismo no tengo cabeza para hacer los cálculos, pero lo que tienes ahí es un fallo con el bus de direcciones. El bus de datos está bien.
Ahora bien: dado que la FPGA es la única que accede a memoria, el orden de los pines en el bus de direcciones en realidad es lo mismo. Quiero decir: que aunque hubieras conectado al revés los pines, y lo que en el ZX-Uno es XA0 en el tuyo fuera, qué se yo... XA15, y viceversa, el resultado sería el mismo.
Por lo que creo que tienes que concentrarte en buscar fallos de la siguiente forma:
- Usa en el test de la ROM, la tecla 1 para ver el patrón de memoria desde la memoria no contenida. ¿Se ve igual que el primero o cambia? Usa la tecla 1 de nuevo para volver al patrón original. Si hay cambios, sobre todo en los dos primeros tercios de la imagen, pon foto que veamos qué es.
- Comprueba, mirando tu esquemático, que todos los pines del bus de direcciones están conectados a pines en la FPGA en los que se espera que haya conexiones al bus de direcciones de la memoria. Dicho de otra forma: que el conjunto de pines de tu FPGA que se conecta al bus de direcciones de la memoria sea el mismo conjunto que usamos en el ZX-Uno. Fíjate que esto no quiere decir que la asignación pin FPGA <-> pin SRAM tenga que ser la misma. Puede ser distinta y aún así funcionaría.
- Si lo primero es correcto, busca cortes en las pistas entre cada uno de los pines de la FPGA y los pines de la SRAM (el bus de direcciones), y comprueba que todos los pines tienen conexión eléctrica
- En tu análisis descarta el bus de datos y el de control. Céntrate unicamente en el bus de direcciones

A la espera de lo que me digas sobre el punto 1, mis sospechas están en los pines del bus de dirección XA12 en adelante (XA12, XA13, XA14, etc)