Dove riparare un VIC in Italia

[Niel]

Ricevuto!
Niente fonte esterna, a meno che di non dissaldare il regolatore. E per ora non dovrei sospettare della 5V con un regolatore nuovo e una lettura col voltmetro che sembra stabile (farò una doppia verifica di oscilloscopio al limite).
Stasera non posso fare verifiche, ne parliamo domani mattina.

Comunque mi sto divertendo un sacco a smanettarci, e se alla fine non si arriva in fondo, non è un problema. Sto di sicuro imparando molto su questa affascinante "macchinetta".

[Niel]

Allora:
Tensione 5V stabile.
RST, IRQ, NMI a regime vanno alte.
Aggiungo Clock in e out stabili 1,1 MHz
Il Sync pin 7 parte stabile per un istante dopo che il reset va alto, poi nulla (come senza Eprom inserita).
Mentre il /CS (/OE) sulla Eprom (pin 22), dopo reset alto parte stabile e ci rimane.

[Niel]

Non so se quanto aggiungo credo ancora più confusione, ma ho fatto anche questa prova.
La prova sopra era con nuova CPU UMC.
Con questa UMC un altra scheda (rev D, ma cambia poco dalla rev C) funziona regolarmente. Ho anche eseguito i test con la scheda apposita.
Su questa altra scheda il vecchio MOS 6502 da schermo nero.
Ho rimontato il vecchio MOS 6502 su questa scheda, e questo sembra eseguire qualcosa, ma non il ciclo giusto. Il SYNC ha attività, ma irregolare.
Link al video https://youtu.be/n311JsFmavc

[MCes]

Allora,
per non impazzire bisogna mettere dei punti fermi, ad es. se un 6502 non funziona su una scheda buona allora il 6502 è quasi sicuramente rotto e quindi va tolto di mezzo (lo butterai a riparazione ultimata, non si sa mai...).

Il filmato credo mostri il sync ed il clock della cpu (CPU rotta, se ho ben capito le tue prove), intanto dichiara quale clock:
pin 35 del VIC6561 (FB10) [P01]
pin 37 della cpu [f0in]
pin 3 della cpu [f1out]
pin 39 della cpu [f2out]
pin 4 UC2 (FB1) [S02]

Comunque se il loop gira bene normalmente dovrebbe rappresentare stabilmente 1 sync ogni 3 colpi di clock, ed ovviamente questo non è il tuo caso....

Da ora in poi dò per scontato che il 6502 rotto è fuori scena e quindi quando scriveremo "6502" o "la CPU" ci riferiremo, salvo specificarlo diversamente, ad una cpu testata funzionante (la UMC, ad es.).
Darò anche per scontato che sulla scheda madre, fino a che il loop non verrà correttamente eseguito, rimangano sfilati i 3x74LS245, la ROM del Basic, i due MOS6522. Nessuna cartuccia collegata.

Per verifica prendi la scheda funzionante, mettici su il 6502 UMC e il kernal farlocco (senza sfilare altri integrati che la scheda, per assunto, funziona e quindi non danno problemi....) ed osserva, su questa macchina funzionante, quanti cicli di CLOCK avvengono tra due fronti di salita del SYNC, cosi mettiamo dei punti fermi.

Rimetti kernal di prova e cpu sulla scheda rotta, e ripeti la misura del filmato così vediamo come una CPU buona reagisce alla scheda rotta.

Poi verifica anche:
Con il kernal "finto" metti l'oscilloscopio 2 tracce su SYNC e su /CS della rom del kernal, sincronizza su SYNC: ad ogni sync DEVE corrispondere un'abilitazione del kernal (sync= la CPU carica un'istruzione, dal kernal appunto) mentre a volte la ROM viene abilitata anche senza sync (lettura di parametri del codice operativo).


Se troverai errori nel /CS della ROM indaga verso UC5 che decodifica gli indirizzi associati, ovvero /BLK7 (il nostro /CS del Kernal).

Facci sapere!

[Niel]

Allora:
1) test su board funzionante con kernal modificata, come da foto. Il loop funziona e il rapporto frequenza è 1 a 3 come avevi indicato.
2) su board non-funzionante installati 6502 e 6561 usati precedentemente, come da foto, il loop non gira e solo /CS mantiene frequenza, il Sync si ferma subito, come da video https://youtu.be/lWAj0JE0nn0
3) le frequenze di clock su tutti i pin da te indicati sono stabili e con valori analoghi sia nel caso 1 che 2.

Visto così non vedrei problemi su /CS
Che ne dici?

[MCes]

