ZX-Uno: Camino hacia la versión 3 (definitiva)

[Mejias3D]

Increible Felicidades Quest!

Es admirable lo que estás consiguiendo. Me declaro presidente de tu club de fans.

[neuro_999]

Increible Si ya me parecía un proyecto flipante... ya con esto.
Vamos que si se pudiera meter el core del atari 2600 ya seria mi maquina soñada.

Animo y Enhorabuena. Me parece alucinante lo que voy viendo por aquí.

[gamer80]

Si el core de la Nes fuera fino y cargara todos los juegos, seria genial, pero parece que estos cores están muy verdes, lo que no quita que sea un gran proyecto.

[mcleod_ideafix]

Vamos que si se pudiera meter el core del atari 2600 ya seria mi maquina soñada.

Si se puede meter el de una Master System o de una NES, el del Atari 2600 es pan comido. Hay, que yo sepa, varios cores de A2600 por ahí. Cuestión de ver si alguno de ellos incluso permite usar la tarjeta SD como almacén de cartuchos (esto ya no es tan común, pero igual alguno de los cores lo implementa)

"And now for something completely different" (que diría John Cleese)

Quest y Antonio Villena. ¿podeis confirmarme si éste es el mapa de memoria que tenemos actualmente en la SPI flash del ZX-Uno? Entiendo que es así.

spi_flash_memory_map.png (26.27 KiB) Visto 6890 veces

Quest: el core, digamos "de usuario", ¿dónde lo tienes puesto? ¿Es cómo en este esquema? ¿El core de ZX Spectrum sigue estando en la posición 0? ¿O lo has hecho al revés para que sea el ZX Spectrum el golden core?
Antonio: como ves, con la SPI flash W25Q80BV tenemos espacio para 20 slots de ROM de 16K cada uno. No está nada mal, pero me pregunto si no sería posible usar la W25Q16BV, que es de 2048KB, con la que podríamos llegar a los 64 slots de ROMs definidos en la estructura de directorio de ROM. ¿La BIOS soporta el listar en la pantalla de inicio más de 20 ROMs?

Ambos: sea como fuere, incluso con una SPI flash de 2 MB no podemos guardar en ella varios cores: sólo el principal y uno de usuario. El principal, ZX Spectrum, no se toca nunca, y el de usuario se toca cada vez que el usuario quiera arrancar otra cosa diferente (me he cansado del SAM Coupé, ahora voy a ponerme un Oric Atmos, por poner un ejemplo). Esto suponiendo que sea así y no al revés (el principal es el de usuario y el golden el de ZX Spectrum, que supongo que tendría más lógica)

Por otra parte, cargar un core de cassette, incluso con una ultracarga de Antonio, son un par de minutos, y además queda feo porque necesitas un elemento externo (el cassette, reproductor MP3, móvil, etc) para cambiar de core. Esto no puede ser así. Tenemos que hacerlo leyendo de la SD, en la que caben muchos más cores. Antonio: ¿cuánto espacio queda actualmente en los 16KB del firmware? Es para escribir un pequeño driver que sea capaz de leer FAT16 y fAT32 (sólo lectura, no escritura de momento)

Hay que tener en cuenta que un nuevo core a menudo no es sólamente "el core", sino que también trae ROMs, BIOS, y demás. En muchos casos esa memoria está dentro del core porque se graba en alguna block RAM dentro de la FPGA, pero en los casos en los que nos interese que el propio aparato pueda cambiar de ROM, habrá que poner ésta como bloque en la SPI, así que habría que reservar un espacio para estas ROM's "invitadas".Esto es para evitar tener que escribir un driver para leer FAT para cada máquina que se implemente.

Otra solución alternativa es reservar un espacio en la tarjeta SD (una partición) donde se podrían poner todos estos datos en un esquema lineal, como están ahora las ROMs del core del ZX Spectrum, simplificando al máximo la operación de lectura del nuevo core + sus ROMs. Claro que esto dificulta al usuario la operación de mantenimiento de los cores en su tarjeta SD, al necesitar algún tipo de herramienta específica que actúe en esa partición especial. No creo que esto sea adecuado.

Bueno, pues eso

[Quest]

Quest y Antonio Villena. ¿podeis confirmarme si éste es el mapa de memoria que tenemos actualmente en la SPI flash del ZX-Uno? Entiendo que es así.

