Clon Superfo 128K - Manos a la obra

[REHome]

Hola:

Mucha profesionalidad veo aquí, hasta siento complejo de inferioridad,

Usar un FPGA me parece mucho para un Spectrum, ejjejejej. Eso si, es muy curioso, sobre todo saber manejarlo bien que es otro reto.

Por lo que estuvieron hablando arriba, se los dejo más claro, no solo para ustedes sino para nuevos visitantes ahora y futuro.



Sólo da un 0 en todo el proceso, aún así con un mini PIC furula, jajajajja. Si insisten en las retro de la época, pues.........

¿Saben donde hay un buen esquema eléctrico del ZX Spectrum +2A?

Ese si que pierdo el tiempo en investigarlo a fondo. No solo hay que tener conocimiento, sino €€€€€€€€€€, tiempo y dedicación hasta para comprar un Willem para leer y grabr EEPROM de todo tipo.

Sobre los proyecto que hicieron y están haciendo, buen trabajo.

Una noticia reciente, que todavía hasta en revistas digitales, nombran algún comentario sobre estas tecnología de la época.
http://www.muycomputer.com/2013/04/20/c ... anzamiento

Saludo.

[mcleod_ideafix]

Usar un FPGA me parece mucho para un Spectrum, ejjejejej. Eso si, es muy curioso, sobre todo saber manejarlo bien que es otro reto.

No creas que no barajé otras opciones, pero para implementar la ULAplus, era (es) lo más barato. Tanto en el coste del chip en sí mismo, como en el ahorro de espacio en la plaquita (al no necesitar la RAM extra para implementar la paleta)

¿Saben donde hay un buen esquema eléctrico del ZX Spectrum +2A?

En el repositorio de archivos de WOS (World Of Spectrum). Ahí tienes todos los esquemáticos habidos y por haber.

Sólo da un 0 en todo el proceso, aún así con un mini PIC furula, jajajajja. Si insisten en las retro de la época, pues.........

Repito que usar un PIC para hacer esa decodificación es matar moscas a cañonazos, sobre todo cuando la solución con un chip 74HC ocupa lo mismo que el PIC, no necesita reloj, y... ¡es mucho más rápida! ¿Cuánto tarda tu PIC en calcular la nueva salida cuando cambie alguna de las entradas? Que yo sepa, el PIC no tiene instrucciones de carga con índice, así que no puedes usar 8 posiciones de memoria para almacenar la tabla de verdad del circuito, sino que tienes que calcularla en cada vuelta de bucle (porque tendrás que hacer polling en las entradas). Nunca he usado el ensamblador del PIC, pero así a ojo, mirando una tabla de opcodes de PIC de una página web se me ocurre el siguiente código:

Asumo que hay un puerto al que llamo PORTA al que puedo programar para que sus bits 0,1 y 2 sean de entrada, y el 3 de salida.

Código: Seleccionar todo

principio:
  BTFSC PORTA,0  ;salta una instrucción si IORQ es 0
  GOTO pon1  ;ve a poner la salida a 1
  BTFSC PORTA,1  ;salta una instrucción si A4 es 0
  GOTO pon1  ;ve a poner la salida a 1
  BTSS PORTA,2;  salta una instrucción si M1 es 1
  GOTO pon1  ;ve a poner la salida a 1
  BCF PORTA,3;  SALIDA  ;aquí llegamos sólo si IORQ es 0, A4 es 0, y M1 es 1. Ponemos SALIDA=0
  GOTO principio
pon1:
  BSF PORTA,3;  SALIDA  ;Aquí ponemos SALIDA=1
  GOTO principio


Si no me he equivocado y este código funciona, en el caso peor (cuando las tres condiciones se cumplen y hay que poner SALIDA=0), una vuelta de bucle completa necesita 4 instrucciones para ejecutarse (las tres comprobaciones, el clear del bit, y el GOTO al principio). Es decir, 4 instrucciones de salto y 1 de set bit. Las 4 de salto, como el salto se cumple, duran 8 ciclos de reloj de PIC. La de set bit dura 4. En total son 36 ciclos de reloj de PIC.

