Dispositivo E/S para Amstrad CPC

[Fran123]

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.

Bueno, sugerí el mini porque es algo más corto, de ancho son iguales.
El puerto USB del nano se utiliza para programarlo, el mini se programa conectando unos pines a un adaptador usb-ttl.

[cacharreo]

Bueno, sugerí el mini porque es algo más corto, de ancho son iguales.
El puerto USB del nano se utiliza para programarlo, el mini se programa conectando unos pines a un adaptador usb-ttl.

En esto estamos de acuerdo, un Nano también se puede programar utilizando un módulo UART (serie) externo o por SPI pero al hablar del Pro Mini y dada la propuesta que manejamos (comunicación serie con otros dispositivos desde el CPC), seguro que no entiendo algo pero no le veía mucho sentido a prescindir del hardware (UART) para tener que emular la comunicación serie por software.

Por cierto, interesante debate.

[Fran123]

ahora sí que no te entiendo yo

al final los dos tienen prácticamente los mismos pines, para el propósito necesitaríamos:
-8 pines para recibir/recibir el dato
-3 pines para sincronizar señales de comunicación con el puerto de expansión
- 1 pin para que comunica si la direccion en el bus es la configurada (el arduino ya se enteraría por interrupción o por polling)
- 2 pines rx/tx para implementar el protocolo de comunicación serie con otro dispositivo (módulo bluetooth o radio). estos dos pines ya pueden ser los estándar del arduino (0 y 1) u otros (utilizando la librería SoftwareSerial.h)

Ahora, lo mismo me pierdo algo, y desde el puerto de expansión ya me puedo comunicar con algún otro dispositivo por protocolo serie, pero creo que no.

En mente tengo que se podría utilizar los módulos de bluetooth HT-05 y radio HC-12. Ya los he utilizado y son bastante fáciles.

los pinouts:

[cacharreo]

ahora sí que no te entiendo yo

Es normal pero básicamente coincidimos en casi todos.

La diferencia importante pasa por entender que el Nano no nos va a dar la velocidad necesaria así que, aunque nos apañemos más o menos con el Z80, descartado por completo algo como usar SoftwareSerial.

En cuanto a pines,
-8 para el dato
-5 para señales de comunicación con el Z80 (/BUSRESET, /RD, /WR, /WAIT e /IO que es nuestra)
-2 para la comunicación serie (RX y TX en D0 y D1, esto no se puede cambiar)
-1 pin la interrupción (D2, tampoco hay otra opción mejor)

Y respecto a la asignación concreta de pines, que haya estudiado hay dos permutaciones (asignaciones) de pines que están más cerca de lo ideal y manejar una de ellas genera menos instrucciones (del ATmega328P) que manejar la otra por lo cual nos hemos quedado con esa.

El dispositivo serie de momento es lo de menos. Para posibles pruebas podríamos utilizar un módulo USB-serie (con FT232RL, CH340x, CP210x, PL210x,...) para hablar entre el Amstrad y el PC con una aplicación de terminal serie. Los kbps los discutimos más adelante.

[mad3001]

Me temo que un atmega328p se te puede quedar corto para dar la respuesta rápidamente a un IN / OUT desde el CPC a 4Mhz (algo menos si tenemos en cuenta que para no entrar en conflicto con el video se reduce algo)... te va a tocar hacerle algo de overclock y currarte una buena rutina de interrupción en el atmega para dar el servicio en el timing requerido... sería más factible bien usar un chip más rápido (ESP u otro a más MHz) o bien combinarlo con una CPLD que realmente sea la que dé el servicio de interrupción...
Si no tienes prisa en la INT también valdría sujetar el WAIT...

[Fran123]

hola

la idea que tenía es mas o menos:

Código: Seleccionar todo

SoftwareSerial modulo (pines);     

void loop() {
   if (modulo.available() > 0) {
      dato = modulo.read();
   }
}

void interrupt() {
   Serial.write(dato);
}

