SAM Coupé bajo el analizador lógico

[mcleod_ideafix]

Resulta que al igual que hice con el Inves Spectrum, estoy pasando al SAM Coupé "por la piedra", o sea, por el analizador lógico, en un intento de hacerle la ingeniería inversa al ASIC que hace las veces de ULA en este ordenador.

Hasta ahora, esto es lo que he encontrado:
- Reloj principal de 24MHz. De aquí se deriva:
* Reloj de pixel: 24 / 2 = 12MHz. Usaré este reloj como referencia: 1T = 1 periodo de ESTE reloj, no del de la CPU
* Reloj de la CPU: 24 / 4 = 6MHz. Constante. No hay "paradas". La arbitración se hace como en el +2A/3, usando WAIT
* Reloj de SAA1099 y FDC: 24 / 3 = 8MHz

- Timings horizontales de pantalla:
* Sincronismo horizontal: 64T
* Front porch: 16T
* Back Porch: 64T
* En total, el tiempo de blanking horizontal es de 144T
* Región activa (paper): 512T
* Anchura INT: 256T. El flanco de bajada de INT ocurre al mismo tiempo que el comienzo del sincronismo vertical. Cuando ocurre en una línea diferente, ocurre 80T antes del flanco de bajada del sincronismo horizontal.
* Aparentemente, el sincronismo vertical consiste en un pulso bajo de 3072T que comienza 80T antes del sincronismo horizontal. Cuando ocurre, el nivel del sincronismo horizontal se invierte.
* Borde izquierdo: 48T aunque se muestran en realidad 56T ya que durante el primer pulso de WAIT, mientras se lee la memoria por primera vez en la línea, se sigue mostrando el borde.
* Borde derecho: 64T aunque se muestran en realidad 56T ya que al principio aún se están enviando píxeles del buffer interno del ASIC.
* Longitud de una línea completa: 768T. Siendo T el periodo de un reloj de 12MHz como hemos comentado, los 768T nos dan 64 microsegundos.

- Timings verticales de pantalla:
* Borde superior: 48 lineas
* Area activa: 192 lineas
* Borde inferior: 48 lineas
* Blanking vertical: 24 lineas, de las cuales 4 son de front porch, 4 de sincronismo vertical, durante los cuales lo que ocurre es que se invierte la polaridad de la señal de sincronismo, y 16 son de back porch
* En total: 312 lineas.

Curiosidad: algunos eventos "importantes" tales como el disparo de una interrupción, o el comienzo/fin del invervalo de blanking vertical ocurren 80T antes del flanco de bajada del sincronismo horizontal. Este momento, según mis cálculos, se corresponde con el momento en que comienza el borde derecho de la línea, ya que el front porch + el borde derecho suman 80T precisamente. Tiene sentido porque a nivel hardware corresponde a decodificar cuándo la posición X es exactamente 512.

- Duración en T desde la bajada de INT hasta el primer flanco de bajada de WAIT (en los modos 3 y 4):
* El flanco de bajada de INT coincide con el comienzo del borde derecho de la línea en curso. Desde ahí hasta el comienzo del borde derecho de la última línea del borde superior hay (4+16+48)*768 = 52224T
* La longitud de ese borde + blanking horizontal + borde izquierdo = 64+144+48 = 256T
* En total: 52480T, que son 26240 tCPU. Unos 4,3733333333 ms de tiempo.

- Ralentización de la CPU: durante el periodo activo el ASIC lanza trenes de pulsos WAIT de 8T de longitud, seguidos por 8T de inactividad. En una línea (768T) caben 96 pulsos: 48 altos (inactividad) intercalados con 48 bajos (WAIT activo). No hay pulsos WAIT siempre. En todos los modos, el primer pulso bajo de WAIT ocurre 8T antes pintarse el primer pixel de paper.
* En el modo 1, que es el que existe para tener compatibilidad con el ZX Spectrum, hay un total de 40 pulsos WAIT. Es decir, la CPU está parada 320T de los 768T que dura una línea. Eso quiere decir que está activo durante 768-320=448T. Por tanto, la velocidad de reloj media de la CPU durante una línea es de 6 * 448/768 = 3.5 MHz
* En los modos 2, 3 y 4 el comportamiento es el mismo entre ellos, y diferente del modo 1. Em estos modos hay un total de 32 pulsos de WAIT, lo que deja parada a la CPU durante 256T de los 768T de una línea. La velocidad de CPU media durante una línea es por tanto: 6 * (768-256)/768 = 4 MHz