Por lo que veo en ese gráfico, encaja con la estructura actual que estoy usando ahora mismo incluyendo el core secundario para el multiboot.

Quest: el core, digamos "de usuario", ¿dónde lo tienes puesto? ¿Es cómo en este esquema? ¿El core de ZX Spectrum sigue estando en la posición 0? ¿O lo has hecho al revés para que sea el ZX Spectrum el golden core?

Ambos: sea como fuere, incluso con una SPI flash de 2 MB no podemos guardar en ella varios cores: sólo el principal y uno de usuario. El principal, ZX Spectrum, no se toca nunca, y el de usuario se toca cada vez que el usuario quiera arrancar otra cosa diferente (me he cansado del SAM Coupé, ahora voy a ponerme un Oric Atmos, por poner un ejemplo). Esto suponiendo que sea así y no al revés (el principal es el de usuario y el golden el de ZX Spectrum, que supongo que tendría más lógica)

Pues verás, te contesto todo esto a la vez:

Hay buenas noticias. Como no me convencía el esquema de ejemplo de xilinx basado en golden/fallback (que asumiría sólo 2 cores en teoría), me basé en su código de ejemplo modificándolo a mi gusto para que fuera más flexible para nosotros. Tal como lo he hecho, no sólo se mantiene el core principal (spectrum) en su posición acutal (0x00000) sino que se pueden poner tantos cores como quepan en la flash , y se puede cambiar a cualquiera de ellos cómo y cuando se quiera, siempre que estos estén siempre en el mismo offset de la SPI cada uno de ellos.

Resumiendo:

- El core principal (spectrum) está en la posición 0.
- Se podrán poner tantos cores como queramos y/o quepan en la flash (como si queremos usar una flash de 64MB y poner muchos cores..
- Se podrá cambiar entre ellos fácilmente
- Se deberán poder actualizar fácilmente (bien por EAR desde BIOS, por SD desde BIOS en el futuro, etc, etc)

Esto nos da una flexibilidad bastante grande.

¿Que cómo se consigue? Sencillo.

La Spartan-6 dispone, entre otros, de un par de registros (GENERAL_1 y GENERAL_2) donde puedes enviarle (en el caso de lo que yo he hecho, mediante una máquina de estados) una secuencia de 16 bits que se compone de: 1) offset de la SPI donde leer el siguiente core a cargar, y 2) opcode de la SPI flash a usar (en nuestro caso 0x03, lectura)

Se usa ICAP para enviarle los comandos que escriben en los registros. Luego se usa ese mismo protocolo para enviarle a la FPGA una señal de REBOOT, que lo que hace es resetear la FPGA para que vuelva a leer un core de la SPI flash, PERO usando los valores guardados en los registros GENERAL_1 y GENERAL_2, cuyo contenido NO se pierde al hacer un REBOOT. Eso significa que cuando haces el REBOOT, carga el nuevo core. ¿Mola eh? Pues como eso podemos hacerlo a voluntad, y on-the-fly cuando queramos, podemos poner los cores que queramos, donde queramos y iniciarlos cuando queramos.

Tengo el código "plantila" listo para adecuar a cualquier dirección.

Por otra parte, cargar un core de cassette, incluso con una ultracarga de Antonio, son un par de minutos, y además queda feo porque necesitas un elemento externo (el cassette, reproductor MP3, móvil, etc) para cambiar de core. Esto no puede ser así. Tenemos que hacerlo leyendo de la SD, en la que caben muchos más cores. Antonio: ¿cuánto espacio queda actualmente en los 16KB del firmware? Es para escribir un pequeño driver que sea capaz de leer FAT16 y fAT32 (sólo lectura, no escritura de momento)

Cierto, cuando revisé todos los hilos de zx-uno antiguos, vi que eliminasteis la posibilidad de escribir en la SPI desde el modo usuario. Lo entiendo, pero podríamos volver a activarlo, y protegerlo de otro modo. Mi propuesta es:

- Reactivar la escritura en flash desde el modo usuario
- Teniendo divMMC-ESXDOS que ya manejan directamente la SD con FAT, podemos actualizar los cores muy fácilmente desde la SD (programamos un sencillo cargador en un TAP y listo)
- Para que no haya accidentes, o que puedan usarse los puertos que acceden a escritura por error, yo lo protegería con una secuencia o KEY determinada (larga, sólo conocida por los desarrolladores dificil de que se ejecute por error o casualidad) para activar la escritura. Esta key podría llevarla el propio TAP o un programa cargador previo. Podríamos usarlo para actualizar cualquiera de los multi-cores que pueda llevar el zx-uno