Ok,
se tutto va bene siamo ad un punto dove bisogna decidere quale tipo di strategia usare per continuare.

Intanto focalizziamo un risultato:
Il fatto che il /CS riproduca grossomodo il CLOCK significa che ad ogni ciclo utile la ROM viene selezionata come dovrebbe essere, e quindi in queste condizioni la decodifica del BLK7 di indirizzo del kernal pare non generare problemi.

Quindi:
la CPU mette l'indirizzo sul BUS, la ROM viene correttamente selezionata, la ROM restituisce il suo contenuto sul bus DATI e la CPU li acquisisce.
Nella frase appena enunciata è nascosta la défaillance della scheda guasta (altrimenti il loop funzionerebbe, no?), e assodato come funzionante la decodifica, il kernal farlocco e la CPU (che funzionano sull'altra scheda) quello che rimane pare essere il circuito stampato....... (compresi zoccoli, saldature, tranciature fatte con i cacciaviti per sfilare chip dai zoccoli, erosione di ossidi nei depositi conduttivi dei fori passanti, rifusi di saldature tra pin tra zoccolo e PCB, ecc...).

Come ti dicevo, a meno di sorprese, ora l'attività che ti consiglierei è la ricerca della/e piste incriminate che può essere appunto eseguita usando strategie e tattiche diverse.
Il metodo più interessante sarebbe quello di "congelare" la macchina ad ogni ciclo di clock per andare a testare anche con un semplice tester (ovvio che l'oscilloscopio è meglio...) le linee logiche di address e data.
Come fermare l'attività, ciclo per ciclo, di un 6502?
Ad esempio così: http://mcukits.com/tag/apple-ii-address ... ep-6502-e/
Sul Vic20 è necessario isolare il pin "ready" che è unito al pin SetOverflow e posto a valore alto attraverso resistore di pull-up, la costruzione del circuitino sarebbe un'attività MOOOOOOLTO didattica ed illuminante, oltre che molto deterministica per la ricerca del guasto....
Altre strategia, diametralmente opposta praticamente triviale, è sfilare CPU e Kernal e testare la continuità delle piste che li uniscono (CD0...CD7, CA0....CA12) mettendo i puntali dell'Ohmmetrro (faccia superiore della board) uno sulla molla dello zoccolo sede del pin della CPU, l'altro sulla molla dello zoccolo sede del relativo pin della ROM.
Ripetere per ogni linea, se sei fortunato trovi una pista aperta, altrimenti devi ipotizzare che ci sia un corto tra tracce, e la cosa diventa più aleatoria, ovvero più difficile da scovare.

[Niel]

Grazie.
La verifica della continuità delle piste indirizzi e dati tra ROM e ROM l'avevo già fatta col tester, come indicavi, e tutte avevano continuità.
Chiaramente non ho testato eventuali combinazioni di corto tra tracce, solo qualche caso di pin adiacenti.
Il circuito per il single step è allettante, e lo trovo qualcosa di utile da avere, quindi penso che mi diletterò a prepararlo.
Sembra semplice, ma lo studio un attimo poi nel caso chiedo.

[MCes]

Il circuito proposto nel link serve a fermare l'attività della cpu senza fermare il clock, questo perchè il 6502 è in tecnologia N-MOS ed i suoi registri interni sono realizzati in modalità dinamica (come le memorie dinamiche che abbisognano di refresh).
Diverso sarebbe se tu potessi recuperare una versione (non fake) del 6502 in tecnologia C-MOS, ovvero un 65C02, questo accetterebbe il fermo del clock e quindi basterebbe togliere il VIC dalla board e pilotare il clock con un deviatore a pulsante ed un piccolissimo circuito antirimbalzo


Nel caso vuoi realizzare il circuito per fermare un comune 6502 ti consiglio di usare un 74HCT74 e di portare il resistore di pull down da 270 Ohm a 2,2k (valore non critico)

Nota: non verifica tra ROM e ROM ma tra pin zoccolo kernal e pin zoccolo cpu, ma credo che questo l'avevi già chiaro

[Niel]

Grazie. Ho ordinato i 74HCT74.
Per fare i collegamenti al 6502 verso RDY e SYNC come è meglio regolarsi?
Non ho questi pins esposti sulla porta di espansione.
Preparo uno zoccolo ad-hoc o uso direttamente la sonda a molla sui pin della cpu?

[MCes]

Per usare il circuito "step by step" dovrai isolare il pin2 della CPU, quindi ti consiglio di sfilare la cpu, sullo zoccolo della scheda madre metti un frammento di carta adesiva a coprire solo il contatto del pin2, poi prendi uno zoccolo nuovo da 40 pin e fletti verso fuori il piedino del pin2, ora metti lo zoccolo nuovo sopra lo zoccolo della scheda madre ed avrai disponibile, isolato dal resto del mondo, il pin2 (READY) della CPU.
Se lo dovrai lasciare libero ricordati di mettere un resistore di pull-up verso Vcc

[Niel]

Sono un po' fermo.
Ho preparato il mio circuito di single step come da schema di Wozniak, di cui allego schema collegamenti.
Se lo testo senza senza la CPU l'uscita 1Q è Low, come mi aspetterei. Quindi suppongo che la base sia corretta.
Poi installo la CPU e mi ritrovo RDY sempre alto, pur essendo il piedino 2 scollegato dalla board, e collegato all'uscita 1Q.
Ho verificato più volte che non fosse collegato con la board, è ho proprio tagliato la pista di collegamento sul mio circuito.
Non capisco... RDY rimane alto di suo già sulla CPU

[Niel]

Ho lasciato per un momento il circuito di single step, anche perchè sono in attesa di un 6502 CMOS che di sicuro aiuterà, e mi sono dedicato a fare delle letture dell'address e data alla partenza.
All'accensione l'address resta per un po' su $FFFF e Data legge $57(che se non sbaglio corrisponde al NOP), poi quando il SYNC smette l'attività l'address leggo address $7FF5 che è lontano da $EAAA del loop.

[Niel]

LIETO FINE
è stata dura ma alla fine ne sono venuto a capo.
Ormai avevo perso le speranze perché le avevo provate tutte, e i risultati all'oscilloscopio del test con la kernal modificata era spesso inconcludenti.
Ho praticamente passato l'ultimo periodo a testare tutte le piste indirizzi/dati/clock, interrupt e tutto ciò che parte arriva a Kernal, 6502 e VIC, ma continuavo a non fare passi avanti.
Poi oggi l'illuminazione.
Mi sono messo a testare tutti i 6502 usati fin'oggi nei test, con un altra board che so funzionare, e a parte il 6502 originale della board fallata, che effettivamente non va, gli altri funzionavano... l'UMC 6502 e il Rockwell 65C02.
Ma ancora non mi tornava che quando testavo il loop sulla board fallata:
Con l'UMC si fermava dopo il reset ancora prima della prima istruzione
Con il 65C02 cominciava il ciclo e sembrava resettarsi in continuo
Quindi prendo il CBM 6502 della board buona, lo monto sulla board fallata e magicamente funziona.
Tolgo il kernal modificato, metto il kernal originale, inserisco i 245, accendo e... Allego il risultato.
Quindi abbiamo imparato che sulla Rev C ci sono incompatibilità con i processori... Informazione che non ho trovato documentata da nessuna parte.
Adesso mi prendo una pausa, ma il prossimo step sarà capire in cosa differisce questa board dalla Rev. D

[nbla000]

Ragazzi, non sapete quanto vi invidio

La prima volta che ho iniziato a "sporcarmi le mani con l'hardware" è stata con l'Amiga 500 mi sembra giusto per aggiungere l'espansione di memoria o qualcosa di simile, prima di allora (Vic-20 / C64) non osavo aprire questi gioiellini per paura che non facessi danno, poi un po' mi sono "sciolto" ma diciamo che mi limito alle cose semplici, quello che leggo da questo thread ad esempio non rientra per me nel novero delle cose semplici.

Se non erro in soffitta dovrei avere sia una board di un Vic-20 PAL che non ricordo funzionante che un drive 1581 sicuramente non funzionante, se non erro proprio per il 1581 avevo scaricato delle istruzioni che diedi ad un tecnico della mia zona (aggiustava ai tempi anche i Vic-20) ma che si rifiutò di metterci mano probabilmente per non perderci tempo...

Ecco tornando al titolo del Thread, credete ci sia qualcuno che faccia ancora questo genere di cose magari a costi umani ?

[Niel]

Ciao.
Non saprei indicarti qualcuno in particolare, alla fine io mi sono cimentato da solo e con un po' di caparbietà sono arrivato in fondo.
Avendo fatto un po' di esperienza in questi mesi, devo dire che non sempre è così complicato, come in questo caso, arrivare a trovare e risolvere il problema. Ma serve un po' di attrezzatura, soprattutto se devi intervenire su chip saldati.
Comunque nel mio vagabondare su Facebook, qualcuno che faccia il riparatore ancora c'è. Prova a guardare tra i gruppi dedicati.