- Disposición de la pantalla:
* Modo 1: como en el Spectrum. En el manual técnico comenta que el efecto de flash se hace cambiando la paleta por interrupciones, pero no sé si esto también se aplica al modo 1 o no
* Modo 2: 256x192, 6144 bytes de bitmap, mapeado completamente lineal. Hay 6144 bytes de atributos pero no pegados a los bitmaps, sino que entre un byte de bitmap y su correspondiente atributo hay siempre 8192 bytes. Es como el modo hicolour del Timex TC2048, pero con direccionamiento lineal
* Modo 3: 6144*4 bytes en total. 512 x 192 puntos. Cada punto ocupa 2 bits, así que puede tener 4 colores (entradas 0 a 3 de la paleta). La disposición en cada byte es AABBCCDD donde A,B,C,D son los colores de los 4 píxeles, vistos de izquierda a derecha. El mapeado es completamente lineal, sin "gaps" en medio, como ocurría en el modo 2
* Modo 4: 6144*4 bytes en total. 256x192 puntos. Cada punto ocupa 4 bits, así que puede tener 16 colores (entradas 0 a 15 de la paleta). La disposición en cada bytes es AAAABBBB con el mismo significado que en el caso anterior. Direccionamiento lineal, sin "gaps".

[radastan]

Pero, ojo, esos 4 MHz equivalentes son 100% disponibles para el programa. Y lo más importante, el Z80 va a 6 MHz, es decir, ejecuta las instrucciones a casi el doble de velocidad que en el ZX Spectrum. Tenemos WAIT, si, pero cuando está libre el micro lo hace al doble de velocidad que un ZX Spectrum.

Espero que sigan bien esas averiguaciones y todo termine en un clon...

[mcleod_ideafix]

Pero, ojo, esos 4 MHz equivalentes son 100% disponibles para el programa. Y lo más importante, el Z80 va a 6 MHz, es decir, ejecuta las instrucciones a casi el doble de velocidad que en el ZX Spectrum. Tenemos WAIT, si, pero cuando está libre el micro lo hace al doble de velocidad que un ZX Spectrum.

Según he podido comprobar, WAIT desaparece sólamente cuando se ejecuta código de ROM, o de la expansión de RAM externa. Cuando se accede a RAM interna (256K o 512K), sea cuando sea (incluso cuando el ASIC está generando el borde, o el retrazo vertical, o incluso cuando se desactiva con el bit 7 del puerto $FE) hay pulsos de WAIT que ralentizan más o menos al micro.

[Quest]

Qué bueno que estés con esto Ver avances en el análisis del ASIC del Sam me pone bastante tontorrón

Sigo atento a cualquier nuevo avance.

Millones de gracias!!

[mcleod_ideafix]

Los detalles los estoy discutiendo con Simon Owen and cía en FB, en el SAM Coupé Users Group: https://www.facebook.com/groups/20486797963/
No sé si este enlace se podrá ver desde fuera de FB por alguien que no tenga cuenta. De todas formas, cuando termine el primer análisis pondré también por aquí mis conclusiones.

[Quest]

Los detalles los estoy discutiendo con Simon Owen and cía en FB, en el SAM Coupé Users Group: https://www.facebook.com/groups/20486797963/
No sé si este enlace se podrá ver desde fuera de FB por alguien que no tenga cuenta. De todas formas, cuando termine el primer análisis pondré también por aquí mis conclusiones.

Se agradece que pongas por aquí la info. Lamentablemente para poder ver la URL que pones de FB hace falta tener cuenta, y yo no tengo cuenta en FB.

Me suscribo a este hilo

Gracias de nuevo.

[mcleod_ideafix]

