QLSD

Subforo oficial del Sinclair QL: realiza aquí las consultas relativas a tu QL.

Moderador: Sir Cilve Sinclair

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Lun Abr 25, 2011 2:32 pm

radastan escribió:Vale, hay algo que no me cuadra entre tus señales y las que en teoría debería haber con la SD. En concreto estoy mirando las señales MOSI y MISO


Tú estás viendo un cronograma con un zoom muy alejado. Mira el cachito que hay desde -200us hasta -150us, por ejemplo, y verás algo parecido a tu diagrama (para el caso CPOL=1 que es el que uso). Si se pudiera agrandar esa parte del cronograma lo verías mejor.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: QLSD

Mensaje por radastan » Lun Abr 25, 2011 2:44 pm

Vale, vale... pues entonces estoy tan perdido como tu respecto a los tiempos, ¿puedes poner una captura ampliada de las señales? es que así no hay forma de verlo bien.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Lun Abr 25, 2011 2:51 pm

radastan escribió:Vale, vale... pues entonces estoy tan perdido como tu respecto a los tiempos, ¿puedes poner una captura ampliada de las señales? es que así no hay forma de verlo bien.


Ahí va. La otra captura que puse es para que se vieran las ráfagas de la SPI, y así poder apreciar lo que se tarda en leer un dato, el siguiente, el siguiente, etc.

Haciendo zoom a una de esas ráfagas, se ve esto:
Imagen

En ROMOEH se ve un pulsito que es la orden de que comience a recibirse un nuevo valor por SPI. A partir de ahí, cada pulsito que se ve es interrogando a ver si el bit de "ocupado" está a 1 o a 0. Mientras esté a 1, seguimos esperando. Ya una vez terminada la ráfaga del reloj hay otro pulsito de ROMOEH preguntando, y ahí ya respondería que no está ocupado.

Lo que la tarjeta SD entrega al QL está en MISO, y como se puede ver debajo (las dos últimas líneas son unos "intérpretes" que ofrece el software del analizador lógico para los protocolos más comunes) es EEh. El dato aparece en MISO en el flanco negativo de SCLK y es capturado por la CPLD en el flanco positivo.

Durante todo este tiempo, SS permanece a nivel bajo. MOSI está todo el tiempo a 1 (en SPI, para recibir algo hay que enviar algo a la vez, así que cuando realmente no queremos enviar nada, enviamos FFh).

En este otro zoom (menos que el anterior) se puede ver un ciclo completo de lectura. Esta vez se lee un 00h.
Imagen
Se siguen apreciando los pulsitos en ROMOEH. El primero, como decía, pide al SPI que comience un ciclo transmisión-recepción. En MOSI se transmite un FFh (es decir, "nada") mientras que en MISO se recibe un valor 00h. Durante la recepción hay tiempo para que el bucle que se encarga de ir preguntando si el dispositivo está ocupado dé dos vueltas (dos pulsitos ROMOEH). A la tercera vuelta, ya fuera de la transmisión, el bit de ocupado está a 0, por lo que el siguiente pulsito lo que hace es leer el registro de 8 bits donde está el dato guardado (00h). Se escribe en pantalla (eso no se ve en el cronograma) y a continuación, se vuelve a pedir otro dato (el pulsito ROMOEH de más a la derecha de la imagen).

Pero como te digo, el error no está en dónde se capturan las cosas o cómo lo hace. El error está, seguro, en cómo se mete el reloj maestro a la CPLD, que tiene una componente de contínua demasiado alta y no lo coge bien. Vamos, que es más un problema "analógico" que "digital".

Hazte a la idea que toda la ráfaga de 8 ciclos de reloj que se ve muuuy grande al lado del pulsito ROMOEH aquí, en el caso ideal ocuparía poco menos que lo mismo que el propio pulsito ROMOEH, con lo que ni haría falta el bucle para ver si está ocupado. Con el propio retraso de las instrucciones, bastaría con enviar el pulso ROMOEH para iniciar un ciclo transmisión-recepción para acto seguido, leer el registro de entrada y recoger el dato recién depositado por el SPI.

