Dispositivo E/S para Amstrad CPC

[Fran123]

Hola

Una pregunta para ir sentando bases para otras ideas:

¿Cuántas líneas del puerto de expansión del Amstrad CPC son necesarias para un dispositivo que sólo tenga que leer datos (OUT desde el CPC) y escribir (IN desde el CPC)?

Creo que son necesarias 8 para el bus de direcciones (se descartan 8) y 8 para el de datos.

Pregunto porque por más que he leído no me queda claro, por ejemplo, hablan del puerto &BF00, luego hacen LD BC,0xBC06 y OUT (C),C con lo que entiendo que el byte menos significativo se ignora.

Gracias.

[Kyp]

La instrucción OUT (C),C sería más bien OUT (BC),C
El CPC internamente solo utiliza los bits más significativos para decodificar sus puertos (para abaratar costes simplificar la electrónica) pero los dispositivos externos pueden (y deben) usar todos para no crear incompatibilidades entre dispositivos.

[cacharreo]

Como bien apunta @Kyp, para Amstrad CPC es más que recomendable hacer una decodificación completa (nunca parcial) del puerto de E/S. Por tanto se requieren entonces 27/28 líneas, las 16 del bus de direcciones, las 8 del bus de datos y las señales de control asociadas que son /IORQ, /RD (solo para lectura), /WR (solo para escritura) y, opcionalmente, es posible usar /M1.

Es necesario consultar tablas como esta para poder decidir qué puerto de E/S escoger para las operaciones del dispositivo externo.

Por último dejo un vídeo relacionado con el Z80, muy útil para refrescar conceptos.

[Fran123]

vale.... tiro por el lado barato, 19

a ver si es posible esto: utilizar un arduino nano para crear un dispositivo genérico al que conectar otros periféricos por protocolo serie

el arduino nano se puede quedar con 20 pines E/S libres: del 2 al 21. con esos pines se tienen los 8 bits de datos, los 8 bits más altos de la dirección, y los 3 de las señales. los pines 0 y 1 para el protocolo serie para conectarlo a otro dispositivo, módulo bluetooth, módulo de rádio, otro arduino, esp8266, esp32, ...



la funcion loop() del arduino haría lo siguiente:
- leer datos del puerto serie, guardarlos o procesarlos
- escuchar peticiones del procesador dirigidas al arduino y devolverles el dato requerido

os leo

[cacharreo]

De acuerdo que el Nano te va a dejar unos 20 pines E/S libres pero, tal como lo veo, no es necesario conectar las 27/28 líneas del bus de expansión al Nano. En mi opinión sería más eficiente enchufar el Nano a una placa con electrónica para hacer la decodificación (léase identificación) del puerto de E/S del CPC sobre el que trabajará el Nano y un registro para el dato con salidas triestado. El Nano iría conectado a este registro, a las señales de control del puerto de E/S del CPC y a las señales del puerto serie del dispositivo externo (por los puertos digitales 0 y 1).

Sobre las salidas triestado. Debe tenerse en cuenta que los buses (de datos, de direcciones,...) son compartidos por lo que cada dispositivo debe mantener sus conexiones a los mismos en un estado de alta impedancia (virtualmente desconectados) cuando no los use porque de esta manera se permite que otros dispositivos (microprocesador, memorias, PPI,...) utilicen los mismos buses. La lógica triestado hace posible que una señal pueda estar en estado lógico bajo (0), alto (1) o de alta impedancia (Hi-Z).

Podría pensarse que aprovechando que el Nano mantiene sus pines digitales en alta impedancia cuando están configurados como entrada (INPUT), bastaría con mantener los pines digitales del Nano conectados a buses configurados estrictamente como entradas excepto en los momentos en los que se lleve a cabo una salida de datos. Es decir, que para escribir se configura el pin digital del Nano en modo de salida (OUTPUT) y se escribe el bit para justo después devolver el pin digital al modo de entrada (INPUT). Lamentablemente esta estrategia no es fiable porque el Nano es terriblemente lento y aunque un ciclo de reloj (a 16MHz) sea de 62.5ns, una instrucción del ATmega328P que monta requiere como mínimo 4 ciclos (250ns) pero, además, el conjunto de instrucciones necesario para cambiar el modo del pin, escribir el dato, restaurar el modo del pin son muchas instrucciones por lo que nos iríamos al orden los microsegundos. Demasiado lento en la práctica aunque quizás en el caso de un CPC a (algo menos de) 4MHz pudiera ser viable aunque sea "pisando el freno" mediante /WAIT.