Bueno, pues resulta que una de las cosas que he podido comprobar es que, como le comentaba a Radas, hay contención de memoria incluso cuando no debería haberla. Esto es: mientras el ASIC pinta el borde o está sacando los sincronismos, también hay ciclos de espera en el acceso a la RAM. Especulo con que esos estados de espera los necesita el ASIC para realizar el refresco de la DRAM. Con el mencanismo interno del Z80 no se puede hacer porque la dirección de refresco del Z80 es de 7 bits y las DRAMs del SAM necesitan 8 bits.

La contienda sigue existiendo incluso cuando se apaga la generación de pantalla. El ASIC tiene un modo de apagar la pantalla, consistente en poner a 1 el bit 7 del puerto $FE. Sólo funciona en los modos 3 y 4. Hasta ahora, lo que parece ser que se conocía es que con la pantalla en off la contienda desaparecía por completo, pero he visto que no es así. Simon Owen hizo sus medidas de temporización escribiendo rutinas que pintaban cosas en el borde en tiempos muy concretos, comparando el resultado en un SAM real respecto de lo que él había programado en el SimCoupé, pero ¡claro! : eso funciona si puedes ver la prueba. Si apagas el ASIC ya no ves nada en pantalla y no puedes saber hasta dónde se ha dibujado la rayita.

El patrón de contención (no confundir con el patrón que sigue la señal WAIT) es el siguiente (medido en ciclos de reloj de CPU):
- En la región activa (el "paper" para entendernos) es: 5 Tw + 3 Tnw
- En el resto de los sitios: 1 Tw + 3 Tnw + 1 Tw + 3 Tnw . Esto es, la secuencia de 5 Tw se sustituye por 1 Tw + 3 Tnw + 1 Tw

Tw significa: ciclo en el que podría haber espera WAIT. Tnw significa: ciclo en el que no hay espera WAIT.

En todos los modos, el primer patrón comienza 4T antes de que realmente se comience a pintarse el pixel de más a la izquierda del scan actual. Este patrón termina, en los modos 2, 3 y 4, 4T antes de que se pinte el último pixel.
En el modo 1 el primer patrón se prolonga por más tiempo. Lo comenté en el primer post de este hilo pero tengo que medir exactamente cuandos T dura.

Esto es el patrón de contención. Es una señal supuestamente interna al ASIC que indica cuándo es seguro para la CPU acceder a la RAM y cuándo no lo es. La señal WAIT se forma combinando este patrón de contención con las señales MREQ, RD y WR. También (creo) interviene IORQ pero como de momento las pruebas sólo las he hecho con instrucciones de lectura de memoria, la única ecuación que puedo inferir hasta ahora es: WAIT = Contencion OR MREQ OR RD OR WR donde Contencion es la señal del patrón anterior, en donde Tw se representa con nivel bajo y Tnw con nivel alto.

Otra cosa que he visto, a la espera de lo que me comente Simón Owen, es que él dice que la contención en el SAM hace que todas las instrucciones alarguen su duración hasta el próximo ciclo múltiplo de 4, y a veces de 8. Por ejemplo: NOP tardaría 4 ciclos. LD A,n tardaría no 7 ciclos, sino 8. En una de las pruebas he podido ver que esto no siempre es así. En concreto, la ejecución de un programa que consta de un montón de repeticiones de las instrucciones NOP seguido de un LD A,(direccionRAM) hace que, durante el intervalo de tiempo en que el ASIC está explorando la pantalla, NOP tarde 9 ciclos en lugar de 4 (u 8 ) y que LD A,(direccionRAM) tarde 31 ciclos en lugar de los 32 que se supone que tarda (y muchos más que los 13 ciclos que tardaría sin contención). Cierto es que la duración de las dos instrucciones combinadas da 40 ciclos, que sí que es múltiplo de 4 (y de 8 ).

En los modos 1 y 2, durante el tiempo en que hay contienda, se leen dos posiciones de memoria, que se corresponden a bitmap + atributo. Mientras se están pintando esos píxeles, se leen otras dos posiciones. Cada par bitmap + atributo da para pintar 8 píxeles.
En los modos 3 y 4, durante el tiempo de contienda, se leen cuatro posiciones consecutivas de memoria. En el modo 3 esas cuatro posiciones se corresponden con 16 píxeles, que tardan en pintarse lo mismo que 8 píxeles en el resto de los modos. En el modo 4, esas cuatro posiciones de memoria dan para pintar 8 píxeles a todo color. Así, el patrón de lectura/actualización siempre es el mismo. Lo que cambia en unos modos respecto de los otros es la cantidad de bytes que se leen.