Es más: cuando todo esto del reloj se solucione, querría probar a implementar una versión del controlador SPI que empleó Alessandro Poppi en el ZXMMC y que consiste en que en la misma instrucción donde envío un dato, leo el que se acaba de leer en la ráfaga anterior. De esa forma puedo encadenar instrucciones y el rendimiento del protocolo sería el máximo posible. Esto es, no me haría falta un pulso ROMOEH para iniciar la lectura y otro para leer lo recibido, sino que con una sola operación leo un dato y pido el siguiente. Eso sí: esto funciona siempre que se asegure uno de que la ráfaga siempre termina antes de que venga la siguiente instrucción de máquina. En el ZXMMC esto se aseguraba usando como único reloj SPI el propio reloj del procesador, pero eso tiene un inconveniente, y es que la especificación SD/MMC dice que las inicializaciones y demás han de hacerse con un reloj más lento. Con un reloj de 25MHz daría más que de sobra en el QL (en donde cada operación con el socket de la ROM tarda "por huevos" 300ns)
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Lun Abr 25, 2011 3:22 pm

Y he aquí al culpable: al pedir un análisis de temporización del diseño en la CPLD, obtengo esto:

Performance Summary
Min. Clock Period 40.800 ns.
Max. Clock Frequency (fSYSTEM) 24.510 MHz.

En resumen: el cuarzo de 40MHz que estoy usando es demasiada tela marinera para el diseño. Tengo que, o o bien buscarme un cuarzo más pequeño, o rehacer el diseño de forma que me permita relojes más altos.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Mar Abr 26, 2011 6:04 am

Ha sido cambiar el diseño para que pueda funcionar a frecuencias superiores a 40MHz y mano de santo. También vale poner un cristal más pequeño, pero de momento he conseguido no tener que prescindir del reloj de 40MHz (lo que me da una frecuencia máxima de SPI de 20MHz, que no está mal).

Y tanto que no está mal. Ahora sí que he podido pisar el acelerador y poner la tarjeta SD a 20MHz.
Imagen

Cada "borrón" amarillo en SCLK se corresponde a 8 períodos de reloj. Le he hecho zoom "alejado" para que se puedan ver tres transferencias completas. Se puede observar cómo ahora el pulsito de ROMOEH tiene una anchura del mismo orden que la ráfaga de SCLK.

Esta secuencia se corresponde con un bucle de lectura de datos tal que éste:

Código: Seleccionar todo

move.b (a2),d7   ; pido una nueva transmisión de dato en SPI. Lo que haya en D7 lo descarto.
move.b (a1),(a0)+  ; leo el dato recién tráido de la SD y lo guardo en memoria.

Con A1 = $FFFC, que es el registro que guarda el último dato leído del SPI, y A2 = $FEFF, que al leerse realiza un envío "vacío" al bus SPI (ya vimos que para poder recibir hay que enviar algo). A0 apunta al buffer de memoria que guardará el sector leído de la SD. En las pruebas, A0 apunta a algún lugar de la pantalla del QL.

Estas dos instrucciones se repiten 512 veces, para leer un sector completo. En la línea de -20us de la imagen, el pulsito de ROMOEH que cae justo en esa línea se corresponde con el primer move.b, que lee de un registro en la interfaz que provoca que se generen los 8 pulsos de reloj. La transferencia dura mucho menos de lo que el procesador tarda en leer y ejecutar la siguiente instrucción, así que ni me molesto en ver si el bit de "ocupado" está activo, porque sé que no lo estará. Unos dos microsegundos más tarde comienza el segundo move.b que lee del registro de salida SPI el dato recién recibido y lo guarda en memoria con autoincremento. El autoincremento "cuesta" y por eso este segundo move dura más que el primero, como puede observarse.

