PiZx: Clon barato de spectrum con FPGA (WIP)

[Hark0]

Oki Doki... para lo que se tercie en "paper"...

[jotego]

A ojo, podría decir que en una Spartan 3-200K cabría sin demasiados problemas:
- Un Spectrum
- Un ZX80/ZX81
- Un Jupiter ACE

Probablemente (aunque para algunos habría que implementar sigma-delta en el video y eso podría funcionar... o no):
- Un Amstrad CPC (pero sin el +)
- Oric 1/Atmos
- Dragon 32/64
- Apple I/II
- VIC-20

A este tipo de cosas me refiero cuando hablo de especificaciones de la placa. Fijaos como hemos pasado de tener un diseño "cerrado" a estar hablando de meter más equipos. Y cuando uno habla de más equipos toca tratar otros temas:

-¿Cómo conmutar de uno a otro? ¿Con unos interruptores DIP? ¿Con un menú en pantalla?
-¿Estarán todos en la misma implementación o se configurará la FPGA de forma distinta en cada arranque?

Y otras posibles características del sistema:

-Botón turbo para la CPU, que suba el Z80 a 7MHz, por ejemplo
-Botón tortuga, que reduzca un 20% la velocidad del sistema (¡para esos momentos difíciles!)
-Conmutador 50/60Hz
-Alimentación por USB y soporte blutooth para enchufar al USB de la televisión y jugar sin cables
-Interruptor de pausa, que corta los relojes a la CPU y mantiene sólo el refresco de vídeo
-Interfaz RS232 para el micro de 8 bits
-Volcado de memoria y recuperación del estado
-Posibilidad de escritura a la cinta/disco virtual, para poder grabar programas

Algunas cuestiones, que quizá ya las tenga Antonio resueltas:

-¿Cómo se hará el controlador de USB? ¿Será un microcontrolador PIC o se hará como parte de la FPGA?
-¿Y el de la FAT de la tarjeta SD?

[retrolab]

Me parece muy interesante el proyecto. Aunque no he trabajado nunca con FPGA ni este tipo de placas, creo que me puede interesar aprender y, si no se dispara excesivamente de precio el invento, posiblemente me apunte (con el proyecto del Jupiter Ace me quedé con las ganas). Lo que me preocupa principalmente es la soldadura de componentes SMD ya que no la he realizado nunca y si la placa los llevase ya montados o toda ella estuviese montada, me resultaria menos problemático.
Respecto al tema de soporte de múltiples sistemas, pienso que estaria bien, siempre y cuando no resultara muy difícil conmutar de sistema ni complicara excesivamente el proyecto.

[radastan]

Yo sigo insistiendo que el sobrecosto de pedir la placa ya montada es mucho mejor, son muy pocos en el foro los que tienen un soldador adecuado para SMD y yo lo pasé canutas con el mierdecilla del clon del ZX Spectrum (el que usábamos para el vídeo).

Pienso lo mismo que tú. Es más si se incluye un kit: fuente de alimentación, carcasa, manual, cable rca, cable sonido, cable EAR, tarjeta SD con juegos de WOS precargados y manual... listo para enchufar seguro que se apuntaba mucha gente más.

¿leo manual?

Yo hago el manual PDF cuando esté terminado, con sección BASIC incluida.

Incluso una imagen para volcar a SD con un kit para todo tipo de públicos y software gratuito (juegos y demos de la escena, kits de desarrollo, etc).

[antoniovillena]

A este tipo de cosas me refiero cuando hablo de especificaciones de la placa. Fijaos como hemos pasado de tener un diseño "cerrado" a estar hablando de meter más equipos. Y cuando uno habla de más equipos toca tratar otros temas:

Pero eso no son especificaciones, eso es un ¿qué podríamos ejectuar en la placa? No te lo tomes todo al pie de la letra, aunque físicamente se puedan meter algunas máquinas, si no hay descripciones exactas de cómo funcionan no hay nada que hacer, por muy simple que sea la máquina. Bueno sí, se podría hacer algo pero nunca sería exacto a nivel de ciclo.

-¿Cómo conmutar de uno a otro? ¿Con unos interruptores DIP? ¿Con un menú en pantalla?