para comunicarnos con el módulo SoftwareSerial que es más lento que el Serial, y el Serial para comunicar con el z80 y que los tiempos de espera sean menores.

Desconozco cuanto puede tardar la respuesta, pero tampoco puede ser muy lenta.

Donde digo arduino mini también digo wemos d1 mini (esp8266) o alguna versión de esp32 que son los que conozco.
Tal vez con algún PIC o STM la solución sea mejor.

[cacharreo]

Si es por usar otro microcontrolador de un precio económico, podría utilizarse una Raspberry Pi Pico, que es superior al Nano en casi todo aunque un ESP32-S3 con BT quizás sea más conveniente en este caso.

Si no tienes prisa en la INT también valdría sujetar el WAIT...

Esa es la idea pero, sobre todo, hacerlo lo más rápido posible pero aún así la velocidad final de la comunicación serie no podría ser alta.

[Scooter]

No estoy muy puesto en el CPC, más bien nada.
El C64 tenía ciertas lineas desde la ULA que ya hacían bastante parte de la decodificación para hacer "carchutos" y solo tendrías que añadir parte.

En general necesitarías decodificar los 16 bits de direcciones, algunos menos si la expansión ocupa varias direcciones, podrían ser 12 o 14...
Las lineas de lectura y escritura y la que selecciona IO/memoria. No sé si me dejo algo.

Salvo que tengas un microcontrolador muy rápido ahí irían dos latches tipo 74hc274 uno en cada sentido para que el Z80 escriba el dato y permanezca, y el equipo esclavo lo lea "cuando quiera" y responda en el otro latch para que el Z80 lo lea "cuando quiera". A este sistema habría que añadir algún control de flujo o handshaking o interrupciones en ambos sentidos...

Parece ser que la Pi Pico tiene un sistema ES muy potente, GTI 16V que permitiría hacer esto fácilmente, lo bastante rápido con los pines de ES "a pelo" *.
Pero la pipico va a 3V3 osea que habría que adaptar niveles, y para eso pones latches...

No sé.

[cacharreo]

No estoy muy puesto en el CPC, más bien nada.

Para este caso no hace falta mucho más que estar puesto en la E/S del Z80.

En general necesitarías decodificar los 16 bits de direcciones, algunos menos si la expansión ocupa varias direcciones, podrían ser 12 o 14...
Las lineas de lectura y escritura y la que selecciona IO/memoria. No sé si me dejo algo.

En el esquema que he publicado se hace una decodificación completa de los 16 bits que se pueden configurar mediante conmutadores DIP.

Salvo que tengas un microcontrolador muy rápido ahí irían dos latches tipo 74hc274 uno en cada sentido para que el Z80 escriba el dato y permanezca, y el equipo esclavo lo lea "cuando quiera" y responda en el otro latch para que el Z80 lo lea "cuando quiera". A este sistema habría que añadir algún control de flujo o handshaking o interrupciones en ambos sentidos...

Esto también lo habíamos planteado con un 74HCT245 y un 74HCT273/74HCT274 para encargarse de la lectura y escritura respectivamente.

Parece ser que la Pi Pico tiene un sistema ES muy potente, GTI 16V que permitiría hacer esto fácilmente, lo bastante rápido con los pines de ES "a pelo" *.
Pero la pipico va a 3V3 osea que habría que adaptar niveles, y para eso pones latches...

No es un gran problema solo que hay que traducir los niveles para bastantes líneas.

[Fran123]

Si es por usar otro microcontrolador de un precio económico, podría utilizarse una Raspberry Pi Pico, que es superior al Nano en casi todo aunque un ESP32-S3 con BT quizás sea más conveniente en este caso.

Si no tienes prisa en la INT también valdría sujetar el WAIT...

Esa es la idea pero, sobre todo, hacerlo lo más rápido posible pero aún así la velocidad final de la comunicación serie no podría ser alta.

el esp8266 va a 80 Mhz, y el esp32 a 240 un procesador y 160 el otro, además ya tiene el bluetooth.