Un I/O para ZX Spectrum

[Scooter]

Si el 8255 os parece demasiado sibarita se puede hacer "a cuchillo" con 74xx244 como buffers de entrada y 74xx274 o 574 como latch de salida, de este modo según pongas de uno u otro vas añadiendo de ocho en ocho. Así ya no hay registro de estado, solo hay OUTs e INs para meter y sacar datos.

Ese circuito me resulta raro, normalmente se va haciendo todo en potencias de dos; 8, 16, 32... 20 es un número extraño.

Respecto a la implementación; pues un decodificador mas o menos completo según se quiera ahorrar hard o duplicar. Si se quiere decodificación completa sería recomendable una GAL o semejante. Un buffer estaría bien si se van a poner muuuchos puertos, y luego ya o el 8255 o el "puñao" de 74xx244 + 74xx574.

A continuación lo que queráis; optoacopladores, relés, transistores, triacs.. al gusto

Con un par de 74xx138, no sería decodificación completa pero casi: 12 líneas frente a 14 que si que sería completa y el 8255, y luego unos pines para pinchar "tarjetas tipo arduino" con lo que se quiera poner. Como poder se pueden poner de forma que se puedan pinchar los shields del arduino, solo que estos pines son menos versátiles, claro.

[Zardoz]

Si el 8255 os parece demasiado sibarita se puede hacer "a cuchillo" con 74xx244 como buffers de entrada y 74xx274 o 574 como latch de salida, de este modo según pongas de uno u otro vas añadiendo de ocho en ocho. Así ya no hay registro de estado, solo hay OUTs e INs para meter y sacar datos.

Ese circuito me resulta raro, normalmente se va haciendo todo en potencias de dos; 8, 16, 32... 20 es un número extraño.

Respecto a la implementación; pues un decodificador mas o menos completo según se quiera ahorrar hard o duplicar. Si se quiere decodificación completa sería recomendable una GAL o semejante. Un buffer estaría bien si se van a poner muuuchos puertos, y luego ya o el 8255 o el "puñao" de 74xx244 + 74xx574.

A continuación lo que queráis; optoacopladores, relés, transistores, triacs.. al gusto

Con un par de 74xx138, no sería decodificación completa pero casi: 12 líneas frente a 14 que si que sería completa y el 8255, y luego unos pines para pinchar "tarjetas tipo arduino" con lo que se quiera poner. Como poder se pueden poner de forma que se puedan pinchar los shields del arduino, solo que estos pines son menos versátiles, claro.

ESO lo tenia hecho mi padre. Me pregunto donde andara dicha placa....

[Scooter]

Yo personalmente puestos a añadir, pondría una ACIA, USART, UART o como se llame que añada un puerto serie de verdad, si puede ser que lleve buffer fifo. Con eso ya se conecta un arduino por fuera o lo que sea.

Anbiao ende mi parato usando catacrak

[yombo]

Buenas,

A tono con este hilo he pensado en presentaros este interfaz que estoy haciendo:



A la izquierda hay un microcontrolador tipo Arduino (pero más tocho y con 16KB de ram) y a la derecha un CPLD XC9572, igual al que se usa en la interfaz de teclado PS/2. Hace de puente entre el bus de expansión del Spectrum y el microcontrolador.
De momento he conseguido que el microcontrolador "hable" con el CPLD. La otra parte, hacer que el CPLD "hable" con el Spectrum la haré cuando tenga el Harlequin funcionando o un Spectrum para testear.

Si queréis saber un poco más: http://yombo.org/2015/02/por-fin-un-peq ... los-cplds/

Por otra parte, se podría hacer un interfaz sólo con el CPLD que tendría 24 entradas/salidas o puede que algunas más, creo que hasta 27.

[otivax]

Aquí un ejemplo de un montaje sencillo con un 8255:
http://www.simandl.cz/stranky/elektro/ur4/ur4_a.htm
Lleva 3 puertos de 8 bits, interface Kempston y botón de reset.

[pep]

