eeprom + math

docs/_docs/90-eeprom.md

@@ -7,34 +7,34 @@ excerpt: "EEPROM Programmer"
 
 **WORK IN PROGRESS - WORK IN PROGRESS - WORK IN PROGRESS**
 
-Tutti i progetti descritti sono basati su Arduino, ad evidenza della versatilità di questo strumento.
+Tutti i progetti descritti in questa pagina sono basati su Arduino, ad evidenza della sua versatilità.
 
 ## PROGRAMMATORE
 
 - Nei link mettere il link a Tommy PROM, spiegare  CHE IL MIO PROGRAMMATORE DI EPPROM  di è basata un po sul DIWSEGNO  originale di ben , UN PO' SUL TOMMYPROM
 - Verificare anche se è Il programmatore dietro di ben Tom che utilizza lo stesso codice di programmazione del Tommyprom; in realtà mi sembra di ricordare che sia una versione tagliata del tommyprom
 
-La mia prima esperienza con un programmatore di EEPROM risale alla costruzione del computer SAP di Ben Eater e alla realizzazione del programmatore basato sul suo schema e sketch. Questo progetto, molto semplice, permetteva di programmare le EEPROM del microcode, ma risultava particolarmente lento.
+La mia prima esperienza con un programmatore di EEPROM risale alla costruzione del computer SAP di Ben Eater e alla realizzazione del programmatore basato sul suo schema e sketch. Questo progetto, molto semplice, permetteva di programmare le EEPROM del microcode, ma la scrittura risultava particolarmente lenta.
 
-Durante lo studio del computer NQSAP di Tom Nisbet e la rivisitazione del suo progetto per creare il computer BEAM, mi ero reso conto che il numero di EEPROM da programmare (quattro anziché due) e la loro dimensione avrebbero ulteriormente aumentato i tempi di programmazione di ogni revisione del microcode. Il programmatore di Ben era funzionale, ma non sfruttava la possibilità delle EEPROM moderne di scrittura a *pagine*, che permette la programmazione di una EEPROM da 32KB in pochi secondi. Ciononostante, continuavo a usare questo programmatore, con tempi di scrittura di circa 90 secondi per una EEPROM.
+Durante lo studio del computer NQSAP di Tom Nisbet e la rivisitazione del suo progetto per creare il computer BEAM, mi ero reso conto che il numero di EEPROM da programmare (quattro anziché due) e la loro dimensione avrebbero ulteriormente aumentato i tempi di programmazione di ogni revisione del microcode. Il programmatore di Ben era funzionale, ma non sfruttava la possibilità delle EEPROM moderne di scrittura a *pagine*, che permette la programmazione di una EEPROM da 32KB in pochi secondi. Ciononostante, continuavo a usare questo programmatore, con tempi di scrittura di circa 90 secondi per ogni EEPROM.
 
-Con il progredire della costruzione dei moduli del BEAM, le riprogrammazioni del microcode diventavano sempre più frequenti per completare l'Instruction Set e risolvere i bug. Il tempo trascorso ad attendere il completamento dei cili di programmazione iniziava a diventare frustrante.
+Con il progredire della costruzione dei moduli del BEAM, le riprogrammazioni necessarie ad implementare l'Instruction Set e risolvere i bug del microcode diventavano sempre più frequenti; il tempo trascorso ad attendere il completamento dei cicli di programmazione iniziava a diventare frustrante.
 
-Tom aveva sviluppato un suo programmatore, il <a href="https://github.com/TomNisbet/TommyPROM" target="_blank">TommyPROM</a>, che supporta una varietà di EPROM, EEPROM e memorie Flash. Questo programmatore include un software molto completo ed è molto veloce grazie al supporto della modalità di scrittura Page Write. Una versione ridotta del software del TommyPROM è stata utilizzata da Tom e pubblicata sul suo repository dell'NQSAP per il semplice scopo di programmare le EEPROM.
+Tom aveva sviluppato un suo programmatore, il <a href="https://github.com/TomNisbet/TommyPROM" target="_blank">TommyPROM</a>, che supporta una varietà di EPROM, EEPROM e memorie Flash. Questo programmatore include un software molto completo e molto veloce grazie al supporto della modalità di scrittura *Page Write.* Una versione ridotta del software del TommyPROM - col semplice scopo di programmare le EEPROM 28C256 - è stata utilizzata da Tom e pubblicata sul suo repository dell'NQSAP.
 
