Avances en el desarrollo del ZX-Uno

[jepalza]

Esta tarde lo miro yo tambien. ¿al final te ha servido de algo lo que hice?
(tengo tambien para la SD ya preparado, pero si no te va a servir, espero antes de subirlo)

[mcleod_ideafix]

¡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 --

- 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 )

[Hark0]

c*ones!

Cuanto saber! Y yo por aqui... un kutter dios!

[antoniovillena]

Puedo hacer la BIOS a 80 columnas, ¿Que os parece?

[Hark0]

Puedo hacer la BIOS a 80 columnas, ¿Que os parece?

Pues que habra que estirar el logo x2 horizontal

[antoniovillena]

No, el logo déjalo igual. Intentaré hacer un cambio de modo a mitad de la pantalla, sincronizandome con el bus flotante

[jepalza]

Ya sé que lo hemos comentado, pero ¿no te vale la BIOS de ESTApágina que estuvimos comentando?

[mcleod_ideafix]

Puedo hacer la BIOS a 80 columnas, ¿Que os parece?

Que no se vería un pimiento en video compuesto

[antoniovillena]

Ya sé que lo hemos comentado, pero ¿no te vale la BIOS de ESTApágina que estuvimos comentando?

Pues posiblemente, pero prefiero hacerla desde cero para tener mayor control.

Puedo hacer la BIOS a 80 columnas, ¿Que os parece?

Que no se vería un pimiento en video compuesto

Acabo de ver que el modo de video es justo el doble de resolución horizontal (misma vertical). Supongo que las 80 columnas se consiguen con fuentes de menos de 8 pixeles de ancho, y es cierto, no se vería ni un pimiento. Así que primero intentaré a ver cómo se ve a 64 columnas con rutinas propias y luego a menos columnas con ZXFonts. A las malas nos quedamos con 32 columnas y fuente estándar.

-- Actualizado 04 Mar 2014, 23:05 --

Decidido, usaré una fuente de 12x8 en modo hi-res. Como este tamaño de fuente es muy extraña partiré de una de 6x8 u otra de 12x16 para crear la fuente, Hark0 se encargaría de pulir los pequeños detalles. Esto nos daría un modo texto de 42.66 x 24. Sería un pelín más estrecha que la ZX estándar pero más legible.

[mcleod_ideafix]

Decidido, usaré una fuente de 12x8 en modo hi-res. Como este tamaño de fuente es muy extraña partiré de una de 6x8 u otra de 12x16 para crear la fuente, Hark0 se encargaría de pulir los pequeños detalles. Esto nos daría un modo texto de 42.66 x 24. Sería un pelín más estrecha que la ZX estándar pero más legible.

Ok. Recuerda estas cosillas:
- Para entrar en el modo HiRes, OUT 255,ink*8+6 Donde "ink" es el color que quieres para tinta. No hay más que dos colores en este modo. El que tú elijas para tinta, y el complementario para paper y borde.
- Antes de salir a ejecutar el nuevo SO, haz un OUT 255,0 para volverlo a la normalidad.