Vamos a ver señores, que os veo animadillos . Lo que a mi realmente me gustaría o me parecería curioso para trastearlo es algo similar a lo que tenemos en un Arduino, unos pines de entrada/salida donde poder conectar cosas, componentes tan sencillos como un LED o un relé que mueva por ejemplo el encendido/apagado de una bombilla. Quien dice una bombilla dice subir la persiana de la habitación o abrir y cerrar la puerta del garaje. No se si me explico.
Con un Arduino o una Raspberry se puede hacer cualquier cosa siempre que de forma externa se añada la circuitería que sea necesaria pero eso es lo típico con esos sistemas, entradas y salidas digitales. Pues la idea del Spectrum es la misma, una tarjeta que se conecte al Slot y sea fácil de gobernar por software (porque yo salvo PRINT y poco más desde BASIC na de na) y que en determinados pines podamos gobernar estados altos o bajos (1 o 0) con el fin de encender/apagar cosas, es decir, gobernarlas. Lo más básico sería un pequeño programa para experimentar, es decir, un interfaz que nos permita poner a 1 o a 0 un determinado PIN y así ver como se enciende y apaga un LED (lo más básico) al pulsar algunas teclas. Lo bueno del todo sería aprender a programar o hacer algún tipo de script (quizá desde el propio software de una forma amigable) que nos permita definir secuencias que el Spectrum pueda hacer de forma ordenada (primero enciende la luz de la habitación, después enciende la tele, emite un sonido de confirmación, después te pones en modo LOAD "" y activas el cassette para cargar el juego, ¡yo que se! mil cosas). Robotizar un Spectrum!!

Después de ese brain storming, lo primero sería ver el hardware (que no se si diferiría mucho del que comenté yo y después puso algo José Leandro de indescomp) y por último ver cómo activar/desactivar esos pines analógicos o digitales en la salida de la placa, al más puro estilo Arduino por software.

Si alguien se anima, yo estaría dispuesto desde crear la placa y hacer todas las pruebas que sean necesarias.

¿y no sería más facil (a la par que más potente) usar directamente un microcontrolador en lugar del 8255? Sería tan sencillo como usar un PIC o un atmega con un programa que emule el 8255, conectando parte del bus de expansión (bus de datos, IORQ, parte del bus de direcciones...) a entradas digitales del uC y sacando todos las demás entradas/salidas o bien emulado los puertos de salida del 8255, con la ventaje de que las salidas serían totalmente programables así como el mapeo. La placa sería tan sencilla como un uC en configuración básica un ICSP o usb y si se quiere algunos relés o MOSFET.

Se puede hacer un prototipo y prueba de concepto simplemente con un arduino nano y un conector EDGE

[dandare]

¿y no sería más facil (a la par que más potente) usar directamente un microcontrolador en lugar del 8255? Sería tan sencillo como usar un PIC o un atmega con un programa que emule el 8255, conectando parte del bus de expansión (bus de datos, IORQ, parte del bus de direcciones...) a entradas digitales del uC y sacando todos las demás entradas/salidas o bien emulado los puertos de salida del 8255, con la ventaje de que las salidas serían totalmente programables así como el mapeo. La placa sería tan sencilla como un uC en configuración básica un ICSP o usb y si se quiere algunos relés o MOSFET.

Se puede hacer un prototipo y prueba de concepto simplemente con un arduino nano y un conector EDGE

hola pep, has resucitado un hilo de hace más de dos años .


En cualquier caso, y respondiendo a tu pregunta: no, no sería más fácil .

No es evidente hacer un interfaz de un microcontrolador con el spectrum, simplemente porque el uC no es lo suficientemente rápido como para responder a las señales del bus del spectrum (señales del rango de 200-300ns). Un PIC18 rápido (a 64Mhz, que son los más rápidos), tarda 62,5ns en leer un pin, y otros 62,5ns en escribirlo. Entre medias sólo te quedarían 2 instrucciones ASM de PIC para saber qué hacer. Imposible.
Utilizando un PIC con CLC, un uC muchísimo más rápido con código simple y optimizado, o lógica externa se puede hacer algún apaño, pero nada ni remotamente parecido a emular un 8255.