Esto se puede mejorar. Uso dos instrucciones: una que hace de "pistoletazo de salida" para que un nuevo dato llegue corriendo desde la SD hasta la interfaz, y otra instrucción que recoge ese dato y lo guarda en memoria RAM. ¿Y si aprovechamos la instrucción que recoge el dato para que a la vez que lo recoge, pida uno nuevo? Es decir, una especie de "pipeline".

El resultado es éste:
Imagen

Que se corresponde con esta instrucción:

Código: Seleccionar todo

move.b (a1),(a0)+

En este caso, A1 = $FFFC
Esta instrucción lee del registro de salida de SPI, guarda lo leído en memoria con autoincremento, y señaliza una nueva transmisión de datos. De un move al siguiente, como se ve, hay tiempo de sobra para que la transmisión SPI termine (yendo a 20MHz, claro). Creo que la ULA del QL mete un retraso cuando se intenta leer de las posiciones reservadas a la ROM del sistema y de ampliación, que es donde estamos nosotros. Este va a ser seguramente el mayor cuello de botella que nos encontremos. No es posible ir más rápido.

¿O sí...? Hay una cosa que no hemos probado: el 68008 tiene un bus de datos de 8 bits y todas las transferencias externas son de 8 bits, pero... hay instrucciones como move.l que mueven 32 bits de un sitio a otro, a base de hacer 4 transferencias seguidas. Esto debe ser más rápido por fuerza que 4 instrucciones move.b

Así que he cambiado el diseño de la CPLD para que en lugar de haber un registro de 8 bits, haya 4 registros de 8 bits cada uno. En realidad son todos el mismo, pero como cada vez que se lee uno, se pide un nuevo dato, al leer el siguiente registro (o el mismo), obtenemos siempre un nuevo dato.

Es decir: si para leer un nuevo dato y pedir el siguiente lo que se hace es leer de la posición $FFFC, ahora podemos hacer esta msma operación también en las direcciones $FFFD, $FFFE y $FFFF.

Así que si hago un:

Código: Seleccionar todo

move.l (a1),(a0)+

Con A1 = $FFFC, lo que el procesador hace son 4 lecturas seguidas de las posiciones FFFC,D,E y F. En efecto:
Imagen

Al contrario que en los gráficos anteriores, aquí muestro un zoom más detallado, donde se ven las 4 transferencias del move.l . No se me ocurre una forma de ir más rápido, por lo que pondré el techo de tasa de trasnferencia aquí. OJO porque la instrucción anterior tiene postincremento, y éste tarda unos cuántos microsegundos, así que cuando se concatenan varias instrucciones move.l seguidas lo que se obtiene son una serie de ráfagas cortas como la anterior, seguidas de alrededor de 4 microsegundos de silencio por el postincremento.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: QLSD

Mensaje por radastan » Mar Abr 26, 2011 7:04 am

Madre mía McLeod, eso si que es velocidad. ¿Puedes hacer un ejemplo de carga como antes para ver la diferencia? creo que sería posible incluso vídeo en streaming, que no es moco de pavo. Por lo que me puedo imaginar la escritura se va a asemejar a un disco de 3 1/2" pero la lectura va a parecer casi instantánea.

Creo que es hora de decir que la primera prueba ha sido superada, eres un genio, y ahora viene lo complicado.

¿Vas a hacer el driver en ensamblador o en C?
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
Scooter
Freddy Hardest
Mensajes: 711
Registrado: Jue Nov 11, 2010 10:17 pm

Re: QLSD

Mensaje por Scooter » Mar Abr 26, 2011 10:23 am

Esto se puede mejorar. Uso dos instrucciones: una que hace de "pistoletazo de salida" para que un nuevo dato llegue corriendo desde la SD hasta la interfaz, y otra instrucción que recoge ese dato y lo guarda en memoria RAM. ¿Y si aprovechamos la instrucción que recoge el dato para que a la vez que lo recoge, pida uno nuevo? Es decir, una especie de "pipeline".