Siguiendo con mi especulación, es posible que antes, o quizás después, o quizás antes y después de las lecturas de RAM, el ASIC meta los ciclos de refresco. Hasta que no pinche RAS y CAS no lo podré saber. Las pruebas las estoy haciendo con el SAM montado, y conectando las sondas del analizador lógico a una placa de prototipos a la que he soldado un conector EuroDIN (vamos, el tipo de conector trasero del SAM)

La DRAM es de 100ns, más rápida que la DRAM de pantalla del Spectrum, así que hay tiempo más que de sobra para leer esos bytes. No lo he podido verificar, pero juraría que en los modos 1 y 2 se hacen dos lecturas independientes (RAS + CAS, RAS + CAS) y en los modos 3 y 4 ser hacen dos lecturas en ráfaga consistentes cada una en dos lecturas (RAS + CAS + CAS, RAS + CAS + CAS)

[radastan]

Pero, ojo, esos 4 MHz equivalentes son 100% disponibles para el programa. Y lo más importante, el Z80 va a 6 MHz, es decir, ejecuta las instrucciones a casi el doble de velocidad que en el ZX Spectrum. Tenemos WAIT, si, pero cuando está libre el micro lo hace al doble de velocidad que un ZX Spectrum.

Según he podido comprobar, WAIT desaparece sólamente cuando se ejecuta código de ROM, o de la expansión de RAM externa. Cuando se accede a RAM interna (256K o 512K), sea cuando sea (incluso cuando el ASIC está generando el borde, o el retrazo vertical, o incluso cuando se desactiva con el bit 7 del puerto $FE) hay pulsos de WAIT que ralentizan más o menos al micro.

Eso explica, por ejemplo, porqué es tan rápido el BASIC del SAM (es que deja patidifuso con el manejo de sprites). Correr las rutinas de la ROM a 6 MHz hace que un simple programa en BASIC parezca de ensamblador.

[mcleod_ideafix]

Algunas matizaciones según las medidas que he tomado en el modo 1 (el compatible con el ZX Spectrum):
- Un scan de pantalla se compone de 48 slots de 16 T ciclos de reloj cada uno. Estos ciclos son ciclos de pixel (12MHz, el doble que la CPU). Recordemos que un scan dura 768 T
- En el modo 1, el patrón 1 de contienda ( medido en ciclos de pixel es 10 Tw + 6 Tnw ) se da en 40 de estos 48 slots. Dicho de otra forma: en cada intervalo de 16 T pixeles, la CPU está parada un máximo de 10 ciclos y libre los otros 6.
- En los modos 2, 3 y 4, el patrón 1 de contienda se da en 32 de los 48 slots.
- El patrón 2 de contienda se da en el resto de los casos, y es de 2 Tw + 6 Tnw + 2 Tw + 6 Tnw (también medido en ciclos del reloj de pixel)

Así, la velocidad media de la CPU en modo 1 durante un scan cualquiera de los 192 que contienen "borde" y "paper" es de: 6*(40*6 + 8*12)/768 = 2.625 MHz. La velocidad en cualquier otro scan que no contenga paper será de 6*48*12/768 = 4.5 MHz
De los 312 scans que hay en un cuadro de pantalla, en 192 la velocidad es de 2.625 y en 120 es de 4.5MHz. Haciendo la media ponderada, la velocidad media de la CPU usando el modo 1 es de (192*2.625+120*4.5)/312 = 3.346 MHz. Esto siempre y cuando la CPU esté ejecutando código en RAM. Si ejecuta código en ROM sólo habrá contienda cuando desde ROM se acceda a RAM (guardar una dirección de retorno en pila cuando se llama a una subrutina, pintar en pantalla, leer de un puerto de E/S del ASIC o acceder a la zona de BASIC o variables del sistema)

