Forum libero

Dunque più o meno è andata così...

Sintomo:
Mentre stavo usando l'MSX il display è diventato nero per nessuna ragione apparente. L'ho riavviato, è ripartito, ma poco dopo di nuovo nero... e da quel momento non è più ripartito, lo schermo restava nero.

Riparazione:
Capire cosa poteva essere andato storto non era semplice. Quando si ha a che fare con un computer le cose che possono andare storte sono tante e non è sempre semplice capire cos'è che non va perché quello che sta facendo internamente un computer dipende molto da quello che in quel momento vuole fare il software. L'MSX ha oramai 30 anni perciò non si può escludere quasi nulla.

Le mie ipotesi iniziali erano più o meno queste: alimentatore rotto (la mia prima riparazione era dovuta a questo, ma per colpa mia, spiegherò dopo o in un altro post), qualche condensatore (soprattutto elettrolitico) andato, generatore del clock per qualche ragione bloccato, RAM bruciata, CPU andata, qualcosa che si è fottuto nel circuito video.

Come prima cosa ho controllato l'alimentatore, non fosse altro che per il fatto che è una delle parti più semplice ed indipendente dal software che potevo testare. La verifica delle tensioni in uscita ha subito escluso che si trattasse dell'alimentatore. Ok, mi sono detto, cominciano i cazzi.

La seconda cosa che ho testato è stato il clock. Il clock era apposto. 4MHz, come ci si aspetterebbe per uno Z80. Visto che c'ero ho anche provato a sostituire lo Z80 con uno che avevo da parte visto che non era saldato è stato semplice rimuoverlo e sostituirlo... ma nulla da fare... quindi in teoria sia clock che CPU erano apposto.

A quel punto estraggo e testo le ROM, me le leggo e le confronto con le ROM che trovo online... tutto OK, le ROM sono apposto. Sia il firmware che le due ROM del BASIC sono perfette.

Ok, cominciano i cazzi veri... vediamo il circuito video. Boh... dai test-point segnati nel service manual sembrava tutto ok, salvo il fatto che mancava completamente la componente del colore e della luminosità... ma d'altra parte se la logica del computer non gli mandava immagini era abbastanza naturale che non ci fossero... e infatti il monitor mostrava nero.
A complicare le cose nel circuito video c'è un chip PLL controllato dal software (all'avvio l'MSX invia al PLL un numeretto che indica al PLL di quanto dividere o moltiplicare la frequenza in input, se quel numeretto non gli arriva, ovviamente il PLL non sa che fare), non so di preciso qual'è il suo scopo, dato che non me ne intendo di roba video, ma se la CPU non gli mandava nulla era piuttosto ovvio che il PLL non funzionasse correttamente.

Prima di complicarmi ulteriormente la vita, ho pensato, proviamo a risolvere il problema potenziale più probabile... il computer ha 30 anni... gli elettrolitici saranno asciutti o comunque morenti... sostituiamoli... tutti... e speriamo di averci azzeccato.
Cambio tutti gli elettrolitici con componenti nuovi... un'operazione rognosa e relativamente pericolosa (saldare e dissaldare può rovinare le tracce del PCB) ma certamente più semplice che mettersi a smontare i chip soprattutto considerando il fatto che su questi vecchi PCB i pad erano piuttosto stretti e dissaldare un circuito integrato da un PCB del genere può essere un incubo nonostante abbia tutta la strumentazione necessaria... cmq dopo averci passato un paio d'ore e aver sostituito tutti gli elettrolitici riprovo la scheda... ma nulla da fare, schermo nero. Bé... per lo meno non è peggiorato...

Ok, sono nei guai, a questo punto non mi resta che testare la parte logica... cosa più facile a dirsi che a farsi in qualcosa che cambia comportamento in base a quello che sta pensando il software. Se la RAM è bruciata forse la CPU entra in ciclo da qualche parte... ma come faccio a sapere qual'è il chip bruciato? Come faccio a testare la RAM se non posso neanche creare ed eseguire un programmino di test? Mi vengono in mente diverse soluzioni, ma tutte richiedono uno sbattimento non indifferente, tipo creare una schedina in hardware da connettere nello slot con un suo microcontrollore che possa interagire con la RAM della scheda madre, oppure smontare tutti gli 8 chip di RAM e testarli uno ad uno con una schedina creata di proposito... la probabilità che la RAM sia fallata a questo punto è altina... forse sto di meno a sostituire i chip con altri chip di RAM che ho messo da parte per queste occasioni... ma se possibile preferisco evitare di dissaldare così tanti chip per un risultato dubbio.

Ok, niente, proviamo con l'oscilloscopio intanto se arrivano i segnali alle RAM... magari capisco cosa c'è che non va così... speriamo...

Controllo quindi gli indirizzi, che sembrano funzionare, i dati di input... boh... tutto ok... poi mi concentro sulle linee di controllo della RAM... provo il segnale RAS (row address strobe) che identifica le righe dentro la RAM... il segnale c'è e sembra corretto, dato che la CPU genera un rinfresco 1 volta ogni 4 colpi di clock dovrebbe fare un RAS con circa una frequenza di 1MHz... e infatti c'è... ok, vediamo il CAS (column address strobe)... il CAS controlla le colonne della RAM... nulla. Segnale assente. Provo sugli altri chip di RAM, stessa cosa. Possibile? Se non c'è il CAS significa una cosa sola... che la CPU non legge né scrive nulla nella RAM. E che cazzo, come può essere che la CPU si limiti a fare un rinfresco senza mai usare la RAM? Vuoi che la CPU si blocchi da qualche parte leggendo la ROM? Ma le ROM sono apposto... le ho controllate... forse cerca di accedere a qualche dispositivo di I/O e lì si blocca per qualche motivo? Quando c'è il software di mezzo è un bell'incubo capire cosa sta succedendo, soprattutto se per capire cosa fa il software devi disassemblare il firmware...