El tiempo en que IORQ está a nivel bajo indicando un ciclo de E/S en el Z80 es de 2.5 ciclos de reloj del Z80. Esto es, 714.28ns. En menos de ese tiempo, la CF tiene que haber sido seleccionada y hay que darle tiempo a que reaccione enviando el valor (si es un ciclo de lectura). Pongamos que la CF necesita 20ns para responder (una CF realmente rápida). Eso significa que la decodificación debe haberse producido antes de 690ns aproximadamente.

Para que al PIC le dé tiempo, 36 ciclos de reloj de PIC deben durar 690ns o menos. Eso significa que la frecuencia de reloj que necesita el PIC debe ser como mínimo, 52MHz.

Ahora, veamos un humilde 74HC10 (tres puertas NAND de 3 entradas), que es el circuito original. Es un chip de 14 pines. Cada puerta tiene un retraso de 11ns (según datasheet). Las puertas están conectadas en cascada en el circuito, así que la propagación de las entradas a la salida es de como máximo, 33ns.

¿Puede un PIC real mejorar estas cifras? ¿Cómo sería el programa y cuánto tardaría en propagar el nuevo valor de las entradas a la salida? ¿Cuánto costaría? ¿Cuánto ocuparía en placa? (incluyendo el cuarzo de 1GHz )

No solo hay que tener conocimiento, sino €€€€€€€€€€, tiempo y dedicación hasta para comprar un Willem para leer y grabr EEPROM de todo tipo.

Hombre... un programador Willem, creo que es de lo más barato que hay por ahí... Si ya incluso los programadores universales estos que hay por USB empiezan a estar baratitos


Y ahora, vamos de vuelta al tema de este hilo:

-----------------------------------------------------------------------------------------

Tengo ya incluido el procesador, ROM y los 128K de RAM en la simulación en Verilog. Como ROM he puesto el test de memoria 128K de Paul Farrow. Si no lo habeis probado con el clon real, os lo recomiendo, porque no sólamente testea el correcto funcionamiento de la RAM, sino también la lógica de paginación.
http://www.fruitcake.plus.com/Sinclair/ ... Tester.htm

Simular 20ms (un frame) de ejecución del clon completo le lleva a mi PC del orden de 1.5 segundos, así que para simular estos 163 frames (unos 3 segundos de animación) se ha llevado su tiempo. Después de recoger los datos RGB en cada ciclo de reloj de pixel y traducirlo a imágenes, esto es lo que sale (la animación está en bucle):



Destaco el hecho de que no he visto ningún fallo de escritura o lectura en VRAM como visteis vosotros. Eso significa que lo que es la lógica "sobre el papel" funciona, y que lo que ha pasado ha sido tema de retrasos, como de hecho ya comprobasteis. Cuando monte "de verdad" el clon, lo que haré será ver si sustituyendo el HC4040 por algo que sea equivalente a él, pero en síncrono, se resuelven los fallos.

Con todo, hay algo que creo que hay que comprobar, incluso con los cambios que habeis hecho: resulta que los mencionados glitches del 4040 afectan a otras partes del circuito, como por ejemplo, la generación del reloj de la CPU. Así, hay veces en que el periodo de ese reloj es más largo de lo que debería ser, como aquí (el periodo alargado está entre los dos cursores amarillos. No hay contención):


Además los glitches del HC4040 afectan, como ya habeis averiguado, a la generación de AL y /AL . Vosotros habeis solucionado el tema de la generación de esas dos señales, pero no habeis solucionado el problema subyacente, y es que esas dos señales se generan mal porque AL1 y AL2 tienen a su vez glitches. Esto hace que en ocasiones, alguna de ellas se activa cuando no debe durante un momentito, haciendo que AL y /AL cambien a su vez también brevemente. Brevemente, pero lo suficiente para confundir al circuito de contienda, que cree que está ante un nuevo ciclo de generación de píxeles, y frena a la CPU cuando no debe hacerlo. Es lo que pasa por ejemplo, aquí:


Lo que está enmarcado entre el cursor amarillo punteado y el cursor amarillo sólido es un ciclo de escritura (3 ciclos de reloj de la CPU). La escritura es a la dirección 4000h y el valor es 01h. El momento exacto en el que se produce la escritura es en el flanco alto de wr_n, que está marcado por un cursor blanco. Ahí se puede ver la dirección a la que se quiere escribir (4000h) y el dato (01h). Esta escritura es a una dirección de VRAM, y por tanto sujeta a contienda. De hecho, así ocurre porque el comienzo de este ciclo de bus coincide con el tramo de tiempo en que la ULA requiere a la VRAM para leerla. Hay contienda del primer ciclo (T1), que se alaaaaaaarga hasta que la señal AL deja de valer 0. El tiempo en que AL vale 1 es el tiempo en que la VRAM no está siendo usada por la ULA.

