Diseño del panel frontal binario Z80

1

Hola, colegas ingenieros,

Necesito ayuda con el diseño del diseño con una computadora con base en Z80 que estoy construyendo. Contará con un panel frontal binario.

Las siguientes funciones se pueden realizar a través del panel frontal. Estas son las cosas habituales que uno encontraría en una mini computadora vintage.

  • Bootstrapping
  • Examen de memoria y carga.
  • visualización del estado de la CPU
  • LED de identificación del ciclo de la CPU
  • Identificación de modo (instrucción de captura, ISR, I / O, DMA, etc.)
  • control del procesador
  • Control de interrupción
  • Protección de memoria
  • restablecer
  • afirmación DMA
  • Selección de velocidad del reloj
  • Ejecutar / Detener
  • Opción de diseño del panel frontal

Un panel frontal se puede construir de varias maneras. Todavía queda mucho por decidir aquí. Básicamente, hay dos opciones de diseño llamadas A y B.

  • Opción A: el panel frontal está vinculado directamente a la dirección, los datos y los buses de control que supervisa. Se emplea hardware adicional para leer y escribir en la memoria y cargar (y rastrear) el contador del programa. El Altair 8800 original realmente atascó las instrucciones de salto en el bus cuando se presionó el interruptor de funcionamiento.

  • Opción B: el panel frontal es esencialmente una pantalla LED elaborada y un periférico de entrada binaria que se controla mediante un software (un controlador). Esto podría agregar la visualización del registro de la CPU.

Las consideraciones se detallan a continuación.

  1. Certeza: en la Opción A, el estado real de los autobuses siempre se mostrará fielmente. En la Opción B, el estado de los buses no siempre puede representarse de manera confiable porque se requiere una capa de software de intermediación que sea menos confiable que el hardware. Además, el software deberá distinguir entre el estado informado del procesador y el estado real en tiempo real del procesador al mostrar el estado del panel frontal.

  2. Legibilidad: si, en la Opción A, los indicadores LED del panel frontal siguen los buses en todo momento, se pueden esperar pantallas indeterminadas que representan el bus entre los tiempos de datos válidos. Esto podría resultar engañoso. Como mínimo, se necesitarán pestillos para capturar los estados del bus en el momento adecuado. Esto tomará un poco de hardware. La opción B no plantea tales problemas, o mejor dicho, esto se hace en el software.

  3. Confusión: la pantalla se ejecutará durante las aplicaciones de usuario. En la Opción B, el software de pantalla deberá ejecutarse con la aplicación. Esto complica las cosas. ¿Con qué frecuencia puede actualizarse el panel frontal? ¿Debe actualizarse después de cada instrucción?

  4. Autenticidad: la opción A está vinculada al hardware y es representativa de los paneles frontales reales utilizados en las computadoras mini y mainframe vintage. La opción B tiene una sensación más moderna y de emulación.

  5. Utilidad: ¿Se puede diseñar el panel frontal de una manera, con la Opción A o la Opción B, para admitir puntos de interrupción y depuración?

Aquí algunas reflexiones sobre la Opción B.

A. Usando la Opción B, el panel frontal podría actualizarse en cada instrucción usando señales de bus de extracción de instrucciones, interrupciones y algunas puertas. Pero el rendimiento de la aplicación será excelente.

B. Alternativamente, un controlador del panel frontal podría tomar instantáneas periódicas del estado del procesador a una velocidad específica y publicar los resultados en el panel frontal.

C. Si se usa la Opción B, el Panel frontal podría ignorarse durante la ejecución de la aplicación y estar disponible para la aplicación de luces intermitentes y entradas de interruptor, lo cual es atractivo y tiene mucho mérito. La opción A no permite el uso de la aplicación del Panel frontal.

D. La utilidad, como se definió anteriormente, y la disponibilidad para la aplicación son las consideraciones de diseño más importantes. La certeza, como se definió anteriormente, es la siguiente consideración de diseño importante.

La opción A, me temo, aumentará significativamente la cantidad de fichas.

¿Alguien tiene alguna idea sobre esto? ¿Alguien ha resuelto este problema antes que yo?

    
pregunta Harry Pots

2 respuestas

1

Yo sugeriría usar un CPLD o FPGA para conectar el bus a algo así como una matriz de 16x8 LED. Dicho diseño permitiría alternar entre diferentes modos de visualización (por ejemplo, podría tener un modo que capture la dirección de los ciclos / M1 y, por lo tanto, mostraría un contador de programa además del bus de direcciones). Si usa un LED multiplexado, sería bueno que el CPLD / FPGA mantenga un conteo de la fracción del tiempo que debe estar encendida cada luz, y ajuste el brillo de los LED de forma correspondiente.

Otra posibilidad sería usar un chip ARM rápido para observar el bus y manejar las cosas en tiempo real. Es posible que un ARM7-TDMA económico se siente en un bus 6502 de 1.19MHz y emule un chip RAM (¡incluso sin acceso a ninguna señal que no sea A0-12 y D0-D7!); un bus Z80 de 4MHz puede ser un poco más difícil, pero Z80 no hace las cosas en absolutamente todos los ciclos como lo hace un 6502.

    
respondido por el supercat
0

Sugiero que la diferencia entre la opción A y la opción B es su deseo de proporcionar un entorno de arranque, normalmente en ROM, para interactuar con el panel frontal.

La opción A no requiere un entorno de arranque y es funcional sin un entorno de arranque inicial. Por cierto, la opción A se puede implementar como puertos de entrada (interruptores) y salida (LED) Z80. No recuerdo si el Altair permitió la salida a los LED, pero los 8 interruptores de dirección de la izquierda también se llamaron interruptores de detección.

La opción B requiere un software que no sea volátil y que se ejecute cuando la computadora está encendida. La ROM KIM-1 controlaba el teclado y la interfaz LED, así como la interfaz de la cinta de cassette.

    
respondido por el linhartr22

Lea otras preguntas en las etiquetas