Gameduino (o como meter un ZX Spectrum con ULAplus en...)

[mcleod_ideafix]

...hacer lo mismo que ha hecho el autor para programar el Gameduino, que es metiendo el firmware como parte del propio sketch o programa de Arduino (o al menos, eso es lo que parece).

Mi idea es similar: implementar un puerto SPI que "hable" con la flash, accesible desde el Spectrum, y que sea el propio Spectrum el que actualice la flash. Eso sí: la primera programación tendrá que ser desde el JTAG.

[mike_01]

Creo que el súmmum del Gameduino sería llegar a algo como el Multiple Classic Computer (MCC), que está basado en FPGA y es capaz de implementar hasta ¡¡5 sistemas diferentes!! , incluyendo el ZX.

Me ha sorprendido encontrarme algo tan versátil como esto. Lo malo es que no está al alcance de la mayoría de los bolsillos .

[mcleod_ideafix]

...está basado en FPGA y es capaz de implementar hasta ¡¡5 sistemas diferentes!! , incluyendo el ZX.

Veamos: con los recursos del Gameduino, y la opción de memoria más simple (SRAM de 512KB), se puede implementar:
- ZX Spectrum 48K/128K
- ZX80/ZX81
- Jupiter ACE
Y aunque no he hecho estos cores (así que no puedo dimensionarlos bien), creo que cabrían:
- Sam Coupé
- Apple II
- Atari 2600
- Commodore VIC20
- Oric Atmos
- Amstrad CPC
- Dragon 32/64

Del Gameduino, lo único que me fastidia un poco es que no queda practicamente ningún pin libre... pero es que ni siquiera para poner un triste joystick

Me ha sorprendido encontrarme algo tan versátil como esto. Lo malo es que no está al alcance de la mayoría de los bolsillos .

Es que para meter una bestia parda como el Commodore Amiga, la FPGA que se gasta este invento es el equivalente a una Spartan de 1 millón de puertas (la del Gameduino es equivalente a unas 200.000 puertas). También por eso cuesta lo que cuesta.

-- Actualizado 06 Ene 2013, 16:59 --

Don "Superfo" me ha escrito ayer por la noche, y me ha pasado estas fotos e información.

Vistas por las dos caras del Gameduino y la plaquita que ha desarrollado.

gameduino_y_placa_delantera.jpg (58.49 KiB) Visto 10068 veces

gameduino_y_placa_trasera.jpg (50.64 KiB) Visto 10068 veces

Cargando desde un iPhone...

gameduino_cargando_desde_iphone.jpg (56.78 KiB) Visto 10068 veces

Prueba con ULAplus y Timex Hicolor, en la misma imagen.

gameduino_prueba_multicolor.jpg (43.47 KiB) Visto 10068 veces

Esquemático de la plaquita que ha realizado (sólo tengo el esquemático, no tengo la placa en sí)

RGB2VIDEO_V3 SCH.zip

(13.7 KiB) Descargado 485 veces

El core que ha escrito en Verilog ya está puesto en OpenCores. Usa aproximadamente un 80% de la FPGA, aunque creo que hay cosas que se puede optimizar un poco más. Por ejemplo, para sacar las señales RGB no ha usado el pequeño DAC de resistencias que existe en el propio Gameduino, sino que ha dejado los conversores sigma-delta del proyecto original (que en mi caso tuve que poner porque mi placa entrenadora sólo me da una línea por cada color). La interfaz de teclado tampoco es la mía, sino que es otra que se ha buscado/hecho. No sé si es porque la mía ocupaba más en el core, o es simplemente porque él necesitaba una implementación con el teclado US y la original usa el teclado español.

[scooter]

¡Vaya!. Lo de "fo"no se de donde viene, pero lo de "super" ya lo voy viendo: ¡¡Este tío no duerme!!
No para quieto un segundo, menudo máquina!!!

Está chulo el spectrum Mini

[antoniovillena]

Por ejemplo, para sacar las señales RGB no ha usado el pequeño DAC de resistencias que existe en el propio Gameduino, sino que ha dejado los conversores sigma-delta del proyecto original

Sí que lo ha usado, el conector J3 de esta plaquita encaja con VGA_CON de la MOD-VGA, donde los pines 1,2 y 3 han pasado previamente por el triple DAC de 3 bits cada uno.

[mcleod_ideafix]

Por ejemplo, para sacar las señales RGB no ha usado el pequeño DAC de resistencias que existe en el propio Gameduino, sino que ha dejado los conversores sigma-delta del proyecto original

Sí que lo ha usado, el conector J3 de esta plaquita encaja con VGA_CON de la MOD-VGA, donde los pines 1,2 y 3 han pasado previamente por el triple DAC de 3 bits cada uno.

No, no ha usado el DAC del Gameduino. No te fijes sólamente en el esquemático del adaptador. En la descripción, él conecta la FPGA sólamente a tres líneas de las que van al DAC (en lugar de las 9). Si miras el fichero UCF que viene con la descripción...

Código: Seleccionar todo