En el caso de Spectrum yo haría un interfaz parecido al ZXMMC pero que vaya por otro puerto, para comunicarme directamente con la SPI Flash. Sería un programa actualizador de firmare que se puede cargar vía cinta o vía tarjeta SD, aunque casi descartaría la cinta. Habría que flashear 146K de configuración (para todas las máquinas) más los específicos de la máquina si cargamos la ROM en la SPI Flash. En caso de un +2A serían 146K+64=210K. Se debe de cargar en un mínimo de 2 bloques (sólo tenemos 128K de RAM), con el peligro de que si cargo un bloque y se resetea hay que enviar la placa a reflashear a alguien que tenga el platform cable de xilinx.

Pero vamos que esto no está hecho aún ni definido cómo vamos a hacerlo, si a alguien se le ocurre un método más sencillo...

-¿Estarán todos en la misma implementación o se configurará la FPGA de forma distinta en cada arranque?

No, la FPGA es pequeñita y sólo cabe una máquina a la vez. He leído por algún datasheet que se puede hacer multiboot, es decir, tener en la SPI Flash varias configuraciones y poder arrancar con una u otra aunque no sé exactamente cómo se hace. De todas formas la SPI Flash es de 512K, y cada máquina ocupa 146K más la ROM, así que este sistema sólo valdría para meter 2 máquinas a la vez sin tener que reflashear.

Y otras posibles características del sistema:

-Botón turbo para la CPU, que suba el Z80 a 7MHz, por ejemplo
-Botón tortuga, que reduzca un 20% la velocidad del sistema (¡para esos momentos difíciles!)

Nada de botones extra, para eso tenemos el teclado PS/2. En las síntesis que estoy haciendo tengo el F1 para Reset y el F2 para en NMI. Así que en principio estas características se pueden introducir mediante programación, sin tener que retocar la placa.

-Conmutador 50/60Hz

Esto se puede configurar en el chip que pasa a video compuesto, y requiere otro cristal. Podemos poner 2 cristales y varios jumper para pasar de PAL a NTSC, pero casi todo el mundo va a usarlo en un único sistema, y la mayoría PAL. Así que se pueden poner unos pads para hacer más fácil configurarlo en NTSC: sería cambiar el cristal y soldar dichos pads.

-Alimentación por USB y soporte blutooth para enchufar al USB de la televisión y jugar sin cables

No me parece buena idea complicar en exceso la placa. Todo esto se puede añadir como extensión. Y a parte que poner un puerto USB es sencillo a nivel de hardware, pero a ver quién es el que se atreve a programarlo en Verilog o VHDL.

-Interruptor de pausa, que corta los relojes a la CPU y mantiene sólo el refresco de vídeo

Lo mismo que antes, puedes mapearlo esta función en el teclado sin cambiar el hardware.

-Interfaz RS232 para el micro de 8 bits

Sería mucho más plausible que el USB, pero de nuevo complicaríamos la placa, se necesitan chip específicos para adaptar los voltajes y se encarecería el precio final.

-Volcado de memoria y recuperación del estado
-Posibilidad de escritura a la cinta/disco virtual, para poder grabar programas

Esto ya cae dentro de la programación de cada sistema y se podrá hacer en el caso de que sobren recursos en la FPGA tras haber sintetizado toda la máquina. Yo me conformaría con ver funcionar algo que no sea un Spectrum o un Jupiter Ace, pero vamos que sí, que es factible.

Algunas cuestiones, que quizá ya las tenga Antonio resueltas:

-¿Cómo se hará el controlador de USB? ¿Será un microcontrolador PIC o se hará como parte de la FPGA?
-¿Y el de la FAT de la tarjeta SD?

¿Quién ha hablado de USB o de PIC? Repito, el hardware será tan sencillo como el que tiene la MOD-VGA+circuito de Video+circuito EAR+conector SD, no habrá nada más a no ser que sea super útil y super fácil de hacer.

En cuanto al FAT de la tarjeta eso pertenece a una capa de más alto nivel, vamos que con VHDL o Verilog tu defines sólo el interfaz ZXMMC, de lo otro ya se encarga el SO o la ROM.

[Hark0]

Yo hago el manual PDF cuando esté terminado, con sección BASIC incluida.