-Non volevo iniziare un nuovo progetto, quello del programmatore di EEPROM, mentre stavo ancora lavorando sul BEAM. Tuttavia, a un certo punto ho realizzato che, a lungo termine, costruire un programmatore basato sul TommyPROM mi avrebbe fatto risparmiare più tempo rispetto a quello che avrei sprecato utilizzando il programmatore di Ben.
+Non volevo iniziare un nuovo progetto, quello di un nuovo programmatore di EEPROM, mentre stavo ancora lavorando sul BEAM. Tuttavia, a un certo punto ho realizzato che, a medio termine, costruire un programmatore basato sul TommyPROM mi avrebbe fatto risparmiare più tempo rispetto a quello che avrei sprecato continuando ad utilizzare il programmatore basico di Ben.
 
 Il mio programmatore iniziale era basato sul design di Ben Eater, quindi utilizzava i '595 anziché i '164 utilizzati in origine da Tom. In una sezione della documentazione, Tom evidenziava che il suo codice non funzionava sul progetto di Ben e che necessitava di significative modifiche. Se si desideravano i benefici del TommyPROM sull'hardware di Ben, Tom indicava che la strada più facile era quella di non modificare il software, ma di adattare l'hardware rendendolo uguale a quello del TommyPROM.
 
-Nella mia testardaggine, ho deciso di fare un compromesso: modificare solo parzialmente l'hardware inizialmente sviluppato seguendo il progetto di Ben e approfittarne per studiare e aggiornare il software di Tom, rendendolo compatibile con il minor numero di modifiche possibili all'hardware.
+Nella mia testardaggine, ho deciso di fare un compromesso: modificare solo parzialmente l'hardware sviluppato seguendo il progetto iniziale di Ben e approfittarne per studiare e aggiornare il software di Tom, rendendolo compatibile col mio hardware effettuando il minor numero di modifiche possibili.
 
-Le modifiche apportate rispetto al programmatore del SAP sono le seguenti:
+Le modifiche minime necessarie rispetto al programmatore originale del SAP sono state le seguenti:
 
-- il pin Write Enable (/WE) della EEPROM non viene più viene controllato dal segnale D13 di Arduino, bensì da A2.
+- il pin Write Enable della EEPROM (/WE) non viene più viene controllato dal segnale D13 di Arduino, bensì da A2.
 - il pin Chip Enable (/CE) non è più connesso a ground (chip sempre attivo), ma è controllato dal pin A0 di Arduino.
-- il pin Output Enable (/OE) non è più connesso allo shift register, ma è controllato dal pin A1 di Arduino.
+- il pin Output Enable (/OE) non è più connesso allo Shift Register, ma è controllato dal pin A1 di Arduino.
 
-Nello sketch di Ben, D13 controlla il segnale Write Enable. Poiché D13 è internamente connesso al LED integrato su Arduino, che lampeggia al boot, potrebbero verificarsi scritture indesiderate della EEPROM ad ogni accensione del programmatore. Questo non è un problema per lo sketch di Ben, perché ad ogni esecuzione la EEPROM viene completamente programmata, sovrascrivendo eventuali scritture spurie. Tuttavia, poiché il TommyPROM può essere utilizzato anche per sole letture da una EEPROM, le scritture spurie potrebbero causare un problema.
+Nello sketch di Ben, D13 controlla il segnale Write Enable. Poiché D13 è internamente connesso al LED integrato su Arduino, che lampeggia al boot, potrebbero verificarsi scritture indesiderate della EEPROM ad ogni accensione del programmatore. Questo non è un problema per lo sketch di Ben, perché ad ogni esecuzione la EEPROM viene completamente programmata, sovrascrivendo eventuali scritture spurie. Tuttavia, poiché il TommyPROM può essere utilizzato anche per effettuare letture da una EEPROM, le scritture spurie iniziali potrebbero causare un problema.
 
 **Vale anche per i 595?** Il pin /OE controllato dagli Shift Register  che nella design del Tommy promnon funziona bene perché OE verrebbe modificato ogni volta che vengono inviati nuovi indirizzi agli shift register 164.
 
