Sintetizando un Spectrum con el ZX-Uno

[jepalza]

Vale, yo lo del bootloader lo interpretaba como que era la xilinx la que copiaba datos de la SPI a la SRAM. No que fuera un miniprograma que se ejecuta en la CPU (Z80 en este caso), que a su vez, usando los recursos del Spectrum, carga desde la SD. Son dos forma de verlo, cualquiera válida, pero la de usar el Spectrum como "donante" de recursos, no es mala idea. La otra forma, la de usar el Xilinx de modo que cargue desde la SPI tambien sirve, pero entonces, no es flexible, por que la ROM que cargue debe ser la que dejemos en la SPI, sin poder elegir otra.
Yo voy estudiando ambos casos, alguno caerá tarde o tmeprano.

[antoniovillena]

Exacto. Sí, las dos formas son válidas. Lo del bootloader sería un pelín más lento pero infinitamente más flexible. Pero vamos que estamos hablando de tiempos de inicialización de menos de un segundo. Si lo que quieres es reducir a cero el tiempo de inicialización hay una tercera forma, mucho más complicada, que es hacer un módulo que sirva datos al Z80 como si fuera una ROM independiente. De esta forma no haría falta almacenar el firmware en RAM (tendríamos más RAM libre). Hice los cálculos y con esa SPI Flash, un modo de lectura rápido de 2 bits y precargando el comando de lectura es factible. De hecho esa es la razón por la que decidí que la SPI Flash y la SD no compartieran líneas.

[mcleod_ideafix]

Yo estoy refactorizando toda la descripción de la ULA, porque empieza a parecerse a un "big mess of wires", así que me he sentado conmigo mismo, y antes de escribir nada, he hecho un esquemático de lo que sería la ruta de datos de la ULA.
Esto de la ruta de datos es más propio del diseño de microprocesadores que de un circuito como la ULA, pero resulta que desde que escribí la descripción de la ULA, hace ya dos años, he aprendido unas cuántas cosas más sobre Verilog, y claro, te das cuenta de que lo que habías escrito hace aguas por muchos sitios, así que estoy aprovechando lo que he aprendido en el Máster que estoy haciendo, y una de esas cosas es que es muy útil dividir un diseño como éste en ruta de datos por una parte, y unidad de control por otra.

Así, después de haber escrito la ruta de datos y definir las señales que necesitaré desde la unidad de control, me he sorprendido un montón al darme cuenta de dos cosas:
- La primera, que puedo hacerlo todo con el reloj de 7MHz, suprimiendo así la necesidad de generar el de 28MHz (aunque hay un sitio en donde por velocidad igual me interesa poner un reloj de 14MHz, ya veremos). El poder bajar la velocidad hasta 7MHz tiene como ventaja el que puedo ser más relajado con las restricciones temporales, admitiendo retrasos de propagación entre flipflops de hasta 140ns (antes necesitaba asegurarme de que cualquier trayecto combinacional entre flipflops no tardaba más de 35ns). En la práctica, estos retrasos son de unos 20-30ns. Hay un trayecto, que es el más crítico de todos, que es el que pasa por la LUT de la paleta. Si estuviera trabajando a 28MHz seguro que no cumplía los tiempos ahí, pero ahora respiro tranquilo
- La segunda, y la que más me ha impactado, es que tanto para las ampliaciones que hizo Timex a la ULA, como las posteriores que han surgido por el tema de la ULAplus, las señales de la unidad de control, ¡son las mismas que las de la ULA original! No hay que añadir ninguna señal nueva.

He añadido, a modo de leyenda, qué módulos del esquema pertenecen a la ULA original, cuáles fueron añadidos por Timex en su momento, y cuáles son los que se han añadido para permitir compatibilidad con ULAplus. Como podeis ver, añadir la parte de Timex no costó mucho, en términos de puertas lógicas. La ULAplus es ya otro cantar

Este es el esquema de la ruta de datos (clic para ampliar)

[jepalza]

Veo que cada uno vamos por un frente diferente, mejor así, para no cruzarnos y repetir trabajos. Yo acabo de empezar hace un rato a meter código para leer la ROM desde la SPI Flash. No es lo mismo que leerla de la SD, mas versátil, pero por ahora, necesito "aprender" y entender como funciona esto del "bootloader".
hasta el momento, he averiguado, que los BitStreams (.BIT) no tienen por que ser necesariamente estándar en tamaño. Un fichero BIT tiene el tamaño de la capacidad que acepta cada Xilinx (por ejemplo, en el Spartan 3E XCS250 es de 166kb, en el caso de la Spartan 6 XCS6LX9 es de 333kb, el doble). Cada BIT está formado por una cabecera minúscula, que indica datos reconocible, como el nombre del XILINX, la fecha y hora y el inicio del BootStrap,que es la parte que se va a cargar en el arranque inicial (boot).