Incluso una imagen para volcar a SD con un kit para todo tipo de públicos y software gratuito (juegos y demos de la escena, kits de desarrollo, etc).

Quédate con el tema SD y déjame lo del manual, plis....

[antoniovillena]

Me parece muy interesante el proyecto. Aunque no he trabajado nunca con FPGA ni este tipo de placas, creo que me puede interesar aprender y, si no se dispara excesivamente de precio el invento, posiblemente me apunte (con el proyecto del Jupiter Ace me quedé con las ganas). Lo que me preocupa principalmente es la soldadura de componentes SMD ya que no la he realizado nunca y si la placa los llevase ya montados o toda ella estuviese montada, me resultaria menos problemático.
Respecto al tema de soporte de múltiples sistemas, pienso que estaria bien, siempre y cuando no resultara muy difícil conmutar de sistema ni complicara excesivamente el proyecto.

La idea es lanzar un producto fácil de usar, no tienes porqué saber ni lo que es una FPGA. El cambio de sistema es complicado a nivel de programación, pero a nivel de usuario es sólo ejecutar un programa y esperar unos segundos. Y tiene el inconveniente de que si hay un fallo (un corte de alimentación durante el proceso) la FPGA no arranca y hay que tener un cable especial para volverla a la vida. En principio nos interesa la placa ya montada y lista para usar, no habría que soldar nada.

[mcleod_ideafix]

-¿Cómo conmutar de uno a otro? ¿Con unos interruptores DIP? ¿Con un menú en pantalla?
-¿Estarán todos en la misma implementación o se configurará la FPGA de forma distinta en cada arranque?

Creo que la ROM de una Spartan 3AN no da para mucho. Además del bitstream hay que meter la ROM del equipo. Como mucho como mucho, creo que podrían caber dos diseños. No sé si es posible elegir de alguna forma cuál de los diseños de una platform ROM se elige para cargar, a menos que lo haga un dispositivo externo, tal como un PIC.

-Botón turbo para la CPU, que suba el Z80 a 7MHz, por ejemplo
-Botón tortuga, que reduzca un 20% la velocidad del sistema (¡para esos momentos difíciles!)
-Conmutador 50/60Hz
-Interruptor de pausa, que corta los relojes a la CPU y mantiene sólo el refresco de vídeo

Son cosas asumibles, y sólo ocuparán 3 GPIO's de la FPGA. Yo añadiría ahí un botón de reset, pero no reset de la FPGA, sino reset del diseño.

-Alimentación por USB y soporte blutooth para enchufar al USB de la televisión y jugar sin cables

Alimentación por USB creo que es lo que se está pensando. Bluetooth... creo sinceramente que no pega en este tipo de cosas, además de que encarecería el aparato cosa mala.

-Interfaz RS232 para el micro de 8 bits

¿Qué microordenador de 8 bits de la época usaba activamente el RS232? No logro recordar ninguno. Además que eran muy pocos los que tenían RS232 incorporado de fábrica.

-Volcado de memoria y recuperación del estado
-Posibilidad de escritura a la cinta/disco virtual, para poder grabar programas

En el caso del Spectrum, de eso puede encargar ResiDOS, si el clon implementa alguna de las interfaces compatibles con este SO.

-¿Cómo se hará el controlador de USB? ¿Será un microcontrolador PIC o se hará como parte de la FPGA?

Hacer un controlador master en la FPGA se comería bastantes recursos. Además... ¿controlador USB para qué? El teclado va por PS/2 y el joystick por el tradicional DB9. De todas formas, en el supuestísimo caso de que se quisiera USB maestro, creo que es más práctico tirar por los chips de FTDI, en concreto, el VNC1L, que es un controlador USB host que implementa ya directamente el protocolo HID, además de poder "hablar" directamente con pendrives que tengan formato FAT.

-¿Y el de la FAT de la tarjeta SD?

Si el clon de Spectrum que se haga incluye un DivIDE y permite instalar ResiDOS o ESX-DOS, la ROM del DivIDE ya tiene el soporte necesario. Si lo que se implementa es soporte para un +3E, la tarjeta SD no irá en FAT, sino en +3DOS.

