Sto cercando di costruire un computer homebrew Z80 per un po 'di divertimento retrocomputer e di insegnarmi le basi del design elettronico. Come prova di concetto, ho già assemblato con successo un sistema di base su breadboard nelle settimane precedenti.
L'attuale prototipo è estremamente semplice. Ho usato un cristallo a 4 MHz pilotato da un oscillatore Pierce 74HCT04 come orologio di sistema, due fermi 74HCT573 in modalità trasparente ( LEalta) come buffer per il bus di indirizzo a 16 bit, altri due 74HCT573 in direzioni opposte controllate da RDe NOT RDcome dati bidirezionali buffer del bus. Ho collegato una EEPROM AT28C256 da 100 ns (viene decodificato solo 16 KiB) e due chip SRAM da 8 KiB da 150 ns sul bus di sistema. Ho usato un 74HCT42 per generare il CSsegnale e ho cablato la OEEEPROM su bassa, WEalta, lasciando solo un segnale CS per controllare la EEPROM.
Tutto sulle breadboard è rumoroso, ma il sistema sembrava essere pienamente operativo dopo aver completato tutte le fasi. Ora può recuperare istruzioni dalla EEPROM, leggere e scrivere dati da / verso la SRAM, e ha una porta seriale ricavata da un altro latch 74HCT573, a cui D0è collegata D0,LE è (NOT (IOREQ NAND WR)), l'uscita esce Q1, in altre parole, solo una porta di uscita senza logica di decodifica dell'indirizzo. Ho scritto un programma di benchmark ad alta intensità di CPU / RAM e il mio computer può produrre il risultato atteso. Memdumps ha anche mostrato che lo Z80 può leggere correttamente tutti i byte dalla EEPROM, quindi tutto funziona.
Ma quando ho provato a sondare il D0pin del bus dati, stavo vedendo alcune strane "tacche" per alcune uscite logiche apparenti 1.
e sembrano apparire sempre per alcuni 1 logici poco dopo che il CSsegnale dell'EEPROM diventa attivo, ad esempio, ecco una cattura della strana tacca sovrapposta al segnale CS EEPROM blu.
Ho provato a isolare il problema, quindi ho cablato tutti i pin CS della SRAM su HIGH, rimuovendoli efficacemente dal sistema e ho scritto un semplice programma di test che non ha accesso alla memoria.
.org 0x00
di
xor a
loop:
out (0x00), a
inc a
jp loop
Ma il problema è invariato, strane "tacche" appaiono sempre per alcuni 1 logici, subito dopo MEMRQe / o (dato che ora è essenzialmente un chip) CS(blu) diventa basso.
Tutti i pin CS della SRAM sono ALTI, quindi il sistema ha praticamente un chip EEPROM AT28C256 come memoria e un latch come porta di uscita. Il sistema ha anche un programmatore interno al sistema fatto da un Atmega328p per riprogrammare la EEPROM al volo durante una richiesta DMA, ma non credo che sia il colpevole da quando ho provato tutti i dati e l'indirizzo del programmatore, e Ho visto tacche anche prima di aggiungere il programmatore.
Quindi le "tacche" devono essere create durante un ciclo di recupero del codice operativo. Quali sono?
Ho alcune ipotesi:
Non c'è niente di sbagliato, è solo causato dalla cattiva integrità del segnale delle breadboard e scomparirà automaticamente in un PCB ben progettato e ben disaccoppiato . La breadboard presenta ogni sorta di problemi di integrità del segnale: discrepanze di impedenza, riflessioni, capacità parassita, diafonia, EMI / RFI. I lunghi fili del bus che attraversano le schede probabilmente peggiorano il problema di un grado di grandezza.
Se è vero, puoi spiegare la natura delle "tacche"? Questo fenomeno ha un nome in EE? Ho visto molti overshoots e squilli prima, ma non ho mai visto le "tacche". E perché lo vedo solo per alcuni livelli logici?
Timing. È possibile che un breve "tempo di assestamento" dell'uscita EEPROM o di altri circuiti logici stia causando questo strano effetto sul bus?
Fan-out. Forse il bus lungo assorbe molta corrente e ha un'alta capacità, quindi l'uscita EEPROM ha avuto difficoltà a guidare il bus in alto? E probabilmente anche la sonda dell'oscilloscopio sta caricando il bus?
Contesa del bus o altri errori logici che hanno causato l'estrazione del bus dati. Improbabile, penso? Altri componenti sul bus sono isolati e non sono riuscito a vedere come una singola EEPROM AT28C256 o un fermo possano farlo. Ma immagino che sia ancora possibile a causa di un errore di cablaggio o di un cortocircuito interno nascosto nelle breadboard.
Aggiornamento: ho già usato i condensatori di disaccoppiamento e filtro sulla scheda sin dall'inizio. Ho usato parecchi condensatori di disaccoppiamento da 0,1 uF su tutte le schede e la CPU ha persino condensatori da 0,1 uF e 0,01 uF per il disaccoppiamento. L'attuale sistema ha 8 schede, ciascuna breadboard ha due condensatori in alluminio da 4,7 uF su entrambe le guide per il filtraggio locale. Inoltre, la potenza ottenuta dalla devboard ha un condensatore al tantalio 200 uF. Ma come ho detto, il problema è qui.
Non sono sicuro che sia adeguato, soprattutto considerando la difficoltà di posizionare 104 condensatori vicino ai chip su una breadboard. Forse l'aggiunta di più può risolverlo?
Quello che mi interessa è la causa principale del problema, se si può confermare che sono semplicemente i problemi intrinseci del disaccoppiamento inadeguato o della scarsa integrità del segnale sulla breadboard, posso smettere di tentare di perdere tempo per risolvere i problemi o preoccuparmi dal il progetto finale sarebbe un PCB. Ma non sono sicuro.
Grazie.
Update2: Secondo me, il commento di Bruce Abbott ha dato la risposta corretta e il problema è stato risolto! Anche se non posso provarlo fino a domani. Il colpevole è l'aggiornamento DRAM di Z80, vedere la mia risposta per i dettagli. Al momento non è necessaria una nuova risposta e accetterò la mia risposta quando confermerò la soluzione. Se non funziona, aggiornerò la domanda. Grazie per l'aiuto di tutti.
