Denial

Dai che sei sulla buona strada! Cross fingers

Purtroppo la saga continua...
Sostituito il 7406 con uno nuovo, ho un segnale di reset pulito adesso.
Ancora schermo nero.
Ho cominciato un controllo chip X chip con un VIC gemello funzionante e mi ha evidenziato un problema alla linea dati ram pin 13, e ho trovato una pista interrotta, proprio a dx della UE6, riparata nell' 84.
Speravo di aver trovato, ho fatto un ponte, ma niente ancora.
Non mi arrendo, ma le speranze diminuiscono.

Coraggio! Non c'è ragione perché non sia possibile riparare il computer, a meno che il numero di piste interrotte non sia davvero abnorme. Se non sono le piste, ci sarà un integrato che non hai ancora testato che non funziona. Oppure uno o più condensatori elettrolitici che si sono seccati (si vede con un oscilloscopio che l'alimentazione non è "pulita").
Potrebbe esserci un'altra pista interrotta, sotto ad un integrato per esempio. Controlla le alimentazioni di tutti gli integrati e se hai una sonda logica o un oscilloscopio, vedi se trovi cose strane come problemi un altra linea del bus. Se hai trovato problemi sul bus dati potrebbero essercene altri.

Tra l'altro, avrei una domanda: per la diagnostica, ho visto in passato cose del genere:

http://blog.tynemouthsoftware.co.uk/201 ... ridge.html

Ma non le ho mai usate di persona, magari qualcuno qui del forum ha esperienza diretta e può consigliare/sconsigliare quest'approccio o mi può per favore indirizzare verso una discussione qui in cui se ne parla?

Io ce l'ho e lo uso regolarmente per testare periodicamente i miei Vic. Mi è servito in passato per identificare alcuni problemi. Unici downside sono che funziona solo con computer PAL e apparentemente non risolve alcuni problemi minori. Due esempi per chiarire questo secondo aspetto. Ho un Vic che ogni tanto "stona" qualche nota, non ho ancora capito perché. Un altro invece carica correttamente tutto da disco o da sd2iec e non ha problemi di sorta, ma misteriosamente non funziona se inserisco la mega-cart. Su entrambi, l'accrocchio di Tynemouth non segnala alcun errore.

Infine, non credo che funzioni con macchine a schermo nero, bypassando la sezione video; però non ho mai provato.

Tutto sommato, è un acquisto che consiglierei.

orion70 wrote: ↑Wed Sep 30, 2020 5:30 am Un altro invece carica correttamente tutto da disco o da sd2iec e non ha problemi di sorta, ma misteriosamente non funziona se inserisco la mega-cart.

Tra le varie ricerche fatte per il mio, sono incappato nella discussione di un problema che potrebbe somigliare al tuo, ma riguardava la PENULTIMATE CARTRIDGE... Il responsabile era il 74LS138
http://blog.tynemouthsoftware.co.uk/201 ... jbfiUqpjMQ

Per il diagnostic sono quasi sicuro che non funziona con macchine a schermo nero

Io per riparare il VIC20 di Orion70 ho inizialmente usato una scheda RAM_ROM che ho appositamente realizzato per contenere (anche) il diagnostico, oltre ad aver realizzato in maniera "casareccia" i cavi di interconnessione....
Esistono due versioni del SW, uno per PAL e uno per NTSC,
ma se ho ben capito le differenze consistono solo nella corretta centratura dello schermo.
Purtroppo in quell'occasione non mi aiutò a trovare il guasto, ma ora ho delle schede modificabili....
La scheda è facilmente personalizzabile, ad es. la ROM può comparire in una area I/O con le routine simil-jiffydos SJLOAD mentre la Ram può espandere l'area basic e/o riempire il BLK5 per caricare (rapidamente ....) un'immagine di cartuccia..

Grazie! Era quello che pensavo per lo schermo nero.

Tornando IT, l'oscillatore parte? La CPU riceve il clock?

Per riparare quel VIC20 di cui parlavo è stato essenziale monitorare il segnale "SYNC" del 6502 (PIN7) che si attiva solo nei cicli in cui la CPU sta leggendo un OP-CODE, con un oscilloscopio a memoria ne ho contati quanti venivano eseguiti dal reset al blocco della macchina e quindi ho capito, seguendo la routin di RESET del Kernal, dove si piantava e quindi perchè.
Il caso che ho raccontato è comunque quello di una macchina in cui la CPU partiva e si bloccava prima di accendere il VIC20,
si bloccava dopo pochi cicli dalla fine della routin che, all'inizio della procedura di RESET, legge la presenza della cartuccia esterna,
mi sono quindi focalizzato sull'istruzione di RTS (ritorno da subroutine) con cui questa procedura si chiude, questa istruziona ripesca l'indirizzo a cui saltare dallo STACK che è un'area di memoria fisicamente posta fuori dal processore nella RAM esterna in pagina1, ovvio che se la ram genera errori proprio in quella porzione allora l'indirizzo di salto è corrotto e la CPU si chiude in un fondo di bottiglia....