Esta lista de los deseos hace que el chisme empiece a parecerse peligrosamente a un entrenador FPGA. Si la intención (lo pone en el título del hilo) es hacer un clon barato de Spectrum, hemos de ceñirnos a lo que necesitaría un Spectrum para poder ser implementado. Si después resulta que el cacharro puede de forma nativa albergar otras cosas que no sean un Spectrum, pues tanto mejor.

Yo, en mi "lista de los deseos" pondría:
- Salida RGB de más de 1 bit por color primario. ULAplus ya está ahí, mola mucho, y es de Spectrum Sería usar 3 bits por color primario, justo como hace el MOD-VGA.
- FPGA con encapsulado TQ144. Sigue siendo soldable por uno mismo (no es BGA), tienes más GPIO's, e decir más posibilidades de expansión.
- Un par de LED's SMD: son muy útiles cuando estás depurando el diseño de la placa y no quieres ir andando con osciloscopios para un lado y otro: metes una copia de la señal a depurar en uno de los leds, y miras si parpadea o no. Si la señal es muy rápida (un reloj por ejemplo) pues metes un divisor de frecuencia (un contador, vamos) hasta que la frecuencia resultante sea del orden de muy poquitos hercios, para que se vea bien si parpadea o no.

Una nota de atención: OJO con la Spartan 3AN: la única que existe con encapsulado TQ144 es la XC3S050AN, que es claramente insuficiente para este clon. La siguiente es la 200, que ya es encapsulado BGA. Eso significa que no se podría hacer un prototipo con ella, además de que BGA implica casi siempre una PCB de 4 capas. La 3A tiene opción de encapsulado VQ100 (también soldable a mano) para la 200. La Spartan 3E puede usarse hasta la 500 en encapsulado VQ100 (ésta no tiene la versión 200 sino la 250, y es por ejemplo la FPGA que está en el OLS). Por último, la Spartan 3 (sin letra) tiene opción de 200 y 400 en TQ144. Habrá que ver por precio y recursos cuál nos conviene. También decir que las familias 3 y 3E disponen de diodos de clamping en sus entradas, lo que significa que estas FPGA's pueden hacerse tolerantes a 5V sin más que intercalar una resistencia de unos 270 ohmios en serie con las GPIO's que vayan a recibir señales TTL de 5V desde el exterior. Las familias 3A y 3AN no disponen de esta característica, así que habría que usar "level shifters" para conseguir la tolerancia a 5V.

Sobre los encapsulados:
- VQ100: ocupa menos "real estate" en la placa, pero da menos GPIO's (alrededor de 60).
- TQ144: obviamente ocupa más, pero tienes más GPIO's (alrededor de 100).
No puedes intercambiar FPGA's de distintas familias aunque tengan la misma huella. Es decir, no puedes usar una Spartan 3E si el diseño se ha hecho para Spartan 3A, aunque la huella sea la VQ100. Sí que puedes usar la misma huella para distintos dispositivos de la misma familia. Esto es: si haces el diseño para Spartan 3E con una huella VQ100 puedes elegir más tarde si vas a poner una 100, 250 o 500 (obviamente, en versión cuyo patillaje sea VQ100).

[Hark0]

Me parece muy interesante el proyecto. Aunque no he trabajado nunca con FPGA ni este tipo de placas, creo que me puede interesar aprender y, si no se dispara excesivamente de precio el invento, posiblemente me apunte (con el proyecto del Jupiter Ace me quedé con las ganas). Lo que me preocupa principalmente es la soldadura de componentes SMD ya que no la he realizado nunca y si la placa los llevase ya montados o toda ella estuviese montada, me resultaria menos problemático.
Respecto al tema de soporte de múltiples sistemas, pienso que estaria bien, siempre y cuando no resultara muy difícil conmutar de sistema ni complicara excesivamente el proyecto.

La idea es lanzar un producto fácil de usar, no tienes porqué saber ni lo que es una FPGA. El cambio de sistema es complicado a nivel de programación, pero a nivel de usuario es sólo ejecutar un programa y esperar unos segundos. Y tiene el inconveniente de que si hay un fallo (un corte de alimentación durante el proceso) la FPGA no arranca y hay que tener un cable especial para volverla a la vida. En principio nos interesa la placa ya montada y lista para usar, no habría que soldar nada.

Suelto una burrada... ¿jumpers?

[antoniovillena]