Luego viene la parte del código en sí, el que el IMPACT (en el caso del grabador de ISE) se encarga de grabar en la Xilinx o en la SPI Flash, según elijamos. Dentro de ese código esta la parte BRAM, donde llevaríamos "inscrustada" nuestra ROM de Spectrum. Como el XCS250 solo tiene 24kb, solo entra una ROM de 16kb, y sobran 8kb de RAM.

La parte de la BRAM se puede inscrutar incluso si no lo haces dentro del ISE, con código programado. Lo puedes hacer tras la generación del BIT, por que las direcciones son fijas y conocidas. Hay utilidades para ello, como el programa DATA2MEM, de ese modo, se puede distribuir un archivo BIT con toda la lógica de un Specrtum, pero SIN la ROM. Luego, con el DATA2MEM podemos (desde casa y cada uno con su conciencia) incrustar la ROM del Specrtum 16k que queramos.

Pero hay un pero, ya conocido, y por eso estamos investigando: si queremos un Spectrum mayor que un 48k, necesitamos obligatoriamente inscrustar la ROM fuera de la BRAM del BIT (madre mia, vaya baile de siglas), y eso se consigue con un código independiente (en el cual estoy ahora trabajando, adaptando de otro) que lo que hace, es coger desde el final del BIT, hasta el final de la SPI que tengamos, en nuestro caso 512-166=346kb aprox. y trasladarlos hacia la SRAM externa, y seguido, dar el control al Spectrum.

En el archivo BIT solo hay que "pegar" tras el final de este, el nuevo binario deseado, en este caso, una ROM de un Specrtum 128k, o incluso dos diferentes y elegirlas al inicio, y luego al fichero BIT cambiarle el tamaño total por el nuevo. Así de simple.

Eso es todo por ahora, a ver si acabo el código y hago unas pruebas y puedo comentar resultados.

EDICIÓN: la prueba funciona, de momento en el Papilio Pro (Spartan 6). He probado a "tragar" una ROM de 128k ficticia, dentro de los 128k de SRAM externa que le he añadido para el propósito, y seguido de leer los 128k completos en la SRAM, los he vuelto a enviar sobre el puerto serie (por USB FTDI) en un fichero en el PC, con el famoso HyperTerminal de Windows, y comparado para comprobar que todo está correcto. De este modo, me aseguro de que el código funciona. Ahora me lo llevo al ZXUNO, a ver cómo lo hago allí.

[antoniovillena]

jepalza léete este mensaje

viewtopic.php?f=58&t=4629&start=60#p38009

Aquí está toda la información necesaria. Sí, es como dices sólamente que el .bit no nos sirve para nada puesto que es ese archivo que se envía del PC a la FPGA de forma volátil, no nos interesa porque no se graba en la SPI Flash. El que nos interesa es el .mcs y la utilidad srec_cat para escribir en él. De todas formas es más sencillo partir la SPI en 2 y trabajar en los últimos 256K porque con eso hay espacio de sobra y la dirección de acceso se simplifica, pero que sí, que realmente de esos primeros 256K que no tocamos, la FPGA sólo usa 166K para cargar la configuración.

No te preocupes por el bootloader (programa Z80 que hace el trasvase entre SPI Flash y RAM externa) que de eso me puedo encargar yo. En un principio tienes que tratar de que te funcione el puerto SPI hacia la flash, aquí tienes el datasheet de la Flash:

http://zxuno.speccy.org/ficheros/spi_datasheet.pdf

Con un simple Read Data a la dirección 0 deberías poder leer los primeros bytes del .mcs, es decir la configuración de la FPGA.

[mcleod_ideafix]

La propia utilidad iMPACT de Xilinx, cuando generas el MCS, te da la opción de añadir archivos que no son de configuración propiamente dicho, al propio MCS para que se graben en la flash. Desde iMPACT tienes un mapa de memoria de la SPI y decides dónde quieres poner los archivos ROM, o lo que quieras.