# I/O
#NET "r<2>" LOC = "P19" | IOSTANDARD = LVCMOS33;
#NET "r<1>" LOC = "P16" | IOSTANDARD = LVCMOS33;
NET "r" LOC = "P15" | IOSTANDARD = LVCMOS33;
#NET "g<2>" LOC = "P10" | IOSTANDARD = LVCMOS33;
#NET "g<1>" LOC = "P12" | IOSTANDARD = LVCMOS33;
NET "g" LOC = "P13" | IOSTANDARD = LVCMOS33;
#NET "b<2>" LOC = "P5"  | IOSTANDARD = LVCMOS33;
#NET "b<1>" LOC = "P6"  | IOSTANDARD = LVCMOS33;
NET "b" LOC = "P9"  | IOSTANDARD = LVCMOS33;
#NET "i" LOC = "D7"  | IOSTANDARD = LVCMOS33;


Verás que él ha comentado dos de cada tres líneas, y sólo ha conectado una línea para rojo, otra para verde y otra para azul. Los pines son el 15,13 y 9, que se corresponden con el bit más significativo para cada color del DAC primitivo. Por esos pines lo que lleva es directamente la señal ya convertida en analógico por los conversores sigma-delta que ha dejado de la descripción original (y que como ya he contado, yo usé sencillamente porque mi placa entrenadora sólamente tiene una línea por color primario).

El resto de pines no los conecta. No he visto la descripción en detalle así que no sé si ha configurado esos pines para que estén a masa, o flotantes. Si es lo primero, la señal se verá más apagada de lo que debería estarlo puesto que esos pines harán de divisor de tensión. Si están flotantes, es como si esos pines (y sus resistencias asociadas) no existieran.

En resumen: que no, que no ha usado el DAC de resistencias del Gameduino.

[antoniovillena]

Lo siento, no había leído la descripción de la FPGA, sólo los esquemáticos. En cualquier caso la placa a nivel hardware sí lo soporta, lo que habría que hacer sería cambiar la programación de la FPGA. Supongo que lo habrá hecho con vistas a añadir futuro hardware, porque 6 pines más dan mucho juego.

[mcleod_ideafix]

Lo siento, no había leído la descripción de la FPGA, sólo los esquemáticos. En cualquier caso la placa a nivel hardware sí lo soporta, lo que habría que hacer sería cambiar la programación de la FPGA.

Sí, el cambio es trivial: quitar los tres DAC's sigma-delta que se implementaron en la FPGA y hacer que los 9 bits de color salgan por los pines correspondientes de la FPGA.

Supongo que lo habrá hecho con vistas a añadir futuro hardware, porque 6 pines más dan mucho juego.

Mmmm... en realidad la cosa es más simple Cuando Don hizo su clon de 128K basado en una CPLD tipo XC95288, ruteó las señales RGB de la misma forma que ha hecho ahora, y metió el conversor sigma-delta. Le dije que no hacía falta (de hecho, con el sigma-delta se ve un poco peor porque no le puso un filtro a la salida para acondicionar la señal), pero me da que no pilló bien el funcionamiento de esa parte del diseño, o bien no se quiso complicar la vida ni antes ni ahora (???).

En cualquier caso, sí que es verdad que generando RGB como lo ha hecho, le quedan 6 señales libres a usar en la FPGA... Lástima que dichas señales no estén disponibles en ningún pinheader y que para usarlas habría que soldar en la propia placa del Arduino cablecillos finos en los puntos de soldadura de las resistencias de la parte de DAC que no usa. La única señal que reaprovecha es la del sincronismo vertical VGA, que en su caso no es necesaria porque genera sincronismo compuesto, así que el pin que estaba destinado al sincronismo vertical se ha convertido en la nueva señal de entrada EAR.

Dado que el Spectrum es un ordenador que no ha tenido interfaz nativa de joystick hasta el +2 gris, y que por tanto practicamente todos (por no decir todos) sus juegos se manejan con el teclado, creo que en el diseño que haga sacrificaré la interface de joystick, dejando sólamente al teclado como sistema de control (quizás con emulación de joystick Sinclair para las teclas del cursor). Hay 4 señales que Don no usa en su diseño pero yo sí quiero usarlas: son precisamente las señales que el Gameduino original usa como interface SPI con Arduino. En mi caso quiero poner ahí una interface SPI pero para poder manejar tarjetas SD/MMC, y así implementar un Spectrum +3e con soporte de ZXMMC

[celestinox]

Me encanta este hilo. Enhorabuena a los participantes, tenéis un nivel acojo.... Yo en cambio ni idea de vhld ni nada por el estilo. Un pregunta, existe la posibilidad de añadir un bus zx al prototipo que ha diseñado superfo y así poder añadir un ZXbus compatible con divide; o hay limitaciones, es problema de hard físico (falta de pìnes libres en fpga) o de descripción en vhld. Un saludo.

[mcleod_ideafix]

La respuesta corta es: no, no se puede por falta de pines.
La respuesta larga es que quizás se podría intentar, pero con algo de ayuda externa: la idea sería encapsular el estado de las señales del bus en una transmision bidireccional serial de alta velocidad. Externa a la FPGA habría que poner una CPLD o algo parecido que multiplexe y demultiplexe las señales.
Sin comprimir, y asumiendo el peor caso (se envían el máximo de señales en cada flanco de reloj de CPU), estaríamos hablando de enviar 16+4+8+2=30 señales (aprox.) cada 140ns. Para ello habría que enviarlas a 210MHz, lo cual se me antoja complicado. Si en lugar de dos hilos contamos con 5, se pueden enviar 4 bits en cada ciclo, lo que rebajaría la velocidad a unos 52MHz, lo cual es más manejable