Avances en el desarrollo del ZX-Uno

[superfo]

"A question for those who have the ZX-one running. You have out there some keyboard that supports both USB and PS/2? It is to verify that the PS/2 also works with these keyboards. If it does not, we would have to make some changes in the design, since with the current prototype we can not send information to the keyboard, only to receive."

## Yes, I have keyboard that support both USB and PS2 and it works with ZX-Uno.
At beginning while I did pcb layout, I thought about use i/o pin for PS2 but I thought it may complicate to use FPGA send command out.
That's why I use only input pin for PS2 (also need to save i/o pin for edge connector)


"I am purchasing this for less than 4 euros:

http://www.ebay.com/itm/321288805822"

## Molstly mini keyboard doesn't have Right-Ctrl key, we may have another set of keyboard that use Left-Ctrl key as SYMBOL key.
Also mini keyboard has numeric keys (0-9) at the middle group of letter keys, some keyboard turn it on when power up and we cannot turn it off.

[antoniovillena]

Thank you superfo.

Estoy sopesando el cambiar de FPGA a una XC6SLX9. La razón está en los problemas que me están dando los pines IP (sólo entrada) de la FPGA actual. La nueva FPGA aunque tendría menos pines disponibles para el usuario (102 en lugar de 108), son todos entrada/salida. En la práctica esto supone retrasar el proyecto, ya que necesitamos un segundo prototipo.

[TallerSeverino]

¿Paramos de soldar entonces?

[antoniovillena]

¿Paramos de soldar entonces?

No, seguid soldando. Primero tengo que estudiarlo, pero en principio las mejoras serían:

• Posibilidad de enviar comandos al teclado: encender los leds, cambiar modos, etc...
• Los pines del DB9 también podrían valer como salida. Esto para el Spectrum no tiene mucha utilidad, pero se podrían sintetizar otros proyectos como el fpgaarcade con un conversor DB9-DB15 (salida VGA).
• Todos los pines del puerto de expansión son bidireccionales, con la FPGA actual hay 9 que son sólo entrada.
• En la nueva FPGA caben más cosas (tiene un número mayor de puertas lógicas equivalentes).
• El precio es prácticamente el mismo

-- Actualizado 20 Mar 2014, 17:28 --

Las desventajas son:

• El engorro que supone el cambio de FPGA: recompilar el código, mantener 2 versiones distintas...
• Esta nueva FPGA se come más SPI Flash (principalmente debido a la mayor BRAM), por lo que deja menos slots disponibles (de 16K) para almacenar ROMs. Si antes cabían 21, ahora caben 11. Un slot sirve para un modelo 48K, para uno 128K necesitamos 2 slots y para los +2A hacen falta 4.

[mcleod_ideafix]

Estoy sopesando el cambiar de FPGA a una XC6SLX9. La razón está en los problemas que me están dando los pines IP (sólo entrada) de la FPGA actual. La nueva FPGA aunque tendría menos pines disponibles para el usuario (102 en lugar de 108), son todos entrada/salida. En la práctica esto supone retrasar el proyecto, ya que necesitamos un segundo prototipo.

¿Y una FPGA con encapsulado PQ208? ¿La SLX9 tiene suficiente capacidad para albergar todo el diseño? Tiene más elementos lógicos, sí, pero menos slices, y no estoy seguro de si se pueden compartir funciones en el mismo slice. Quiero decir: en la Spartan 3, se usan slices completos, los "llenes" o no con lógica. Por otra parte... ¿lo de los pines de entrada es el único problema? ¿Cuántos pines de I/O crees que necesitamos para desarrollar un slot de expansión? No tantos como crees

Hay que sacar afuera, para un slot de expansión, las siguientes señales (así de memoria):
16 líneas de bus de direcciones: sólo salida
8 líneas de datos: entrada/salida
10 señales de control de solo salida
4 señales de control de solo entrada

Para el expansor de entrada/salida, ya había pensado en serializar alguna de estas señales: en concreto, el bus de direcciones. En lugar de necesitar 16 líneas de E/S, sólo necesito 4: un reloj de 56MHz, una señal de inicio de cuenta, y dos señales por donde irían los 16 bits (8 + 8) en fila india. A la salida, una CPLD se encarga de des-serializar las señales y volver a sacar los 16 bits del bus de direcciones. A la frecuencia indicada, puedo cambiar el estado del bus a una frecuencia efectiva de 7MHz, el doble de la frecuencia de reloj del Z80.