[pep]

hola pep, has resucitado un hilo de hace más de dos años .

sí, me parecía interesante el tema... ¿no está permitido hacerlo o se considera inapropiado?

En cualquier caso, y respondiendo a tu pregunta: no, no sería más fácil .

No es evidente hacer un interfaz de un microcontrolador con el spectrum, simplemente porque el uC no es lo suficientemente rápido como para responder a las señales del bus del spectrum (señales del rango de 200-300ns). Un PIC18 rápido (a 64Mhz, que son los más rápidos), tarda 62,5ns en leer un pin, y otros 62,5ns en escribirlo. Entre medias sólo te quedarían 2 instrucciones ASM de PIC para saber qué hacer. Imposible.
Utilizando un PIC con CLC, un uC muchísimo más rápido con código simple y optimizado, o lógica externa se puede hacer algún apaño, pero nada ni remotamente parecido a emular un 8255.

Ok, gracias por tu respuesta y aclaración, abusando un poco... ¿podrías ampliarla?. No sé si te he entendido bien pero la idea no es emular un 8255 en velocidad sino en funcionalidad, y que un uC sea lento para el spectrum no debería ser un problema, muchos periféricos son más lentros que el spectrum!

Si te he entendido bien, el problema es que las señales en el bus cambian a mayor velocidad de la que las puede leer un uC, con lo cual no le da tiempo a activar WAIT para avisar al z80, pero si este es el problema ¿no se podría solucionar con buffers?

[dandare]

Hola pep,
No suele ser normal resucitar hilos, sobre todo porque el OP ya no se acordará de qué iba eso . Si acaso que se pronuncie un moderador a ver cual es la postura "oficial" .

Amplío un poco con ejemplos concretos para el caso del spectrum:

A un periférico de spectrum, normalmente, querrás escribir a un puerto determinado, eso lo harás con una instrucción OUT. Para leer, lo harás con una instrucción IN.
Éste es el diagrama de tiempos de una instrucción OUT y de una IN (están los dos juntos).
Sin contar con los trucos de la ULA de parar el reloj (contención), en un Spectrum 48k cada ciclo (T1,T2...) es de unos 286ns.

IO Z80.png

Veamos el caso de envío de datos Spectrum -> Microcontrolador (OUT)
El microcontrolador debe monitorizar el bus de control buscando la combinación del puerto seleccionado en el bus de direcciones, un IOREQ y un WR. Eso son bastantes instrucciones de uC que, bien deben estar en un bucle, bien disparadas por una interrupción en el flanco de bajada de IOREQ, pero esas interrupciones se dispararán "en falso" muchas veces...
Una vez detectada la petición de escritura, el uC tiene que leer el bus de datos y obtener el byte enviado.
Incluso aunque insertes señales de wait adicionales a la que se inserta automáticamente, necesitarías detectar el puerto IO, IOREQ, WR y activar esa señal o leer el valor en menos de 600ns.

El caso de lectura de datos Spectrum <- Microcontrolador (IN) es aún más complejo porque tendremos que escribir en el bus de datos en el momento adecuado y luego liberarlo, poniendo los pines del microcontrolador en modo in justo a tiempo. Ni muy pronto, porque el spectrum no leerá lo que le mandemos, ni muy tarde o habrá colisión con el ciclo M1 de la siguiente instrucción.


En resumen, toda la gestión de lectura y escritura, si se usa el método normal IN/OUT del Z80, hay que hacerla con una capa exterior de lógica discreta, gal o cpld, que es lo que se usa normalmente, complicando bastante el hw. Por tanto, hacerlo con un simple microcontrolador es prácticamente imposible, salvo uno muy muy rápido y que haga cosas muy simples. Tampoco podemos pasarnos con el WAIT, porque en equipos de 48k, paralizamos el refresco de la DRAM alta y se puede corromper.