En condiciones normales, los dos restantes ciclos (T2 y T3) se suceden sin problemas, ya que el tiempo que AL está a 1 es suficientemente largo como para permitir que el ciclo de escritura termine sin más contención.

Peeeeeeeero ¡el glitch! Cuando el contador horizontal (HC, nuestro HC4040) pasa de 159 a 160, podeis ver que ese paso no es nada limpio. De hecho, en binario esto es pasar de 10011111 a 10100000, y eso implica que cambien de estado 6 bits. Siendo el HC4040 un contador ripple, el resultado es similar al que os conté hace ya unas cuantas páginas. El resultado es que uno de los valores basura de HC hace que AL2 vuelva a valer 0, así que AL vuelve a valer 0. Esto sucede durante unos cuantos nanosegndos, pero los suficientes para que la lógica de contención se crea que esto es un nuevo ciclo, y en la siguiente subida del reloj de la CPU, lo vuelva a frenar, alargando T3 mucho más de lo debido. Esta es una ampliación del glitch y el pulso erróneo de AL2:



Tengo que buscar alguna rutina o programilla que sea muy sensible a las temporizaciones (quizás la segunda parte de la Shock Megademo...) y ponerla aquí, a ver qué pasa...

[REHome]

Hola:

Es una forma de programar más. Usar un PIC solo para ese propósito no hace falta, si acaso si usa muchos 74LSxx por poner un ejemplo. En la programación dependiendo del número de entradas, obtienes una salida que desees. Y si, se puede usar puertos o PORTA como entradas y salidas que escogas, sean digitales o analógicas depende del microcontrolador.

Esos PIC que nombras son de 8 bits tipo de 16F a 18F, 20 MHz como máximo con crital de cuarzo y 8 MHz con oscilador interno. PIC32 de 32 bits hasta los 80 MHz. Z80 es un procesador, para eso uso uno superior vez de PIC como el 8085/86 casi de la misma época. Nombro PIC, no por usar simplemente un PIC y ya está, hay más microcontroladores, iba a usar Rabbit de 200 MHz, ahora le pertenece a otra empresa. Hay microcontroladores para escoger. Por lo que me cuentas, el simple PIC para estas cosas no sirve de mucho.

Los 74xxXX son rapidísimos, los hay de varias velocidades, solo son puertas y no necesitan osciladores. Doy por hecho que sabes como son por dentro una puerta NAND, llenos de transistores, etc...



Sigo viendo los experimentos que hacen ustedes del clon. Cada vez me engancho un poco más...

...por no decir, demasiado.

Saludo.

[jepalza]

Si no lo habeis probado con el clon real, os lo recomiendo, porque no sólamente testea el correcto funcionamiento de la RAM, sino también la lógica de paginación.
http://www.fruitcake.plus.com/Sinclair/ ... Tester.htm

Comprobado primero en modo normal:
(edito: acabo de ver la foto, y la pillé acabando el último, pero es "ok" tambien)

test_128_modo_normla.JPG (67.52 KiB) Visto 7513 veces

Y luego en modo amstrad:

test_128_amstrad.JPG (89.89 KiB) Visto 7513 veces

uno ok, otro desastroso (¿o debe ser así? tengo un cacao mental con tantas roms que he probado, que no sé dónde me da el aire)

-- Actualizado 21 Abr 2013, 07:17 --

Por otro lado el tema de que no funcione en un +3e y sí (medio sí) con la ROM de 16K puede ser debido a que estos interfaces son muy antiguos y las roms del +3e han sido modificadas varias veces. En una de estas modificaciones se ha podido "joder" la compatibilidad para ZXCF.

Eso es lo que estoy mirando. Pero "telejuro" que estoy superliado con tantas ROM. He probado mas de una docena, solo una (creo que era de un DivIde) hizo amagos de mostrar el CAT, pero el resto, ninguna ve la CF, no al menos, con el invento del 74HC04. En cambio esa "vieja" ROM de 16k para el 48, funciona (mal) pero funciona.