Dado que en esa SPI se va a poder poner más de una ROM, creo que sería conveniente decidir sobre qué formato es el que va a usar para que el bootloader reconozca las diferentes ROMs que hay y configure el ZXUno antes de botar la ROM elegida. Cosas como:
- Tamaño de la ROM (16K, 32K o 64K)
- Modo de inicio del ZXUno (128K / 48K)
- Dirección inicial en la SPI Flash
- Algún otro flag de características que se puedan habilitar o no, a elección del usuario

La idea es que este bloque de información, a modo de "tabla de particiones de ROM" estuviera en una posición fija de la SPI, se leyera, se mostrara en pantalla las opciones que hay, y se actuara en consecuencia.

[antoniovillena]

Me parece perfecto. Viendo el datasheet la Flash es más sencilla que la de la MOD-VGA, en la que había que escribir en páginas de 264 bytes en lugar de 256 bytes. No sabía que se pudiera hacer lo mismo con iMPACT, no obstante srec_cat sigue siendo útil porque se usa la línea de comandos. Vamos que puedes tener un bat que al ejecutarlo te combine el .bit con el .rom y te genere directamente el .mcs que necesitas.

Al lío. Según los datasheets, la SPI Flash acepta $80000 bytes, es decir desde la dirección 0 hasta la dirección $7ffff. Por otra parte la FPGA necesita 1,353,728 bits de configuración, esto son 169216 bytes, en hexadecimal $29500. Digamos que nos sobran $80000-$29500= $56b00 (346.75Kb). Esto nos da para más de 21 ROMs de 16K. No obstante prefiero no apurar tanto la SPI Flash, porque al fin y al cabo en la SD todo el espacio que queramos. Así que propongo usar:

• La dirección $30000 para la configuración/tabla de particiones
• Desde $40000 hasta $7ffff para guardar 16 bancos roms de 16K cada uno.

¿Qué os parece?

-- Actualizado 16 Feb 2014, 13:40 --

Para la configuración propongo esto:

• $30000: Tabla de ROMs
• $30200: Parámetros de la BIOS

En los parámetros de la BIOS se almacenarían cosas como si debe aparecer el logo de ZX-Uno al comienzo, con qué ROM y máquina bootear, etc... Serían cosas genéricas independientemente de la máquina/ROM que elijamos.

En la tabla de ROMs el máximo es de 16 elementos (en el caso de que todas sean de 16K), aunque no es necesario usarlas todas. Cada item de la tabla ocuparía 32 bytes, así que el item 1 sería $30000, el item 2 $30020 y así hasta el item 16 que sería $301e0. De esos 32 bytes en los dos primeros podemos guardar lo esencial y dejamos los 30 bytes últimos con un identificador ASCII (rellenando con ceros) con un texto descriptivo tipo "English Amstrad +2A 4.0". En los 2 primeros se puede poner:

• Byte 0: Máquina a implementar, aquí ya va implícito el tamaño de la ROM y el modo de inicio (48K/128K).
• Byte 1: Dirección inicial (4 bits) y nos sobran 4 bits para flags que queramos implementar. Sólo necesitamos 4 bits porque limitamos las posibles ubicaciones a sólo 16.

Falta el detalle de "Máquina a implementar". De aquí también nos pueden sobrar bits para usarlos como flags.

[jepalza]

Lo cierto, es que no había leído todos los hilos que llevamos abiertos del ZXUNO. Vosotros me lleváis unos pasos por delante, por que yo estaba mientras tanto tratando de hacer funcionar el mio. Y cuando me he puesto a probar cosas, no me apetecía leerme las docenas de mensajes. Por eso voy "a mi bola", y veo que hago cosas que ya habéis probado (pero bueno, eso es lo bonito, aprender).

Sí, es como dices sólamente que el .bit no nos sirve para nada puesto que es ese archivo que se envía del PC a la FPGA de forma volátil, no nos interesa porque no se graba en la SPI Flash.

Es raro es que me dices del BIT, por que (al menos en el Papilio) sí se graba en flash. No lo había probado en el ZXUNO, he hecho una prueba para meter en la FLASH el código, y me dice que está grabado, se inicia y funciona, pero si apagas y enciendes, se ha ido al carajo. O sea, qu no graba en la flash, pero está ahí, por que la ve, la borra y la lee.

Lo de leer desde la SPI, en el papilio ya me funciona. He probado a leer un fichero de 512k dentro de la SRAM, y ha ido correcto, y no tarda apenas nada. Voy a mirar ahora de hacerlo en el ZXUNO, y si funciona, pongo el código para que lo uséis.

