Estoy tratando de construir una computadora homebrew Z80 para divertirme en la retrocomputación y aprender las bases del diseño electrónico. Como prueba de concepto, ya he ensamblado un sistema básico en placas de prueba con éxito en las semanas anteriores.
El prototipo actual es extremadamente simple. Utilicé un cristal de 4 MHz impulsado por un oscilador Pierce 74HCT04 como reloj del sistema, dos pestillos 74HCT573 en modo transparente ( LEalto) como búfer para el bus de direcciones de 16 bits, otros dos 74HCT573 en direcciones opuestas controlados por RDy NOT RDcomo datos bidireccionales búfer de bus. I adjunto un 100 ns (se descodifica sólo el 16-KiB) AT28C256 EEPROM y dos 150 ns 8-KiB chips de SRAM al bus del sistema. Utilicé un 74HCT42 para generar la CSseñal y cableé OEla EEPROM a baja, WEa alta, dejando solo una señal CS para controlar la EEPROM.
Todo en las placas de pruebas es ruidoso, pero el sistema parecía estar completamente operativo después de completar todas las etapas. Ahora puede obtener instrucciones de la EEPROM, leer y escribir datos desde / hacia la SRAM, y tiene un puerto serie hecho desde otro pestillo 74HCT573, D0está conectado D0, LEes decir (NOT (IOREQ NAND WR)), la salida sale Q1, en otras palabras, solo un puerto de salida sin lógica de decodificación de dirección. He escrito un programa de referencia de uso intensivo de CPU / RAM y mi computadora puede generar el resultado esperado. Memdumps también mostró que el Z80 puede leer todos los bytes de la EEPROM correctamente, por lo que todo está funcionando.
Pero cuando intenté sondear el D0pin del bus de datos, estaba viendo algunas "muescas" extrañas para algunas salidas lógicas 1 aparentes.
y parece que siempre aparece durante algunos 1 lógicos poco después de que la CSseñal de EEPROM se active, por ejemplo, aquí hay una captura de la muesca extraña superpuesta en la señal azul de EEPROM CS.
Traté de aislar el problema, así que conecté todos los pines CS de la SRAM a ALTA, eliminándolos efectivamente del sistema, y escribí un programa de prueba simple que no tiene acceso a la memoria.
.org 0x00
di
xor a
loop:
out (0x00), a
inc a
jp loop
Pero el problema no se ha modificado, extraño "muescas" sigue siempre aparecen para algunos 1s lógicas, justo después MEMRQy / o (ya que es esencialmente un chip ahora) CS(azul) pasa a nivel bajo.
Todos los pines CS de la SRAM son ALTOS, por lo que el sistema es prácticamente solo tiene un chip EE28 de AT28C256 como memoria y un pestillo como puerto de salida. El sistema también tiene un programador en el sistema hecho de un Atmega328p para reprogramar la EEPROM sobre la marcha durante una solicitud de DMA, pero no creo que sea el culpable ya que confié en todos los datos y la salida de direcciones del programador, y He visto muescas incluso antes de agregar el programador.
Por lo tanto, las "muescas" deben crearse durante un ciclo de búsqueda de código de operación. ¿Qué son?
Tengo algunas hipótesis:
No hay nada malo, solo es causado por la mala integridad de la señal de las placas de prueba, y desaparecerá automáticamente en una PCB bien diseñada y desacoplada . La placa de pruebas tiene todo tipo de problemas de integridad de la señal: desajustes de impedancia, reflexiones, capacitancia parásita, diafonía, EMI / RFI. Los largos cables del bus que atraviesan los tableros probablemente empeorarán el problema en un grado de magnitud.
Si es verdad, ¿puedes explicar la naturaleza de las "muescas"? ¿Este fenómeno tiene un nombre en EE? He visto muchos excesos y timbres antes, pero nunca he visto las "muescas". ¿Y por qué lo veo solo para algunos niveles lógicos?
Sincronización. ¿Es posible que un corto "tiempo de asentamiento" de la salida EEPROM u otros circuitos lógicos esté causando este efecto extraño en el bus?
Desplegarse. ¿Quizás el bus largo consume mucha corriente y tiene una alta capacitancia, por lo que la salida EEPROM estaba teniendo dificultades para conducir el bus alto? ¿Y probablemente la sonda del osciloscopio también está cargando el bus?
La contención del bus u otros errores lógicos que causaron que algo tirara del bus de datos. Improbable, creo? Otros componentes en el bus están aislados, y no pude ver cómo una EEPROM AT28C256 o un pestillo pueden hacer esto. Pero supongo que todavía es posible debido a un error de cableado o un corto interno oculto en las placas de pruebas.
Actualización: ya usé condensadores de desacoplamiento y filtrado en el tablero desde el principio. He usado bastantes condensadores de desacoplamiento de 0.1 uF en todas las placas, y la CPU incluso tiene condensadores de 0.1 uF y 0.01 uF para desacoplar. El sistema actual tiene 8 placas, cada placa tiene dos condensadores de aluminio de 4.7 uF en ambos rieles para el filtrado local. Además, la potencia obtenida de la placa de desarrollo tiene un condensador de tantalio de 200 uF. Pero como dije, el problema está aquí.
Sin embargo, no estoy seguro de si es adecuado, especialmente teniendo en cuenta la dificultad de colocar 104 condensadores cerca de los chips en una placa de pruebas. ¿Quizás agregar más puede arreglarlo?
Lo que me interesa es la causa raíz del problema, si se puede confirmar que se trata simplemente de los problemas inherentes de desacoplamiento inadecuado o mala integridad de la señal en el tablero, puedo dejar de intentar perder el tiempo para solucionarlo o preocuparme por ello desde El diseño final sería un PCB. Pero no estoy seguro.
Gracias.
Actualización 2: En mi opinión, ¡creo que el comentario de Bruce Abbott ha dado la respuesta correcta y el problema está resuelto! Aunque no puedo probarlo hasta mañana. El culpable es la actualización DRAM de Z80, vea mi propia respuesta para más detalles. Actualmente, no se necesita una nueva respuesta, y aceptaré mi propia respuesta cuando confirme la solución. Si no funciona, actualizaré la pregunta. Gracias por la ayuda de todos.