[mcleod_ideafix]

uno ok, otro desastroso (¿o debe ser así? tengo un cacao mental con tantas roms que he probado, que no sé dónde me da el aire)

No, no debería ser así. ¿Tienes bien puestos los jumpers para el modo Amstrad? Parece ser que tal y como está hecha la huella de J13, el modo Sinclair es fácil de jumpear, pero el de Amstrad no.

[antoniovillena]

No, no debería ser así. ¿Tienes bien puestos los jumpers para el modo Amstrad? Parece ser que tal y como está hecha la huella de J13, el modo Sinclair es fácil de jumpear, pero el de Amstrad no.

Hay que hacer un puente entre los pines 1 y 5 del conector para que funcione el modo Amstrad. El diseño de ese conector no era lineal, sino cuadrado de 2x2. Y no debería ser de 5 pines sino de 4, Superfo se equivocó al poner la huella, por eso el quinto pin no está conectado a nada. Pero casualidades del destino ambos errores se contrarrestan si puenteas los pines 1 y 5, y la tira de pines lineal tiene exactamente la misma funcionalidad que la cuadrada que se pretendió diseñar (eso sí, con un pin mas).

[superfo]

Here is my RAM test for Sinclair mode



And this is for Amstrad mode

[antoniovillena]

Me han gustado un montón las simulaciones. Sigo pensando que es una herramienta muy muy potente, y bien empleada en el diseño de circuitos con lógica discreta te ahorra muchos prototipos y quebraderos de cabeza. Aún así no ha podido detectar el fallo de la basura porque en teoría la lógica combinacional estaba bien, era un tema de retardos y de qué señal se genera primero, si AL o /AL.

Por otro lado, es cierto que hay glitches en algunas señales. También estarían en caso de usar 74hc161 en cascada en lugar de 74hc4040, aunque de menor duración y no en todos los casos. Todo esto lo tuvo en cuenta tanto Richard Altwasser cuando diseñó el original como Chris Smith cuando diseñó el clon. De todas formas no está mal repasarlo por si se les escapó algo que nos pueda dar problemas.

En el caso de la contención, el arreglo consiste en un biestable (U21A) que se sincroniza medio ciclo de reloj (del reloj de 7Mhz) después del incremento del contador HCX, tiempo suficiente para que las señales se hayan estabilizado.

Estas serían las reglas básicas:

• Las señales individuales HCX no tienen glitches, sólo se dan en circuitos combinacionales que se hagan a partir de estas señales porque hay un desfase entre ellas.
• No todos los giltches son malos. Hay glitches que son deseables, como los que resetean los contadores de forma asíncrona. Hacerlo de forma síncrona requeriría más puertas.
• Por lo general todos los glitches que generan video no se protegen porque son muy pequeños para ser visibles o se eliminan en el filtro de 8MHz de la TV.
• Tampoco se eliminan los glitches de AL1, AL2, AL ó /AL. En este caso creo que es porque el decodificador impide que se activen varios CX la vez, y los posibles glitches no causan errores reales. Por ejemplo cuando HC3..HC1 cambia de 011 a 100 pasa por la secuencia: 011 -> 010 -> 000 -> 100, a la salida del decodificador sería C3 -> C2 -> C0 -> C4. Esto en términos de AL1 supone 0 -> 1 -> 1 -> 1, que significa que no se produce glitch en AL1 aunque existiera en HC3..HC1.
• Sin embargo en C6->C7 sí que existen glitches, por eso se emplea el biestable U21A, para eliminarlos.

-- Actualizado 21 Abr 2013, 08:32 --

Here is my RAM test for Sinclair mode

...
And this is for Amstrad mode

...

Has you changed the J13 jumpers between the tests?

[superfo]

## Have you changed the jumpers J13 Between the tests?

Yes, I changed the jumper.
Maybe it relate to the border problem.

[antoniovillena]

@mcleod can you modify the uC firware to active P0.4 when Pause is pressed? Also is the desirable to add the P0.5 when Scroll lock or print screen to generate a NMI pulse, but this only will work on revD or later revisions.

Superfo has the PS/2 interface working on the clon, and can try these improvements.