Una opción es usar un método alternativo de comunicación y descargar esta función en código sw más complejo, tanto en el spectrum como en el microcontrolador. No elimina la necesidad de una pequeña lógica discreta (aunque se podría hacer con un microcontrolador con puertas incluidas).Eso es lo que he hecho en el Dandanator Mini, que tiene un hardware muy simple y, en contrapartida, un sw bastante complejo para hacer la comunicación.

[pep]

No suele ser normal resucitar hilos, sobre todo porque el OP ya no se acordará de qué iba eso . Si acaso que se pronuncie un moderador a ver cual es la postura "oficial" .

ok, pues lo tendré en cuenta la próxima vez

Sin contar con los trucos de la ULA de parar el reloj (contención), en un Spectrum 48k cada ciclo (T1,T2...) es de unos 286ns.


Veamos el caso de envío de datos Spectrum -> Microcontrolador (OUT)
El microcontrolador debe monitorizar el bus de control buscando la combinación del puerto seleccionado en el bus de direcciones, un IOREQ y un WR. Eso son bastantes instrucciones de uC que, bien deben estar en un bucle, bien disparadas por una interrupción en el flanco de bajada de IOREQ, pero esas interrupciones se dispararán "en falso" muchas veces...
Una vez detectada la petición de escritura, el uC tiene que leer el bus de datos y obtener el byte enviado.
Incluso aunque insertes señales de wait adicionales a la que se inserta automáticamente, necesitarías detectar el puerto IO, IOREQ, WR y activar esa señal o leer el valor en menos de 600ns.

El caso de lectura de datos Spectrum <- Microcontrolador (IN) es aún más complejo porque tendremos que escribir en el bus de datos en el momento adecuado y luego liberarlo, poniendo los pines del microcontrolador en modo in justo a tiempo. Ni muy pronto, porque el spectrum no leerá lo que le mandemos, ni muy tarde o habrá colisión con el ciclo M1 de la siguiente instrucción.


En resumen, toda la gestión de lectura y escritura, si se usa el método normal IN/OUT del Z80, hay que hacerla con una capa exterior de lógica discreta, gal o cpld, que es lo que se usa normalmente, complicando bastante el hw. Por tanto, hacerlo con un simple microcontrolador es prácticamente imposible, salvo uno muy muy rápido y que haga cosas muy simples. Tampoco podemos pasarnos con el WAIT, porque en equipos de 48k, paralizamos el refresco de la DRAM alta y se puede corromper.

Bueno, yo no me refería a usar únicamente un uC sino que este fuese el elemento principal con la lógica necesaria para que funcione, lo que pensaba era algo así (para un OUT)



que se podría externder para las lecturas duplicando los latch y multiplexando en función de RD o WR.

En cualquier caso, la idea es en cuanto se produzca la petición de IO guardar el bus de datos y (la parte interesante del) bus de direcciones y activar WAIT, la única escritura en pin que tendría que hacer el uC es activar WAIT, luego podría tomarse todo el tiempo del mundo en hacer lo que necesite porque entiendo que mientras WAIT esté activo el z80 no finaliza la petición de IO, una vez el uC acabe escribe los datos en el bus de datos y en el de direcciones si es necesario y desactiva WAIT y IORQ, eso son dos escrituras de pin, que entiendo que entrarian en los tiempos del diagrama

Una opción es usar un método alternativo de comunicación y descargar esta función en código sw más complejo, tanto en el spectrum como en el microcontrolador. No elimina la necesidad de una pequeña lógica discreta (aunque se podría hacer con un microcontrolador con puertas incluidas).Eso es lo que he hecho en el Dandanator Mini, que tiene un hardware muy simple y, en contrapartida, un sw bastante complejo para hacer la comunicación.

sí, esa sería básicamente la idea, pero ¿por qué necesitas una GAL? ¿tan compleja es la lógica discreta? uno supondria que con pocos componentes se puede realizar un interfaz que funcione