Dopo qualche tempo dalla prima riparazione mi trovai a dover affrontare un nuovo problema, non sul mio MSX originale ma su un secondo MSX (stessa marca e modello) che avevo acquistato tempo prima in attesa di riparare quello originale.

Mentre stavo giocando con, credo Antarctic Adventure, improvvisamente, e senza alcun preavviso, l’immagine è diventata completamente nera; oltre all’immagine era svanito anche l’audio ma inizialmente non ci diedi molto peso. Pensai di aver incontrato un bug nel gioco, riavviai, per qualche istante funzionò e poi tutto di nuovo nero, stavolta in modo permanente. Da quel momento, infatti, non si è più riavviato neanche per un istante.

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 intuire 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 (come nel caso della riparazione di cui ho già scritto in precedenza), 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. Tutti i livelli di tensione erano apposto.

Ok, mi sono detto, cominciano i cazzi.

La seconda cosa che ho verificato è stato il clock. Il clock era apposto. 3.5MHz, come ci si aspetterebbe per uno Z80 dell’epoca. Visto che c’ero ho anche provato a sostituire lo Z80 dell’MSX con uno che avevo da parte e, dato 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 ok. Sia la ROM del firmware che le due ROM del BASIC erano perfette (su alcuni modelli le ROM sono solo due, solo più grandi, il software che contengono “sommate assieme” è identico).

Ok, pensai, cominciano i cazzi veri… vediamo il circuito video. 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 (marcato CX7925A) controllato dal software (all’avvio l’MSX invia al PLL un numeretto che indica 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 video né di PLL, ma se la CPU non gli mandava nulla era piuttosto ovvio che il PLL non funzionasse correttamente e non era certo colpa sua.

Prima di complicarmi ulteriormente la vita, ho pensato, proviamo a risolvere il problema potenzialmente più probabile… il computer ha 30 anni… gli elettrolitici saranno asciutti o comunque morenti… sostituiamoli… tutti… che tanto male non fa 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é… penso… 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 micro-controllore 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 preferivo evitare di dissaldare così tanti circuiti integrati per un risultato dubbio.

Ok pensai, 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… (o seguirlo passo passo con un emulatore)

Va bene, non fasciamoci la testa prima di essercela rotta, dissi fra me e me… cerchiamo di risalire al circuito che genera il CAS. A questo punto mi stampo il circuito su vari fogli e faccio un collage per semplificarmi la vita (P.S. voglio un sacco di bene a chi ha scansionato il service manual del mio modello, però se non risparmiava sulla scala di grigi e aumentava un po’ la definizione non avrebbe certo fatto male).

La gestione della RAM sugli MSX era piuttosto complessa (ma ingegnosa). Le CPU Z80 possono indirizzare un massimo di 64KByte di memoria (fra RAM e ROM), ma nell’MSX, attraverso trucchetti hardware (suddivisione in pagine, banchi e sotto-banchi attraverso chip esterni al microprocessore) si possono montare in totale fino a 1MByte di memoria massima teorica indirizzabile (RAM e ROM). In particolare lo spazio di indirizzamento dello Z80 (64KByte) è divisa in 4 pagine da 16KByte, ogni pagina poteva fare riferimento ad uno dei 4 banchi (anche detti slot primari) ed ogni banco poteva essere suddiviso a sua volta in 4 sotto-banchi (slot secondari). Ogni pagina può quindi andare a pescare i dati sia dalla ROM, che dalla RAM, che dalle cartucce collegate al computer (generalmente gli slot primari capaci di ospitare delle cartucce sono 2 anche se lo standard MSX, se ben ricordo, ne richiede solo 1). Mentre guardo lo schema mi auguro subito di non dovermi addentrare troppo in questo incubo…

Comincio col 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 negata). 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)

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 (negato, ripeto, i segnali sono in logica negata)… 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 livello logico alto e che quindi la CPU non voglia mai scrivere nulla sul BUS? Controllo il corrispettivo segnale all’uscita della CPU e quello cambia… chiaramente c’è qualcosa che blocca il segnale da qualche parte. Guardo lo schema e identifico tutti i chip che attraversa (sostanzialmente un buffer e poco altro)… non mi restava che provare con l’oscilloscopio.

Prendo l’oscilloscopio e verifico il segnale WR in uscita della CPU… 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?
A questo punto sono già un po’ rincuorato… ho trovato un possibile problema che potrebbe spiegare la mancanza di segnali di vita del computer quindi forse mi sono avvicinato alla soluzione.

Scollego l’alimentazione, prendo il multimetro e provo la continuità… in effetti non c’è continuità sulla traccia. Forse non è l’unico problema ma è sicuramente parte del malfunzionamento… 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 si avvia.

Do tensione, accendo… e l’MSX si avvia mostrandomi la schermata di benvenuto con il menu iniziale :)

Ricontrollo i segnali di CAS e RAS con l’oscilloscopio e ora ci sono entrambe (prima, come dicevo, solo il segnale di RAS presentava segni di vita). Nella foto qui accanto è possibile vedere entrambe i segnali mentre l’MSX sta visualizzando il suo menù principale. Per visualizzare questi due segnali basta posizionare i due terminali dell’oscilloscopio sui piedini 4 (RAS) e 15 (CAS) di uno dei chip di DRAM 3764 da 64Kbit ciascuno.

A livello puramente indicativo, all’avvio dell’MSX, se non ricordo male prima di visualizzare delle immagini sullo schermo, i due segnali risultano essere più ripetitivi e dunque più “puliti” sull’oscilloscopio.

Non ho una teoria convincente per spiegare questo fenomeno, la mia ipotesi, anche in base a ciò che ho letto sul service manual e il technical manual, all’avvio l’MSX fa un test della RAM per identificare, su tutti i banchi e sotto-banchi disponibili, la (prima) sezione di RAM libera più grossa da dedicare al MSX-BASIC (fino ad un massimo di 32KByte)… cosa che potrebbe spiegare i segnali ripetitivi (per via delle letture sequenziale con tempistiche predefinite e ripetute). Se qualcuno ha un’idea migliore la scriva pure nei commenti.

A questo punto il problema era stato individuato e risolto, ma non mi piaceva quel ponticello temporaneo che avevo realizzato. Perciò ho tolto il ponte, grattato con una carta vetrata molto fine le piste annerite in modo da esporre il problema, e così facendo ho scoperto che mancava un’intero pezzo di traccia (mi aspettavo qualcosa di molto meno evidente).

Preso un pezzetto di conduttore l’ho saldato nella parte mancante e poi ho ricoperto 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).

Fatto questo l’unica cosa che restava da fare era rimontare tutto quanto e testare l’MSX. Dopo aver rimontato tutto facendo attenzione a non dimenticare nulla faccio varie verifiche, sia avviando ed utilizzando l’MSX-BASIC che provando varie cartucce di giochi per MSX che ho acquistato nel tempo su eBay.

Un’ultima nota.
Alcune delle foto, soprattutto quelle con i segnali RAS e CAS rilevati dall’oscilloscopio, sono state scattate su un altro MSX (identico, stessa marca e modello di quello riparato) a mia disposizione in un secondo tempo. Questo perché, quando ho effettuato la riparazione, non avevo scattato quelle foto ma ho ritenuto fossero abbastanza interessanti da includerle comunque se non altro come riferimento nel caso qualcun altro si trovi a dover riparare questo modello e si chieda come quei due segnali dovrebbero essere fatti su un modello funzionante.

Nelle immagini che seguono è possibile vedere l’MSX in riparato alle prese con vari giochi e, come vedete, funziona tutto perfettamente.