En los modos 2, 3 y 4, la velocidad media de la CPU durante uno de los 192 scans con borde y paper es de 6*(32*6 + 16*12)/768 = 3 MHz. Fuera de estos scans es de 4.5MHz. La velocidad media es de 3.576 MHz. Mucho más próximo a la velocidad del ZX Spectrum.

Los slots de contienda comienzan a numerarse por el slot 0, que es además el primero de los slots de contienda de tipo 1. Ahí es donde comienza el contador de píxeles a contar (desde 0 hasta 767, que es lo que dura un scan). Sin embargo, no veremos pixeles de paper en pantalla hasta que dicho contador no llegue a 10. De la misma forma, aunque el contador llegue a 512, aún seguiremos viendo píxeles por otros 10 ciclos de reloj más. Esto es en todos los modos.

[mcleod_ideafix]

Especulación:

Hay contienda siempre, incluso cuando la pantalla está apagada. De acuerdo. Esa contienda sigue el que hemos llamado "patrón 2" en el que por cada 16 ciclos de pixel hay 2 con espera, 6 sin espera, 2 con espera y 6 sin espera. ¿Por qué?

La opción más lógica es pensar que esos intervalos donde hay contienda se usan para refrescar la DRAM. Pero entonces... ¿por qué en cada slot hay dos intervalos de espera en lugar de uno? La DRAM necesita refrescarse completa en menos de 4ms. Para refrescarse hay que hacer 256 ciclos "RAS-only" en menos de ese tiempo. Un slot dura 16 ciclos de reloj de pixel, que son 1,333us. Si en cada slot se usa sólo un intervalo de espera para refrescar la DRAM, necesitaremos 256 slots para refrescarla. Esto son 341,333us. Mucho menos que los 4000us que se necesitan. ¿Entonces por qué hay dos intervalos de espera, espaciados regularmente, en cada slot?

Entonces es cuando mirando en el "World of Sam" me encuentro esta reseña sobre Bruce Gordon, uno de los fundadores de MGT (Miles-Gordon Technologies):

One of the most famous storys was that Bruce offered to design and build an upgrade to the Coupé to address its shortcomings such as lack of DMA and hardware scrolling if ‘1000 people sent him £50’ to develop a new ASIC. This was announced in the November 1992 issue of Your Sinclair. However, only 64 coupons (pledging support for the offer) were received.

En cristiano: que Gordon se ofreció a diseñar y construir un nuevo ASIC que dotaría al SAM Coupé de, entre otras cosas, capacidad DMA y scroll por hardware, pero no hubo suficiente apoyo por parte de los usuarios.

Entonces se me ocurrió pensar que quizás... en el diseño del ASIC original se tuvieron en cuenta ya estas cosas aunque no llegaran a implementarse. Es decir, que se pudo hacer la circuitería que "reservaba" un slot de tiempo para que el ASIC hiciera lo que fuera con ella, sin que la CPU la molestase, en cualquier momento, incluso cuando se está pintando el borde o la pantalla está apagada.

El comportamiento del ASIC casa sin dificultades con esta especulación: en el patrón de contención 1, el que tiene 10 estados de espera y 6 estados sin espera, en los dos primeros de los 10 con espera, no hay actividad en la DRAM. La actividad viene un poco más tarde. Es un tiempo en el que no se hace aparentemente nada. ¿Refresco de DRAM? Cuando se está en el patrón de contención 1 el refresco de la DRAM está implícito en la operación de lectura que se hace de ella (como pasa de hecho en la ULA del Spectrum)
En el patrón de contención 2, el que tiene 2 espera + 6 sin espera + 2 espera + 6 sin espera, mi conjetura es que los 2 primeros estados de espera son equivalentes a los 2 primeros estados de espera de la contención 1, en los que aparentemente no se hace nada. Los otros 2 ciclos de espera sí se usarían para el refresco de pantalla, ya que mientras el patrón de contención 2 está en uso, no hay lecturas reales de la memoria de pantalla.