Va bene dai, non fasciamoci la testa prima di essercela rotta... cerchiamo di risalire al circuito che genera il CAS. A questo punto mi stampo il circuito su vari fogli e faccio un collage:



La gestione della RAM sugli MSX era piuttosto complessa. Le CPU Z80 possono accedere ad un massimo di 64KByte di RAM, ma nell'MSX, attraverso trucchetti hardware (suddivisione a banchi e a pagine controllate da chip esterni) si possono montare in totale fino a 1MByte di RAM. In particolare lo spazio di indirizzamento del Z80 (64K) viene divisa in 4 banchi, che a loro volta possono essere suddivisi in 4 pagine... Ogni pagina e ogni banco può, indipendentemente, andare a pescare i dati sia dalla ROM, che dalla RAM, che dagli slot collegati al computer (generalmente 2 anche se mi pare che lo standard MSX ne richiede solo 1). Spero tanto di non dovermi addentrare in questo incubo...

Comincio a risalire nello schema alla parte del circuito che genera il CAS. Testo ogni chip che incontro con l'oscilloscopio per individuare un eventuale chip (quasi tutti TTL della serie 74) con comportamenti bizzarri... finché non mi trovo davanti ad una AND (chip 30) con input negati (perché i segnali sono a logica inversa). Questa AND prende in input diversi segnali e ha lo scopo, all'avvio dell'MSX, di inviare almeno un segnale ad un Flip Flop D (chip 21) che è una sorta di "enable", fra gli altri, anche per il CAS. (In realtà qui l'ho fatta più semplice di quello che è... ci sono vari chip di mezzo che ho dovuto controllare prima di arrivare al chip 21 e di conseguenza al 30)



Ok, forse sono quasi arrivato ad una soluzione del mistero.
Il mio primo sospetto è che il chip 30 non funzioni... ma non c'è da stupirsi che il suo output non cambi mai... visti gli input. Tutti i segnali che arrivano all'IC30 cambiano, tranne il WR... il WR è un segnale generato dalla CPU il cui scopo è quello di dire "sto scrivendo dei dati sul bus, il destinatario per favore li legga"... come è possibile quindi che rimanga fisso a 1 e che quindi la CPU non voglia mai scrivere nulla sul BUS? testo il segnale all'uscita della CPU e quello cambia... chiaramente c'è qualcosa che blocca il segnale. Risalgo lo schema e identifico tutti i chip che attraversa (sostanzialmente un buffer e poco altro)... non mi resta che provare con l'oscilloscopio.

Prendo l'oscilloscopio e testo il segnale WR in uscita della CPU... e quello cambia... dopo il buffer... cambia ancora... bene... poi arrivo ad una AND... e lì il segnale non arriva... non c'è nulla fra il buffer e quella AND... solo una traccia sul PCB. Do un'occhiata alla traccia e identifico una sezione annerita. Vuoi vedere che è corrosa?

Prendo il multimetro e provo al continuità... in effetti non c'è continuità sulla traccia. Forse non è l'unico problema ma è sicuramente parte del problema... quella stronza di traccia... dopo essermi dato dello stupido per 5 minuti buoni per non aver controllato le tracce annerite (sono più d'una) procedo con una fix "al volo" giusto per vedere se ripristinando la continuità il computer parte.


(In rosso la riparazione al volo, in blu la RAM con i due terminali [giallo e verde] dell'oscilloscopio sul RAS e CAS di uno dei chip di RAM)

Accendo... e l'MSX si avvia e mi mostra la schermata di benvenuto con il menu iniziale


Riprovo i segnali di CAS e RAS con l'oscilloscopio e ora ci sono entrambe (prima solo il segnale di RAS presentava segni di vita).

(CAS sopra, RAS sotto)

Ecco un bel "fermo immagine" (anche qui CAS sopra e RAS sotto):


Dettaglio dei terminali sul piedino di CAS e RAS


Ok, problema identificato. Ora vediamo di ripararlo un po' meglio.
Tolgo la fix temporanea e prendo la carta di vetro fine. Comincio a grattare gentilmente la pista annerita (e quella vicina, nera anch'essa ma senza problemi di continuità) ed ecco il risultato:

(in rosso la sezione corrosa dopo aver rimosso la pista annerita che la nascondeva)



Riparo la parte mancante della pista saldandoci sopra un conduttore


e poi ricopro tutto con una lacca trasparente per circuiti stampati il cui scopo è quello di tenere le tracce isolate dall'umidità (una volta solidificata, questione di pochi secondi, diventa un sottile strato di plastica trasparente). Qui si può vedere in controluce la lacca ancora liquida che luccica.


Rimonto la scheda al suo posto


E ora provo il tutto

Antarctic Adventure



Penguin Adventure


Arkanoid



L'MSX BASIC


Tutto ok, MSX riparato


Ora devo riparare un altro MSX, stesso sintomo... ma il problema potrebbe essere molto diverso... vedremo.