Cambiati i due chip di RAM relativi al KByte più basso (rotto ne era solo uno) il VIC20 è rinato

Sì, in questo caso per il mio piccolo NTSC in coma è servito davvero l'intervento di un esperto

MCes wrote: ↑Wed Sep 30, 2020 11:54 am Per riparare quel VIC20 di cui parlavo è stato essenziale monitorare il segnale "SYNC" del 6502 (PIN7) che si attiva solo nei cicli in cui la CPU sta leggendo un OP-CODE, con un oscilloscopio a memoria ne ho contati quanti venivano eseguiti dal reset al blocco della macchina e quindi ho capito, seguendo la routin di RESET del Kernal, dove si piantava e quindi perchè.

Molto interessante. E' il genere di riparazioni che piace a me, complimenti!

Grazie per i complimenti, spero di essermeli meritati.

Comunque il VIC20 è una macchina che idealmente possiamo tagliare in due cercando di rendere più agevole la ricerca guasti,
il punto di congiunzione tra le due metà sobno i buffer (isolatori) del bus 74LS245.
Da un lato abbiamo la CPU con le ROM, dall'altro abbiamo il VIC con le RAM.
Ovviamente prima si controlla se la CPU è messa nelle condizioni di funzionare; Vcc=5V, RST=H, NMI=H, IRQ=H, Fase0= presente,.....
ma poi, per quanto detto prima sul poter dividere in due il VIC20 ho fatto una prova mettendo un nuovo kernal dove l'unica attività che fa la CPU all'accensione è ciclare all'infinito in un loop, questo semplice programma non implica l'uso delle ram o delle periferiche e quindi viene eseguito senza implicare la seconda metà del VIC20, lla sua corretta esecuzione può dare già molte informazioni, come ad esempio la corretta decodifica degli indirizzi ROM, il non cortocircuito delle linee del bus della CPU, ecc...
La corretta esecuzione del programma può essere monitorata (anche con un tester!) sul pin SYNC e sui pin dell'address della CPU che devono essere stabili tranne i due o tre di ordine più basso.
Sarebbe il caso anche di ripetere la procedura con un kernal che fa lo stesso ciclo infinito ma in una diversa zona dell'area in modo da cambiare stato anche ai bit più alti del bus address verificandone quindi il corretto pilotaggio.
Ovvio che se non funziona si indaga nella metà dominata dalla CPU, ad iniziare dai buffer LS245 che spesso si rovinano.

MCes wrote: ↑Wed Sep 30, 2020 11:54 am Per riparare quel VIC20 di cui parlavo è stato essenziale monitorare il segnale "SYNC" del 6502 (PIN7) che si attiva solo nei cicli in cui la CPU sta leggendo un OP-CODE, con un oscilloscopio a memoria ne ho contati quanti venivano eseguiti dal reset al blocco della macchina e quindi ho capito, seguendo la routin di RESET del Kernal, dove si piantava e quindi perchè.
Il caso che ho raccontato è comunque quello di una macchina in cui la CPU partiva e si bloccava prima di accendere il VIC20,
si bloccava dopo pochi cicli dalla fine della routin che, all'inizio della procedura di RESET, legge la presenza della cartuccia esterna,
mi sono quindi focalizzato sull'istruzione di RTS (ritorno da subroutine) con cui questa procedura si chiude, questa istruziona ripesca l'indirizzo a cui saltare dallo STACK che è un'area di memoria fisicamente posta fuori dal processore nella RAM esterna in pagina1, ovvio che se la ram genera errori proprio in quella porzione allora l'indirizzo di salto è corrotto e la CPU si chiude in un fondo di bottiglia....

Cambiati i due chip di RAM relativi al KByte più basso (rotto ne era solo uno) il VIC20 è rinato

Ecco cosa intendevo con professionale... Hai tutto il mio rispetto e ammirazione.

Oggi sostituzione condensatori elettrolitici.
Controllo di connessioni varie.
Non ho segnale di UD1 pin 1,4,10. E corrispondenti su UE1e 6561. Le piste sono ok. Il 6561 so che è ok. Chi sostituisco? UD1 o UE1? O entrambi? O sono fuori strada...

Per una riparazione o provi "a naso" (ovvero statisticamente) cosa potrebbe essere rotto, oppure fai diagnosi basate sulle misure, e le misure stesse basandosi su delle ipotesi.... è come leggere un romanzo giallo: non sai chi è l'assassino eppure ci sono innumerevoli piste che ti portano anche lontano dalla soluzione!

UD1 serve a gestire il knibble della memoria colore, se hai forti dubbi puoi anche dissaldarlo che il VIC20 funzionerebbe ugualmente (se funzionasse...) ma non avresti i colori giusti nel testo.

Hai la possibilità di autoprodurti una rom per sostituire il kernal? posso fornirti il file .BIN per il kernal che cicla senza andare ad accedere nelle ram, e visto che i tuoi buffer '245 sono tutti e tre zoccolati puoi sfilarli ed isolare le due metà del VIC 20 (vedi post precedenti) e monitorare con l'oscilloscopio l'attività (o meno) del bus così ridotto ai minimi termini....