Es decir, que especulo con la posibilidad de que esos 2 primeros ciclos en lo que hay contención, en cada slot de 16 ciclos, estuvieran reservados por diseño para un futuro uso como parte de un engine para hacer scroll por hardware o DMA. Que el ASIC que se usó de la empresa VLSI no tuviera suficientes recursos como para añadir esa circuitería, y que se dejara para "trabajo futuro", si había demanda para ello.

Dejando volar un poco la imaginación, un canal de DMA que usara estos dos ciclos de espera por slot, podría mover 1 byte en cada 32 ciclos de pixel (2 slots, uno para leer un byte desde el origen y otro para escribirlo en su destino). Esto da un rendimiento de unos 365,625 KB/s.

EDITO: La reseña original en el número 83 de "Your Sinclair". Como podreis leer, Bruce Gordon estaba pensando en mucho más que un simple canal de DMA :O Y se adelantó a su tiempo usando "crowfunding" a través de la revista

[radastan]

Como al final se descubra que el SAM está capado de fábrica por algo que no se llegó a implementar y que realmente es más potente de lo que está funcionando... es para matar a alguien.

[mcleod_ideafix]

Pues la cosa es bastante cachonda: acabo de poner las sondas en las señales RAS y CAS y adivina qué: cuando el ASIC no tiene por qué leer la pantalla porque está generando borde o lo que sea, no hace absolutamente nada con esas señales. Es decir, no hace siquiera ciclos de refresco.

Vamos, que o algo se me escapa, o esos ciclos de espera del patrón 2 de contención están de adorno.

Ah! La velocidad media que calculé de la CPU cuando el ASIC usa el patrón de contención 2 está mal calculada. Al haber sólo 2 ciclos de reloj de pixel de espera, que corresponden a un ciclo de reloj de CPU de espera, hay veces en los que ese ciclo de reloj cae, dentro de una instrucción, en el momento en que no se está muestreando WAIT por parte de la CPU (por ejemplo, en el ciclo T1). En esos casos, la instrucción no sufre ningún retardo. Así que el valor de 4.5 MHz que di como velocidad media, en realidad es la velocidad mínima a la que va la CPU en esos casos. Todo depende de la longitud en ciclos de las instrucciones que se ejecuten. Una ristra de NOP's, por ejemplo, caerían todos dentro del slot en momentos en los que no hay espera, así que se ejecutarían a 6MHz.

Otra cosa: refresco de memoria hay, pero el ASIC lo hace aprovechando los ciclos de lectura de memoria: justo después de terminar el acceso, deja CAS baja, y hace un pulso de RAS, para implementar un ciclo de refresco del tipo "hidden refresh cycle" en lugar de uno "RAS only" que era lo que yo suponía.

Esto significa que si la CPU no hace lecturas a memoria (por ejemplo, mientras ejecuta un PAUSE 0 en ROM), y además la pantalla se apaga con el bit 7 del puerto $FE, la DRAM no se refresca en absoluto. Nada de nada. Vamos, que un programa tal como:

Código: Seleccionar todo

10 MODE 4
20 OUT 254,128
30 PAUSE 0

Deja la RAM sin refresco ninguno, excepto en los momentos en los que el HALT que hay dentro del PAUSE 0 da paso a la rutina del gestor de interrupción. Pero entre una cosa y otra pasan 20ms.

Si en lugar de eso, hago esto otro:

Código: Seleccionar todo

10 MODE 4
20 POKE 40000,243: POKE 40001,201
30 OUT 254,128
40 RANDOMIZE USR 40000: PAUSE 0

Consigo hacer un PAUSE 0 en ROM, con las interrupciones deshabilitadas. Ahí sí que estoy viendo que no hay absolutamente ninguna actividad en RAM. Voy a dejarlo unos minutos y después pulsaré el botón NMI. En cualquier otra situación, ese botón me devuelve el control al BASIC, incluso si estoy en un DI+HALT. ¿Y en este caso? ¿Me podrá dar el control con la memoria presuntamente corrupta?

[VELESOFT]

Some infos about my planned SAM COUPE 2:
http://oldcomp.cz/viewforum.php?f=65&si ... c9fe81efbd

[mcleod_ideafix]

Casi casi.... ya se ve luz al final del tunel....

[Quest]

Madre mía, qué cerca