A propósito, ¿conoces USIFAC? Hace algo parecido pero utilizando un PIC. En Hackaday también hablan de algo similar.

[Fran123]

tengo usifac ii. decía arduino porque es la plataforma que conozco,y por lo que estoy viendo tiene más pines para ese fin que el esp32 y esp8266.

no conozco nada de la programación de los PICs y STMs, seguro que sería posible, indagaré más

pero si pilláis la idea y la podéis pulir, sería maravilloso

[cacharreo]

A continuación una propuesta rápida de placa de E/S (I/O shield) para un Nano (usa 14 pines, 16 con RX y TX) para un Amstrad CPC con conector MX4.


(click para ampliar)

Tiene decodificación completa del puerto de E/S cuya dirección se configura fácilmente mediante dos conmutadores deslizantes DIP de 8 posiciones (en el esquema, PORT H y PORT L),



la comunicación serie se realizaría por el conector de cabecera J2 (SERIAL).

Se puede usar desde el BASIC del Amstrad CPC utilizando los comandos OUT puerto,valor para salida (escritura) y INP(puerto) ó WAIT puerto, parametro1 [,parametro2] para entrada (lectura) según convenga.

[Fran123]

Hola

Con esa reducción del nº de pines se podría utilizar el arduino pro mini que es más pequeño, y además se pueden dejar libres los pines de SDA-SDL y CLK-MISO-MOSI

[issalig]

Pégale un vistazo a este proyecto
https://github.com/bmpc/amstrad_cpc6128_interface

Creo que tiene lo que buscas.

[cacharreo]

Con esa reducción del nº de pines se podría utilizar el arduino pro mini que es más pequeño,

Al coste de perder el chip de comunicación asíncrona serie (UART) y la comunicación USB.

y además se pueden dejar libres los pines de SDA-SDL y CLK-MISO-MOSI

MISO, MOSI y SCK están libres. También está libre el bit 2 del puerto B, es decir, el pin digital 10 del Nano.

Para el resto hay que tener en cuenta el rendimiento porque la asignación actual presupone el uso de interrupciones, la manipulación directa de puertos y está planeada para minimizar las instrucciones necesarias para la manipulación de bits. Con una asignación arbitraria dejando bits libres en los registros, posiblemente sea necesario cortar, desplazar dichos bits y ordenarlos según convenga a bits sueltos de otros registros.

Pégale un vistazo a este proyecto

Muchas gracias, éste no lo conocía ni lo había encontrado cuando busqué.

Así a primera vista no parece lo que busca @Fran123,
- se ve que usa un Arduino MEGA (no el Nano), que la decodificación del puerto es parcial (3 bits del bus de direcciones, A0, A5, A10, es decir, puertos XXXX X1XX XX1X XXX1 y XXXX X1XX XX1X XXX0 en su representación binaria),
- no usa /RD ni /WR,
- utiliza dos puertos de E/S del CPC,
- no está diseñado para la comunicación serie sino que lee de una tarjeta SD,
- ¿son realmente necesarias las resistencias de elevación sobre el bus de direcciones? y, lo más raro,
- la alimentación del MEGA se hace por VIN desde los +5V del CPC por lo que, debido a la caída del tensión en el regulador, ¿no serían necesarios al menos unos 6.4V-7V? Creo recordar que las especificaciones del MEGA recomendaban una tensión de alimentación de 9V-12V. Si es así y lo alimenta por VIN suponiendo que, con suerte, la propuesta funcionara toda la circuitería del MEGA estaría alimentada alrededor de los 3V largos ó 4V muy justos en vez de a 5V que es lo que requiere.