No he usado ninguna SD porque no he encontrado una documentación decente, pero muchos periféricos SPI permiten un modo burst en el que simplemente cada byte que se lee es el siguiente con lo que una vez empezado, se leen secuencialmente todos los datos (en este caso todo el sector) simplemente siguiendo los pulsos de reloj, sin tocar SS ni nada. ¿Existe ese modo para las SD?, en ese caso bastaría con "apuntar al sector" y después "leer, leer, leer, leer..."
Aquellos chalados en sus viejos cacharros...

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: QLSD

Mensaje por radastan » Mar Abr 26, 2011 11:45 am

Yo comprendo que se quiera una interfaz lo más rápida posible... pero es que con el estado actual ya es suficientemente rápida como para decir que la carga es casi instantánea. El cuello de botella lo tenemos ahora en el mismo puerto de la ROM, y contra eso poco podemos hacer.

No se, creo que mejor tocar el tema del driver y ya habrá tiempo para optimizar después el diseño.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
Scooter
Freddy Hardest
Mensajes: 711
Registrado: Jue Nov 11, 2010 10:17 pm

Re: QLSD

Mensaje por Scooter » Mar Abr 26, 2011 12:54 pm

Si, pero si en el puerto de la rom se emplea una instrucción por byte en lugar de dos irá mas o menos el doble de rápido que no es poco así que si que es interesante.

Edito: no había leído en detalle todo el post de mcleold, es verdad que ya está en el tope. Ademas me parece que ya está en el burst o como se llame en una SD.
Aquellos chalados en sus viejos cacharros...

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Mar Abr 26, 2011 1:01 pm

Scooter escribió:No he usado ninguna SD porque no he encontrado una documentación decente, pero muchos periféricos SPI permiten un modo burst en el que simplemente cada byte que se lee es el siguiente con lo que una vez empezado, se leen secuencialmente todos los datos (en este caso todo el sector) simplemente siguiendo los pulsos de reloj


Eso es ni más ni menos lo que he hecho. Los 512 bytes del sector se leen uno detrás del otro. En SPI es el máster quien pone el reloj, por lo que tengo que señalizar que quiero un nuevo dato, y eso lo hago cuando leo "el anterior". Los dos últimos cronogramas lo que muestran es ni más ni menos que un modo burst.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Mar Abr 26, 2011 1:06 pm

radastan escribió:Madre mía McLeod, eso si que es velocidad. ¿Puedes hacer un ejemplo de carga como antes para ver la diferencia? creo que sería posible incluso vídeo en streaming, que no es moco de pavo.

No sé si a pantalla completa será posible. Todo depende de que consiga hacer funcionar el comando CMD18, que es la lectura multisector. Si lo consigo... ya lo vereis ;)

radastan escribió:Por lo que me puedo imaginar la escritura se va a asemejar a un disco de 3 1/2" pero la lectura va a parecer casi instantánea.

Hombre... la escrituras en soporte flash es lenta, pero vamos, no tanto como la escritura en floppy...

radastan escribió:¿Vas a hacer el driver en ensamblador o en C?

Buena pregunta! Te contestaría que en C sin dudarlo si no fuera porque el compilador que encontré... digamos que no me fío mucho mucho de él. Tengo que hacer más pruebas con ese compilador. El ensamblador no me ha dado sorpresas desagradables, pero... me da una pereza escribir toooda la parte de FAT en ensamblador, cuando en C ya la tengo hecha...
Web: ZX Projects | Twitter: @zxprojects

afx
Sabreman
Mensajes: 396
Registrado: Dom Feb 24, 2008 10:56 pm

Re: QLSD

Mensaje por afx » Mar Abr 26, 2011 8:01 pm

Los detalles técnicos me suenan a "chino" :D ... pero todo esto es ¡fantástico!

Mcleod, felicidades por tus progresos. A este paso tendremos SD a velocidad de "disco-duro de QL" con drivers nativos QDOS antes de las navidades (en ti hemos depositado nuestra confinaza ... :D :D )

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Mié Abr 27, 2011 11:44 pm