[yombo]

Eso de "una secuencia o KEY determinada (larga, sólo conocida por los desarrolladores)"...

[Quest]

Eso de "una secuencia o KEY determinada (larga, sólo conocida por los desarrolladores)"...

Leyendolo asi, queda feo, si
Mas bien me refería a que sea una secuencia dificil de introducir por error desde un tap o programa cualquiera. La key puede ser publica perfectamente, siempre esperando que no hubiera algun gracioso que hiciera un tap brickeador... lo cual podria dejar el zx-uno inservible para alguien sin cable jtag para reescribir la flash

No obstante, si se pudiera actualizar desde BIOS por SD mucho mejor, claro. Es lo ideal. Pero hay que programarlo. El protocolo de acceso a la SD, el driver de fat16/32, etc. Antonio podrá comentar más al respecto.

Yo solo propuse eso de antes por si lo otro era muy largo de hacer y retrasaba las cosas, ya que seria mucho más sencillo de implementar. Supongo que ya se verá

[jordi_ab]

Felicidades!, es impresionante, cada día que pasa aumentáis la versatilidad del ZX-Uno.

- Para que no haya accidentes, o que puedan usarse los puertos que acceden a escritura por error, yo lo protegería con una secuencia o KEY determinada (larga, sólo conocida por los desarrolladores) para activar la escritura. Esta key podría llevarla el propio TAP o un programa cargador previo. Podríamos usarlo para actualizar cualquiera de los multi-cores que pueda llevar el zx-uno

Me sabe mal decirlo, pero eso de "sólo conocida por los desarrolladores", por muy larga que sea, alguien la reventará y mas si se incluye de forma estática en un TAP o cargador. Creo que poner una KEY, a largo plazo será tiempo perdido.

¿No se podría hacer algo a nivel hardware? del estilo de un jumper o interruptor que con una puerta lógica o similar en el core de la FPGA le impida escribir en la flash, al estilo de una protección contra escritura, que deba habilitar el usuario bajo su responsabilidad.

Incluso se podría usar para diferenciar un modo programación de un modo ejecución.
El modo programación podría permitir el acceso a los puertos y a cierta parte de la BIOS para gestionar la flash, pero el modo ejecución seria requisito para el uso normal.

Quizá no es fácil de implementar en la FPGA, pero es una idea.

Saludos

[Quest]

Jordi_ab:

Para lo primero que comentas, lee mi respuesta a yombo justo en el post anterior. No se trata de que haya una key oculta, solo de evitar brickeos por error

Para lo segundo, lo que comentas es justo como funciona el zx-uno ahora mismo. Solo se permite la escritura estando en bios. De hecho los settings de la bios, se graban en la flash, asi como los upgrades

En cualquiera de los dos casos si alguien quiere brickearlo, lo hara de todos modos, incluso con el sistema actual. Basta con crear un upgrade corrupto.

EDITO: he modificado el post para acabar ya con la "polemica" esta. De hecho me sorprende muchísimo que de todo lo comentado sólo os hayáis fijado en eso. Es cuanto menos, curioso

[mcleod_ideafix]

Eso de "una secuencia o KEY determinada (larga, sólo conocida por los desarrolladores)"...

Leyendolo asi, queda feo, si

La decisión de no permitir el acceso a la SPI flash desde, vamos a llamarlo, el "modo usuario" fue precisamente para evitar brickeos del aparato, intencionados o no, que obligarían al usuario a disponer de un programador universal o un cable JTAG. usar una key "secreta" para evitar el brickeo es inútil, dado el carácter abierto del proyecto. Usar una "secuencia mágica" para desbloquear el acceso a la SPI flash tiene más sentido (el tipo de cosas que hizo Amstrad para desbloquear las características avanzadas del ASIC del CPCplus) pero no evitas que un usuario malintencionado te cuele un TAP con un programa que ejecute esa secuencia, borre un cacho de flash y te brickee el ZX-Uno.

Así las cosas, podemos tirar por varios caminos:

- Desbloquear el acceso a la SPI Flash con una secuencia mágica, key, o como quieras llamarlo, confiando en que no habrá usuarios perversos. De esta forma podemos usar un comando de ESXDOS para todo el proceso: leer el core desde la SD, comprpobar si no es el mismo que hay en flash, para evitar una escritura innecesaria, grabarlo si es preciso, y lanzar la secuencia de REBOOT a la FPGA.
Lo malo es que el sólo hecho de mencionar "usuario perverso que puede brickearte tu ZX-Uno con un TAP" ya puede poner en alerta a un usuario suspicaz. Cuando alguien usa un Spectrum, jamás de los jamases ha tenido que preocuparse por el software que carga en su ordenador, y no querría que esto cambiase. ¿Soy demasiado paranoico?

- Bloquear el acceso a la SPI flash para que sólo pueda tenerlo la BIOS como estamos haciendo por ahora, lo que significa que perdemos la posibilidad de lanzar cores desde un comando ESXDOS con toda la facilidad que eso implica, e implementar el código necesario para leer los cores desde la SD en la BIOS, sin soporte de ESXDOS. Tened en cuenta que el acceso de SD desde la BIOS es de todas formas muy conveniente, para poder actualizar ROMs, core principal, y el propio firmware desde la tarjeta SD en lugar/además de por EAR.

- Tercera opción: "Ni pa tí ni pa mi". Me explico: usar la SRAM del ZX-Uno como almacenamiento intermedio del core entre la SD y la flash. La idea es:
* Desde ESXDOS se lee el core y se guarda en la SRAM. Con 128K no es suficiente, así que hay que modificar el core para permitir el acceso a toda la memoria, cosa que de todas formas tengo que hacer para implementar el manejador de memoria horizontal del Timex, para la especificación Chloe 280SE. Probablemente el core no pueda caber "todo seguido" y haya que saltarse bloques para no cargarse la ROM de ESXDOS o las páginas de RAM que se usen durante la carga de la SD (probablemente los primeros 32KB de DivMMC). Una vez terminada la carga, se fuerza por software un master reset dejando en el registro SCRATCH un código que indica a la BIOS que en la SRAM hay un core que pretendemos cargar en la flash
* La BIOS lee nada más comenzar ese registro y detecta que hay que proceder a copiar el contenido de la SRAM a la parte de flash que contiene el core de usuario. Lo hace y acto seguido lanza una secuencia de REBOOT como la que ha explicado Quest, lanzando el core.
* El comando de ESXDOS que lance toda esta secuencia puede tener un argumento: el fichero del core que queremos lanzar, o no tener argumentos, para indicar que queremos lanzar el core secundario que ya existe en la flash. Así evitamos escrituras innecesarias, que ya sabemos que son limitadas en una flash.
- ¿Alguna idea más? Aunque implique picar mucho más código, me parece más "elegante" la segunda opción.

-- Actualizado 14 Sep 2015, 23:11 --

¿No se podría hacer algo a nivel hardware? del estilo de un jumper o interruptor que con una puerta lógica o similar en el core de la FPGA le impida escribir en la flash, al estilo de una protección contra escritura, que deba habilitar el usuario bajo su responsabilidad.

La cosa es que escribir en la flash no es una operación anecdótica, como podría ser hacerlo en un DivIDE o DivMMC. Operaciones tales como elegir la ROM por defecto con la que quieres arrancar, o cambiar los settings de teclado, NMI, DivMMC, timings de ULA, etc, escriben a la flash. Al final el usuario tendría todo el rato puesto el jumper que permite la escritura a flash por no tener que quitarlo y ponerlo cada vez que lo necesite.

La otra cosa es que el pin de protección de escritura, /WP, nos imposibilitaría usar el modo quad SPI, que permite cargar los cores cuatro veces más rápido que con SPI estándar. En modo quad, el pin WP es un pin de datos más, desapareciendo por tanto el soporte hardware de protección contra escritura.

-- Actualizado 14 Sep 2015, 23:22 --

Otra opción, del estilo de lo que plantea jordi_ab: tener una opción en la BIOS para permitir el uso de la flash desde el modo usuario. Esa opción tendría que activarse por el usuario, y sólo duraría hasta el siguiente reset o máster reset. La idea es que el usuario resetearía, pondría esa opción (puede ser pulsando alguna tecla concreta mientras la máquina arranca) y entonces sí puede usar ESXDOS para actualizar cores, o lo que sea, en la flash. En el siguiente reset, reboot, máster reset o lo que sea, el acceso a la flash vuelve a estar denegado. Esto bloquearía la gran mayoría de intentos de brickeo intencionados.