¡Hola! Pues me temo que no. La implementación que tú tienes de la SPI flash es más compleja, porque integra en hardware los comandos de lectura. Eso se puede hacer por programa. Aparte, tú estabas interactuando con el antiguo mapeador, y ese mapeador de memoria no estaba preparado para soportar ROM en RAM (no sin un reescrito fuerte), así que corté por lo sano y he tirado a la basura el antiguo mapeador. El nuevo (módulo "memory") es el que ahora se encarga de decidir si el Z80 "ve" ROM, VRAM, SRAM, o incluso E/S (para los puertos que controlan los accesos a memoria).
Respecto al módulo SPI de la SD: si las pruebas que estoy haciendo son satisfactorias, podré compartir el módulo SPI entre la flash y la SD, ahorrándome unos cuántos slices en la FPGA. Vamos a ver si lo conseguimos
-- Actualizado 04 Mar 2014, 17:25 --
mcleod_ideafix escribió:- El prototipo tiene serios problemas de ruido. En días pasados he visto en el foro probemas al grabar la SPI Flash con diversos cables grabadores, aunque el BIT se transfiere bien. He podido ver que la SPI Flash es un poco delicada a este respecto, y parece que según sea la calidad del alimentador que uses en el ZX-Uno, se portará mejor o peor. La cosa es grave porque cuando no le da la gana de portarse bien, la lectura de la SPI Flash devuelve bytes basura entre los bytes verdaderos. Una opción que estoy barajando para paliar esto es bajar la velocidad del reloj del SPI Flash (ahora mismo a 14MHz 25MHz). Esto puede implicar algún que otro cambio en la forma de leer la SPI Flash para volcarla a SRAM.
Creo que ya he dado con la solución, y era lo que me imaginaba: con el layout de la placa actual, una señal de 25MHz no se porta nada bien
He cambiado el módulo SPI Flash y ahora la velocidad de reloj de la flash es de 3.5MHz: la misma velocidad que tiene el módulo SPI para la SD, y no es coincidencia: pretendo compartir el mismo módulo para ambos periféricos y así ahorrar slices
Esto significa algo importante, y que, Antonio, debes tener en cuenta cuando escribas el firmware. Es un cambio mínimo de todas formas: consiste en que ahora, cuando pedimos leer un dato a la flash, el dato tarda en recibirse más tiempo del que tarda el ciclo de lectura de E/S. Para solucionar esto hay dos opciones:
- Pulsar WAIT para parar al procesador hasta que el módulo SPI haya terminado la transferencia.
- Usar un pipeline de forma que un lectura lea el dato actual mientras se transfiere el siguiente.
He optado por la segunda opción, más que nada porque es la que está implementada en el ZXMMC y, me imagino, en el DIVMMC.
¿En qué se traduce esto? Muy sencillo: cuando se vayan a recibir datos desde la flash por SPI, la primera lectura debe descartarse. Es decir, la hacemos, pero no hacemos nada con el resultado.
La siguiente lectura (la segunda) nos dará el byte que se transmitió desde la flash con la primera lectura (o sea, obtendremos el primer dato), mientras que esta misma segunda lectura ya está trayendo el segundo dato.
La siguiente lectura (la tercera) nos dará este segundo dato, mientras se va trayendo el tercero. Y así sucesivamente.
Ejemplo: el programa que puse antes para mostrar los 10 primeros bytes de lo que hay en la flash a partir de la posición LBA 030000h cambia de esto:
Código: Seleccionar todo
10 OUT 64571,3:OUT 64827,0 : REM CS a nivel bajo
20 OUT 64571,2 : REM selecciono FLASHSPI
30 OUT 64827,3 : REM comando de lectura
40 OUT 64827,3:OUT 64827,0:OUT 64827,0 : REM direccion LBA
50 FOR n=1 TO 10:PRINT IN 64827;" ";:NEXT n
60 OUT 64571,3:OUT 64827,1 : REM CS de nuevo a nivel alto
A esto otro:
Código: Seleccionar todo
10 OUT 64571,3:OUT 64827,0 : REM CS a nivel bajo
20 OUT 64571,2 : REM selecciono FLASHSPI
30 OUT 64827,3 : REM comando de lectura
40 OUT 64827,3:OUT 64827,0:OUT 64827,0 : REM direccion LBA
45 RANDOMIZE IN 64827 : REM lectura que descarto
50 FOR n=1 TO 10:PRINT IN 64827;" ";:NEXT n
60 OUT 64571,3:OUT 64827,1 : REM CS de nuevo a nivel alto
He actualizado
testrom.asm para reflejar esto mismo. Ahora (cruzo los dedos) las lecturas a la flash son estables
De regalo, al no usar relojes rápidos en el diseño, el rutado se ha podido relajar un poco más y nos ha brindado el esperanzador mensaje de que el diseño puede funcionar a un máximo de 48MHz (chachi, teniendo en cuenta que la señal más rápida es de 28MHz)
¡Ah! Por lo que he podido comprobar, la rutina de inicialización de Open SE IV no borra la memoria de pantalla shadow (página 7), que usa este SO para mostrar el modo de texto de 80 columnas, con lo que en la propia rutina que carga la ROM en SRAM, antes de eso, limpio esa parte de la memoria, para no tener ruiditos ni cositas en la pantalla cuando haces MODE 1 (es una pasada.... 80 columnas en pantalla... eso sí, en video compuesto se intuyen las letras
)