@@ -59,8 +59,3 @@ Per questi motivi Tom consiglia di effettuare qualche semplice modifica hardware
 - Il video <a href="https://www.youtube.com/watch?v=K88pgWhEb1M" target="_blank">Build an Arduino EEPROM programmer</a> e il repository GitHub <a href="https://github.com/beneater/eeprom-programmer" target="_blank">Arduino EEPROM programmer</a> di Ben Eater.
 - Il programmatore di EEPROM <a href="https://github.com/TomNisbet/TommyPROM" target="_blank">TommyProm</a> di Tom Nisbet.
 - Il programmatore di EEPROM <a href="https://github.com/TomNisbet/TommyPROM" target="_blank">TommyProm</a> di Tom Nisbet.
-
-
-## TO DO
-
-- TBD

docs/_docs/97-bin-math.md

@@ -819,7 +819,7 @@ Andiamo ora a realizzare un Carry Look Ahead Adder, ma prima, considerando quant
 
 *Logica della somma del Modified Full Adder.*
 
-La somma **Q**, come sempre, corrisponde ad A<sub>0</sub>⊕B<sub>0</sub>⊕C<sub>0</sub>. Aggiungiamo al Full Adder una porta OR e una porta AND con il solo scopo di ottenere i termini p (cioè A<sub>0</sub>+B<sub>0</sub> per il primo Adder) e g<sub>0</sub> (cioé A<sub>0</sub>*B<sub>0</sub> per il primo Adder).
+La somma **Q**, come sempre, corrisponde ad A<sub>0</sub>⊕B<sub>0</sub>⊕C<sub>0</sub>. Aggiungiamo al Full Adder una porta OR e una porta AND con il solo scopo di ottenere i termini **p** (cioè A<sub>0</sub>+B<sub>0</sub> per il primo Adder) e **g** (cioé A<sub>0</sub>*B<sub>0</sub> per il primo Adder).
 
 Aggiungiamo la logica del Carry C<sub>1</sub> = g<sub>0</sub> + p<sub>0</sub>\*C<sub>0</sub>:
 
@@ -845,7 +845,7 @@ Come si può notare dagli screenshot, utilizzati per gentile concessione del [pr
 
 In definitiva, il lavoro svolto per creare il Carry in un CLA Adder è molto elevato, ma si hanno in cambio le massime prestazioni.
 
-Un aspetto da tenere in considerazione potrebbe essere il fattore fan-in, che limita il numero di ingressi che una porta logica può avere. La porta OR finale, che genera il Carry Out, avrà un numero di input sempre maggiore all'aumentare del numero di bit dell'Adder, così come le AND connesse a questa OR. A un certo punto sarà necessario suddividere le OR e le AND in due livelli, causando così un incremento di 2 livelli nel computo totale dei livelli dell'Adder. Pertanto, il numero di livelli aumenta anche all'aumentare del numero dei bit del CLA Adder, ma con una linearità decisamente inferiore rispetto a quella del Ripple Carry Adder, nel quale ogni singolo bit aggiunge ben due livelli da attraversare.
+Un aspetto da tenere in considerazione potrebbe essere il fattore fan-in, che limita il numero di ingressi che una porta logica può avere. La porta OR finale, che genera il Carry Out, avrà un numero di input sempre maggiore all'aumentare del numero di bit dell'Adder, così come le AND connesse a questa OR. A un certo punto sarà necessario suddividere le OR e le AND in due livelli, causando così un incremento di 2 livelli nel computo totale dei livelli dell'Adder. Pertanto, il numero di livelli aumenta anche all'aumentare del numero dei bit del CLA Adder, ma con una velocità decisamente inferiore rispetto a quella del Ripple Carry Adder, nel quale ogni singolo bit aggiunge ben due livelli da attraversare.
 
 ## Le sottrazioni con gli Adder
 

docs/_docs/todo.md

@@ -27,6 +27,11 @@ excerpt: "Cosa c'è da fare"
 
 - mettere dei link
 
+## EEPROM
+
+- ci sono 3 sketch: microcode, loader, SSD
+- nel microcode ci sono due diverse chiamate writeEEPROM e writeEEPROM2, credo che la seconda non serva
+
   ## ALU
 
 - /WE ↘↗