Por cierto, me he hecho un simple programa en basic que mete una ROM al final del BIT, para poder hacer pruebas rápidas. Si lo queréis me decís. Es muy simple, pero ayuda. Da las direcciones de la cabecera del BIT antes y despues de la mezcla.

[antoniovillena]

Sí, es así. Por eso te decía que no tiene sentido poner nada después del .bit, porque ese archivo no va a parar a la Flash sino directamente a la FPGA. Esto es así en todas las FPGAs. Las FPGAs tienen una especie de RAM interna que es como si fuera el ADN con el que sintetizan sus funciones. El archivo .bit actúa escribiéndose en esa RAM interna. La propia FPGA de hecho cuando arranca y dependiendo de los valores de ciertos pines (VS2..VS0, etc...) trata de cargar por sí misma su RAM interna leyendo desde la Flash (los primeros 166K).

Cuando cargas un .mcs sólo escribes en la SPI Flash, lo que pasa es que el propio iMPACT te marca por defecto el que se ejecute la máquina, así que en la práctica en el segundo paso es como si tras grabar la SPI Flash se pasara el hipotético .bit que contiene el .mcs directamente a la FPGA.

No te creas que estamos tan avanzados. Bueno McLeod sí, pero ten en cuenta que su código lo está adaptando desde otro que ya tenía (el de opencores). Y yo en lo que a FPGA se refiere sólo estoy aportando ideas. Lo que te quiero decir es que si tienes algo que pueda hacer avanzar el proyecto, creo que lo mejor es que te pongas en contacto con McLeod para que te dé accesso de escritura al repositorio y subas allí los fuentes (en una carpeta aparte para no machacar lo de McLeod). Si no pues lo subes por aquí y le echamos un vistazo.

-- Actualizado 16 Feb 2014, 14:27 --

La Papilio Pro (creo que es la que tienes)

http://store.gadgetfactory.net/papilio-pro/

Tiene una FPGA más tocha en la que cabe la ROM de un +2A/+3 en la BRAM, por lo que puedes probar si te funciona la implementación del ZXMMC tan sólo cargando la ROM del +3e específica de ZXMMC.

Es cierto que podría haber escogido otra FPGA que nos diera menos quebraderos de cabeza, pero como dije en el primer hilo se trata de hacer un clon barato. Ten en cuenta que las entrenadoras y otros clones FPGA no bajan de los 100 euros, en este estoy tratando que cueste (sólo la placa montada) entre 30 y 40 euros.

[jepalza]

Me sigue pareciendo raro que el BIT no se grabe en flash. (por cierto, el papilio es ese que indicas, y por cierto, ya probé a meter spectrum mas "gordos", pero no avancé lo suficiente, los tengo pendientes, para no variar) Yo genero un BIT para el Papilio, le añado una ROM tras el final, arreglo la cabecera, y el soft de grabación lo envía directo a la FLASH del papilio. Apago, enciendo, y se autoarranca. Solo se me ocurre, que el Impact NO lo haga, por que yo uso uno de "Gadget Factory", el "papilio loader", que viene a ser lo mismo que el Impact, pero mas cómodo. Solo elijo el BIT, y lo envío, y se queda grabado en la Flash. Quizás es que ese programa, primero meta un código al Xilinx para que este, según reciba datos, los desvie a la flash.

No lo sé, lo desconozco (por ahora).

He compilado ya un código para el ZXUNO que lee desde la SPI (fichero BIT con ROM mezclada), y lo único que hace, es enviar los datos leídos a la SRAM, y de ahí al diodo LED para que este parpadee según los datos enviados, simplemente, para ver que está vivo. Pero el Impact me dice que el fichero está corrupto (me imagino, que por que no cumple el tamaño que espera), y no puedo probarlo. Creo que es, por que uso un Impact version 10.1 del año 2002, que es el único que he podido ejecutar en el XP con grabador lpt1

Lo de subir el código, lo puedo dejar de momento aqui, como adjunto.
Puedes cogerlo tú y probar en un ZXUNO con el grabador USB tuyo y la versión mas moderna de tu ISE. Y modificarlo a tu gusto.
Este código es el mismo que he usado hace un rato en el Papilio, y allí ha funcionado. Para llevarlo al ZXUNO solo he cambiado los pines, los accesos a SRAM (ya que el ZXUNO siempre está activa, y en el papilio no), y poco mas. Debería funcionar, pero ya te digo, que el impact no me deja grabarlo.

Por cierto, si envio el BIT sin "engordar" con una rom, si lo graba el Impact, y el LED parpadea, por eso, imagino que funciona.