SIMM, un dubbio (x esperti)

prova a guardare sul datasheet delle DRAM usate sul modulo, cercati i Tsetup e Thold dei pin d'indirizzo rispetto a CAS e RAS se sono specificati rispetto ai fronti di discesa dovrebbe andare bene il tuo approccio se sono specificati rispetto al fronte di salita direi di no

manca pero' il ciclo di lettura come lo faresti ?

le WOM ( write only memory ) non hanno avuto un grande successo anche se signetics ci provo' un po' di anni fa

ho trovato il DS

si, sono specificati rispetto al falling-edge (al 90%)

idem alla scrittura ma tengo WE# alto per tutto il ciclo... è ok?

e che cosa se ne fa uno di una memoria che può essere solo scritta e non letta?

ora si tratta di provare... spero solo che non cambi tutto se cambio il modulo di memoria altrimenti è un lavoro sprecato!

-ice-

e' quello che temevo quando attacchi il ciclo di lettura devi essere veloce a cambiare direzione al 'bus-dati-indirizzi'

controlla i tempi di accesso in lettura cerca il Tdatavalid dovrebbe essere riferito al CAS

il link al datasheet signetics:

leggilo attentamente

no questo no, le DRAM sono ( erano ) tutte molto simili

e non dimenticare i cicli di refresh , dovrebbe essere presente la modalita' CAS only ( o e' RAS only ? )

piuttosto se parli di 22 bit d'indirizzo vuol dire che hai moduli 4 MB, ragazzo fortunello :-)

questo e' un classico per chi gioca con le DRAM

Be, per esempio per costruire delle FINO

Ciao Giulio

mi stavo rileggendo quell'articolo e ho visto una frase che non mi piace affatto

a pagina 8

In DRAMS it is CAS that controls the output drivers.

rischi dei seri conflitti di 'bus'

prova a mettire delle resistenze da un centianaio di ohm per isolare bus dati della simm col resto del mondo

ci ho ragionato su un po' per essere la collisione dei bus potrebbe essere evitata (in lettura) perchè prima che il dato diventi disponibile (dopo l'attivazione del CAS, proprio come mi facevi notare) deve passare un tempo pari a Ta-cas (CAS-access-time e cioè dopo che il CAS viene attivato deve trascorrere minimo Ta-cas prima che il bus dati della dram esca dall'alta impedenza --> data valid). Questo Ta-cas è dell'ordine delle decine di ns e quindi ho tutto il tempo per portare le linee del micro in input

invece il problema non arginabile, ho scoperto, è che il segnale W# in realtà serve per discriminare fra lettura/scrittura e non per dare il comando -write- infatti (in SCRITTURA) quando attivo il CAS#, il W# deve essere già stato attivato da almeno Tsu(w-cas) (= write-setup-time-before-cas) questo implica che il bus dati ed indirizzi (in particolare quando il bus porta l'indirizzo della colonna) NON possono essere condivisi :( per cui sono costretto a mettere dei latch ora vedo di recuperare una vecchia MB... sono curioso di capire (se riesco) come hanno risolto il problema per caso nell' 80486 il bus indirizzi e dati sono separati???

grazie

-ice-

lascia perdere le mother board li e' tutto risolto con un ASIC che si incarica tra l'altro di gestire il refresh in hardware.

si il 486 ha bus dati ed indirizzi separati , se non fisicamente logicamente ( potrebbe essere della classe 80x86 ) e comunque e' una CPU troppo complessa per studiarla e fa largo uso di ASIC esterni per gestire i 'dettagli'

da studiare come CPU piu' semplici ci sono lo Z80 (o 6809 o z180 ) che ha bus dati ed indirizzi separati, o l'8088 ( o 8086 o 8051 ) che hanno il bus dati multiplexato col bus indirizzi.

in questo caso c'e' un ulteriore segnale ALE ( address latch enable ) o nome simile da usarsi per demultiplexare gli indirizzi ( che vengono emessi per primi nel ciclo di bus ) utilizzando dei latch esterni tipicamente 74373 o 74573 o qualche chip 'dedicato' della serie 82xx ( intel )

una volta ottenuto il bus dati-indirizzo completo comunque gli indirizzi per le DRAM vengono rimultiplexati.

quel documento di cui ti ho mandato il link la precedente posta tratta questi argomenti in maniera abbastanza completa