radastan escribió:Madre mía McLeod, eso si que es velocidad. ¿Puedes hacer un ejemplo de carga como antes para ver la diferencia?


Ahí va! Esto es lo más rápido que he conseguido. He podido optimizar el diseño de la CPLD y ahora puede funcionar a frecuencias superiores a los 50MHz. Tengo precisamente un cristal de 50MHz y con él lo estoy probando. Con este cristal, la velocidad SPI es 25MHz (siempre la mitad que la del reloj "maestro") y esta velocidad es la máxima para una tarjeta de clase 0 (lo mínimo que se despacha en SD). A eso súmale el tema de las transferencias de 32 bits en ráfaga, y una cosa nueva: la lectura multisector: en lugar de pedir 64 sectores uno detrás de otro, le digo a la tarjeta que se ponga a escupir datos hasta que me aburra.

Este es el resultado:
http://www.youtube.com/watch?v=t0XvKy8wb-g

PD: Radastan... como te podrás imaginar... después de tanta prueba... estoy hasta LOS MISMISIMOS de ver el careto del Sr. Sinclair :D ¿La pantalla esta que me pasate en BMP, modo 4... ¿no existe en formato QL? ;)

EDITO: oye, que ya no me hace falta. He re-descubierto "Retro-X" y su infame y poco intuitivo panel de control :P (pero me vale) ;)
Imagen

Por otra parte... el QL tiene doble framebuffer... ¿será esto lo suficientemente rápido como para.... video a pantalla completa? A ver si me sale :P

EDITO2: estoy en ello. Pantalla completa sí, pero full frame rate, va a ser que no. Sólo necesito comprender cómo funciona el formato RXA del Retro-X ...
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: QLSD

Mensaje por radastan » Jue Abr 28, 2011 6:53 am

Oleeeeee... se ve que vas a tomarte un respiro probando vilguerías antes de hacer el driver, pero ver vídeo en QL es algo que merece la pena probar. Y la velocidad tremenda, prácticamente instantánea la carga.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: QLSD

Mensaje por mcleod_ideafix » Jue Abr 28, 2011 1:13 pm

radastan escribió:Oleeeeee... se ve que vas a tomarte un respiro probando vilguerías antes de hacer el driver, pero ver vídeo en QL es algo que merece la pena probar. Y la velocidad tremenda, prácticamente instantánea la carga.


Bueno, no es exactamente un respiro. Antes de pasar al siguiente "nivel" tengo que dejar atado el anterior. Es decir, tengo que estar muy seguro de que las capas más bajas de manejo de la SD/MMC funcionan antes de poner más código (el filesystem) encima. Es por eso que sigo haciendo pruebas de rendimiento con varias velocidades, etc.

De hecho, el sistema está aún lejos de tener el visto bueno para la siguiente fase ya que:
- Aún no he probado las escrituras
- Aún no he probado satisfactoriamente con más modelos de tarjeta SD salvo la que tengo (que estoy viendo que es muy permisiva)

El punto 2 es realmente fastidioso ya que si me atengo al estándar, necesito dos frecuencias de reloj diferentes: una para inicializar la SD, a unos 400kHz, y otra ya a 20-25MHz, peeeeeeeero hay tarjetas "antiguas" que igual no soportan más allá de unos 5-6MHz para su modo de operación. Tengo que tener en cuenta todo esto y llegar a un compromiso: soportar más tarjetas, pero hacer más complejo el hardware (CPLD más grande, y por tanto más cara), o bien soportar un determinado tipo de tarjeta (tal fabricante, o tales características) a cambio de dejar el hardware como está ahora, que es bastante baratito.

Me he llevado del laboratorio una tarjeta SD Kingston de 1GB, ya que dicen en los foros que Kingston cumple mejor con los estándares de SD que la propia SanDisk (que fue quien escribió el estándar)

Y lo del video, en cuanto sepa cómo funciona el formato RXA, es cosa hecha ;)
Web: ZX Projects | Twitter: @zxprojects

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 6 invitados