[antoniovillena]

¿Y una FPGA con encapsulado PQ208?

Eso se lo tendríamos que preguntar a Superfo, porque no sé si va a caber en la placa. El TQFP144 son 22mm de lado (484mm2) mientras que el PQFP208 son 30.60mm (936mm2). Estamos hablando de casi el doble de área.

¿La SLX9 tiene suficiente capacidad para albergar todo el diseño? Tiene más elementos lógicos, sí, pero menos slices, y no estoy seguro de si se pueden compartir funciones en el mismo slice. Quiero decir: en la Spartan 3, se usan slices completos, los "llenes" o no con lógica.

Más capacidad tiene seguro, pero no sabría decirte. Según la métrica de Xilinx, que tiene en cuenta la mayor complejidad de la arquitectura LUT, la Spartan 6 tiene un equivalente a 9,152 puertas, frente a las 5,508 puertas de la Spartan 3E. Supuestamente tiene un 66% más de capacidad, pero personalmente no creo que sea tanta la diferencia (a lo mejor un 30%), ya que prácticamente tienen el mismo precio (la Spartan 6 es unos $0.50 más cara). Lo mejor que puedes hacer es comprobarlo por tí mismo, compilando el código que tienes para la Spartan 6 y viendo los recursos utilizados.

Por otra parte... ¿lo de los pines de entrada es el único problema?

Básicamente sí, aunque el cambio también conlleva otras ventajas (no tan necesarias, claro).

¿Cuántos pines de I/O crees que necesitamos para desarrollar un slot de expansión? No tantos como crees

Pues cuando hice las cuentas con los que hay ahora estamos muy ajustados. Tuve en cuenta el multiplexado del bus de direcciones y el sentido de las señales. Lo que hay ahora son 36 señales, 27 de ellas de entrada/salida y las 9 restantes de sólo entrada.

Hay que sacar afuera, para un slot de expansión, las siguientes señales (así de memoria):
16 líneas de bus de direcciones: sólo salida
8 líneas de datos: entrada/salida
10 señales de control de solo salida
4 señales de control de solo entrada

Para el expansor de entrada/salida, ya había pensado en serializar alguna de estas señales: en concreto, el bus de direcciones. En lugar de necesitar 16 líneas de E/S, sólo necesito 4: un reloj de 56MHz, una señal de inicio de cuenta, y dos señales por donde irían los 16 bits (8 + 8) en fila india. A la salida, una CPLD se encarga de des-serializar las señales y volver a sacar los 16 bits del bus de direcciones. A la frecuencia indicada, puedo cambiar el estado del bus a una frecuencia efectiva de 7MHz, el doble de la frecuencia de reloj del Z80.

Yo había tenido en cuenta una reducción de 16 a 9 en el bus de direcciones. Con esto que propones (16 a 4) ganamos 5 señales más, siempre y cuando no haya problemas de ruído. Ten en cuenta que tenemos una placa de 2 caras, por muy bien que esté diseñada va a dar más problemas que una de 4 a medida que tengamos frecuencias altas.

Para mí es un follón tener que pedir de nuevo las PCBs y los componentes para hacer un segundo prototipo. Tal y como está ahora la cosa funciona, tenemos un bus de expansión "posible", funciona con teclados duales USB-PS/2 (aunque no podemos enviar nada al teclado) y al DB9 sólo le podemos enchufar un joystick. Creo que lo mejor es que pruebes a compilar el diseño y decidas tú mismo si merece la pena o no. Yo iré mirando modelos de 208 pines a ver si hay alguno que no se nos va de precio.

-- Actualizado 20 Mar 2014, 21:58 --

Mirando opciones, tenemos:

• XC3S250E, 144 pines por $6.98 (la que lleva el prototipo actual)
• XC3S500E, 208 pines por $7.21
• XC6SLX9, 144 pines por $7.40
• XC6SLX16, 256 pines por $9.76, el inconveniente es que es BGA por lo que necesitamos una PCB de 4 capas