Yo, en mi "lista de los deseos" pondría:
- Salida RGB de más de 1 bit por color primario. ULAplus ya está ahí, mola mucho, y es de Spectrum Sería usar 3 bits por color primario, justo como hace el MOD-VGA.

Totalmente de acuerdo.

- FPGA con encapsulado TQ144. Sigue siendo soldable por uno mismo (no es BGA), tienes más GPIO's, e decir más posibilidades de expansión.

Esa era mi idea, pero por lo que comentas más abajo no tenemos tanta libertad en cuanto a encapsulado.

- Un par de LED's SMD: son muy útiles cuando estás depurando el diseño de la placa y no quieres ir andando con osciloscopios para un lado y otro: metes una copia de la señal a depurar en uno de los leds, y miras si parpadea o no. Si la señal es muy rápida (un reloj por ejemplo) pues metes un divisor de frecuencia (un contador, vamos) hasta que la frecuencia resultante sea del orden de muy poquitos hercios, para que se vea bien si parpadea o no.

¿Qué te parece si el led es RGB?. Aparte de para depurar podemos utilizarlo en las configuraciones, por ejemplo si le asignamos el mismo color que el borde podemos saber cuando está leyendo un tono guía, o datos o pausa.

Una nota de atención: OJO con la Spartan 3AN: la única que existe con encapsulado TQ144 es la XC3S050AN, que es claramente insuficiente para este clon. La siguiente es la 200, que ya es encapsulado BGA. Eso significa que no se podría hacer un prototipo con ella, además de que BGA implica casi siempre una PCB de 4 capas. La 3A tiene opción de encapsulado VQ100 (también soldable a mano) para la 200. La Spartan 3E puede usarse hasta la 500 en encapsulado VQ100 (ésta no tiene la versión 200 sino la 250, y es por ejemplo la FPGA que está en el OLS). Por último, la Spartan 3 (sin letra) tiene opción de 200 y 400 en TQ144. Habrá que ver por precio y recursos cuál nos conviene. También decir que las familias 3 y 3E disponen de diodos de clamping en sus entradas, lo que significa que estas FPGA's pueden hacerse tolerantes a 5V sin más que intercalar una resistencia de unos 270 ohmios en serie con las GPIO's que vayan a recibir señales TTL de 5V desde el exterior. Las familias 3A y 3AN no disponen de esta característica, así que habría que usar "level shifters" para conseguir la tolerancia a 5V.

Sobre los encapsulados:
- VQ100: ocupa menos "real estate" en la placa, pero da menos GPIO's (alrededor de 60).
- TQ144: obviamente ocupa más, pero tienes más GPIO's (alrededor de 100).
No puedes intercambiar FPGA's de distintas familias aunque tengan la misma huella. Es decir, no puedes usar una Spartan 3E si el diseño se ha hecho para Spartan 3A, aunque la huella sea la VQ100. Sí que puedes usar la misma huella para distintos dispositivos de la misma familia. Esto es: si haces el diseño para Spartan 3E con una huella VQ100 puedes elegir más tarde si vas a poner una 100, 250 o 500 (obviamente, en versión cuyo patillaje sea VQ100).

Sí sí, ya lo estoy viendo en los datasheets. No había caído. Si queremos más pines o bien tiramos de BGA y una PCB de 4 capas, o bien de otros modelos de FPGA, eso sí, tiene que tener un mínimo de 16 bloques de BRAM para que funcionen los diseños que estoy haciendo. Que por cierto tus diseños no los necesitan porque multiplexas la RAM en el tiempo simulando dos bancos.

-- Actualizado 30 Jul 2013, 12:08 --

La XC3S200 (a secas) es muy barata, unos $4.40 aquí:

http://www.aliexpress.com/item/XC3S200- ... 68387.html

Lo malo es que tiene 12 en lugar de 16 bloques BRAM, con lo que habría que tirar de tus diseños si queremos implementar modelos de 128K o más (necesitamos 2 bancos de memoria contenida, RAM 5 y 7).

-- Actualizado 30 Jul 2013, 12:12 --

Otra opción (con encapsulado de 144 pines) es la XC3S250E, pero cuesta casi el doble

http://www.aliexpress.com/item/Free-Shi ... 66384.html