[mcleod_ideafix]

Mirando opciones, tenemos:

• XC3S250E, 144 pines por $6.98 (la que lleva el prototipo actual)
• XC3S500E, 208 pines por $7.21
• XC6SLX9, 144 pines por $7.40
• XC6SLX16, 256 pines por $9.76, el inconveniente es que es BGA por lo que necesitamos una PCB de 4 capas

Pues si tuviera que votar, votaría por la XC3S500E de 208 pines. No sólo acabarían los problemas de pines de E/S que nos faltan, sino también los problemas que estoy teniendo en el P&R de warnings por no poder optimizar la lógica de forma adecuada, por estar acercándonos peligrosamente al límite de recursos (estamos al 89% en el test12).

Por otra parte, la familia Spartan 6 tiene una cosa golosísima: el hecho de que se puede implementar en ella señales diferenciales de muy alta velocidad, a.k.a. salida HDMI, como en la versión del clon de Josepf Laszlo (lo habré escrito mal fijo):
http://joco.homeserver.hu/zxpipi/

NOTA: la suya es una Spartan 6 LX45.

[antoniovillena]

De entrada te puedo decir que la LX45 se nos sale de presupuesto, $35.19, que sería 5 veces lo que cuesta la FPGA actual.

Que quepa seguro tenemos la LX9, lo que no sé es si cabrá es el HDMI y la circuitería asociada (conector, chip pequeño de 8 pines que hace de conversor de niveles y pasivos correspondientes, que son unos cuantos). Pero supongo que haciendo un esfuerzo se podrá.

En cuanto a los 208 pines del XC3S500E, a simple vista parece chungo de encajar, pero lo mismo Superfo se lo come con papas.

No se trata de votar, sino de decidir (lo dejo en tus manos). El único requisito que te pido es la FPGA no sobrepase la barrera de los $10. Tampoco te tienes que cerrar en las opciones que te he puesto, seguro que hay muchas más.

[aowen]

Las desventajas son:

• El engorro que supone el cambio de FPGA: recompilar el código, mantener 2 versiones distintas...
• Esta nueva FPGA se come más SPI Flash (principalmente debido a la mayor BRAM), por lo que deja menos slots disponibles (de 16K) para almacenar ROMs. Si antes cabían 21, ahora caben 11. Un slot sirve para un modelo 48K, para uno 128K necesitamos 2 slots y para los +2A hacen falta 4.

Are you saying the ROMS are stored permanently in Flash RAM in the FPGA? I suppose if it's Flash you don't want to continually LOAD them at boot time, although in practice that should still be safe. The 128K really only needs one slot as a three byte change to the Editor ROM will enable it to use the original BASIC ROM in place of the 128 version. Unless you're planning on supporting the 128 keypad that is. Of course in Chloe 280SE mode you can LOAD the ROMs in software into volatile RAM.

¿Quieres decir que las ROMS se almacenan permanentemente en la Ram flash de la FPGA? Supongo que si es flash no querrías cargarlas (LOAD) continuamente en el arranque, aunque en la práctica eso debería de ser seguro(safe). El 128K en realidad sólo necesita un slot, ya que un cambio de 3 bytes al Editor ROM permitiría usar la ROM BASIC en lugar de la versión 128. A no ser que estéis pensando en que el teclado del 128 se vaya a usar. Por supuesto, en Chloe 280SE podéis cargar (LOAD) las ROM en software dentro de la RAM volátil.

[antoniovillena]

Are you saying the ROMS are stored permanently in Flash RAM in the FPGA? I suppose if it's Flash you don't want to continually LOAD them at boot time, although in practice that should still be safe. The 128K really only needs one slot as a three byte change to the Editor ROM will enable it to use the original BASIC ROM in place of the 128 version. Unless you're planning on supporting the 128 keypad that is. Of course in Chloe 280SE mode you can LOAD the ROMs in software into volatile RAM.

ROMs are stored in another chip (SPI Flash W25X40), that is the same where the FPGA Bitstream is stored.

-- Actualizado 21 Mar 2014, 18:32 --

Subo los esquemáticos v0.13 tanto de la FPGA 250e como de la 500e. Me falta por crear los de la LX9