Dove riparare un VIC in Italia

[Noizer]

Simpaticissimo Il Niel , ancora non ti arrendi?
Ci fai cortesemente vedere l‘altro lato di screda com‘é combinata?

[Niel]

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....

Diciamo che un po' alla volta mi sto attrezzando. Questo VIC è diventata l'occasione per riprendere in mano un po' di conoscenze inutilizzate e allargarle. Quello che manca è solo il tempo da dedicare, ma a piccoli passi si procede.
Quindi la risposta è positiva e volentieri accetto la tua proposta.
Grazie

[Niel]

Simpaticissimo Il Niel , ancora non ti arrendi?
Ci fai cortesemente vedere l‘altro lato di screda com‘é combinata?

Grazie per la simpatia
Se ti può tranquillizzare nel frattempo ho anche rimesso in funzione il mio vecchio VIC, grazie ad una scheda funzionante e dello stesso periodo.
Ma è diventato un passatempo, e di solito non lascio le cose incomplete.

[MCes]

Allora,
il contenuto del "dummy" kernal che ho usato è essenzialmente questo:

Code: Select all

$EAAA:	JMP$EAAA    [ciclo infinito]

$FFFA: 	$AA,$EA	[vettore chiamato da NMI= $EAAA]
	$AA,$EA	[vettore chiamato da RESET= $EAAA]
	$AA,$EA	[vettore chiamato da IRQ= $EAAA]

v20loop.zip

(302 Bytes) Downloaded 79 times

In pratica come il uP esce dallo stato di RESET hardware esegue il SW puntato in $FFFC, ovvero salta a $EAAA che a sua volta salta su $EAAA creando un ciclo infinito senza aver mai avuto necessità di accedere a RAM o periferiche.

L'indirizzo $EAAA in binario è "1110101010101010" dove i 3 bit più significativi devono essere "1" per indirizzare l'area del kernal, gli altri sono un'alternanza di "1" e "0" che durante l'esecuzione devono rimanere fissi (tranne gli ultimi 3) e questa è una condizione che è facilmente misurabile sulle linee fisiche del uP anche con un semplice tester.
Monitorando l'address BUS e il pin SYNC della CPU si capisce se il loop è in esecuzione e quindi si potranno ottenere dalle misure ottime informazioni, specie se si possono sfilare i tre 74LS245 (isolatori del BUS).

Ricorda che non solo dovrai programmare una (E)EPROM,
ma dovrai anche realizzare l'adattatore perchè questa corrisponda alla pinnatura della ROM originale....
Un esempio:http://blog.worldofjani.com/?p=757

[Niel]

Eccomi, ci sono ancora.
Tempi morti dovuti al lavoro e all'attesa delle parti necessarie.
Sembra strano ma è più semplice prendere un programmatore di eprom che trovare degli zoccoli torniti fatti come si deve. Se poi ci si mette anche RS che mette nelle buste i prodotti sbagliati... Lasciamo perdere.
Ho preparato tutto e stasera comincio test con la Kernal modificata.
Magari chiederò altri lumi a Mces che si sta così gentilmente offrendo di dare una mano.

[MCes]

Poi sei riuscito ad andare avanti?
a che punto sei?

[Niel]

Si sono andato avanti.
La tua kernal modificata è stata utile, dopo essermi anche documentato (o meglio rinfrescato) un po' di teoria del 6502.
Ho perso parecchio tempo perchè con il loop della kernal attivo non leggevo i dati che mi aspettavo con la sonda.
Anche in condizione di integrati minimal (senza le VIA e le altre ROM e anche senza 74LS245) avevo segnale sporco su gli address pin da A0 a A8.
ho ricontrollato tutte le piste, ma nulla.
Poi mi è arrivato l'oscilloscopio,e ho cominciato a vederci meglio.
A0->A2 avevano segnale instabile e notavo anche minima instabilità del sync (allego un esempio).
Ho fatto i controlli sul clock e il segnale era perfetto, sia al 6561 che in uscita verso il 6502.
Ho sbattuto molto perchè pensavo a una RAM con un problema che portasse instabilità sul Bus, Poi a furia di analizzare lo schema ho capito quello che mi dicevi sul fatto che il VIC20 lo puoi tagliare in 2, e che senza 74LS245 la RAM era isolata.
A questo punto mi sono venuti i sospetti sul 6502... Lo provo su una scheda funzionante e mi da schermo nero.
Prendo quindi il 6502 che so funzionare, lo monto e... schermo nero!
Rimentto questa cpu sulla scheda buona e funziona.
In effetti avevo già testato all'inizio dei mie lavori 6502, e funzionava.
Ho indirizzato quindi i miei sospetti sull'alimentazione, visto che mi sono ritrovato la CPU danneggiata.
Ho rifatto le saldature al transistor do tensione, controllo i voltaggi e non ho più i 5V... fusibile bruciato.
Tolgo il fusibile e realizzo che era un 15A!!! Non ho idea di come possa esserci arrivato.
Sostituisco con un 3 A, come dovrebbe, e si brucia subito!
Morale: sono in attesa che mia arrivi un nuovo 5V regulator e bridge rectifier e chiaramente un 6502.
Appena arrivano vediamo se abbiamo letto il "capitolo giusto del libro".
Speriamo che il libro non sia Bandersnatch e che non sia un vicolo cieco!

[MCes]

Attento:
ricorda che avrai schermo nero o comunque non lo schermata di inizio se anche solo una di queste condizioni è presente:
1) usi il mio kernal-loop (il VIC non viene mai inizializzato...)
2) hai sfilato i 74LS245 isolatori di BUS (la CPU non può raggiungere il VIC per inizializzarlo anche con il kernal giusto)
3) altri guasti in giro...

Il kernal-loop serve solo a rendere autosufficiente la metà del computer collegato direttamente alla CPU ma questo può generare solo uno stato "vegetativo" della macchina (senza RAM o periferiche di alcun tipo: tastiera, schermo, nastro, disco, ecc...), questo stato vegetativo però può o non funzionare o funzionare mettendoti in migliori condizioni per capire, con la dovuta strumentazione, cosa potrebbe non funzionare nella macchina completa.
Comunque il senso mi pare che l'avevi già ben capito....

Tienici aggiornati!

[Niel]

Ok, mi servono idee adesso.
Premetto che la custom kernal su una board funzionante fa il suo dovere e leggo tutti i segnali corretti.
E premetto che l'alimentatore esterno funziona con altro Vic, e sotto carico eroga poco più di 9 V AC.
Quindi ho sostituito sulla scheda il ponte di raddrizzamento (che comunque funzionava), e il regolatore 5V ( questo era in corto).
Adesso ho 9V e 5V puliti.
La scheda ha a bordo solo il Vic, il 6502, e UD9 e custom kernal. In queste condizioni non esegue il loop e ho un segnale del sinc instabile. Senza la kernal il sinc è stabile. Ho controllato la continuità di tutte le tracce dal 6502 alla kernal e sono ok. Come anche 5V e gnd della kernal.
Il 6502 e il Vic su altra scheda funzionano.
Il clock è ok.
Ho guardato gli schemi più volte ma non vedo cosa controllare ancora.
Help!

[MCes]

Purtroppo già di suo un lavoro di riparazione di un sistema così composto non è facile, poi a forza di smanazzare le cose rischiano di intorbidirsi....

Non ricordo: hai verificato che a regime vanno alte le linee di RST, IRQ e NMI?

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).

Ricordati che il goal in queste condizioni (3x 74LS245, 2xMOS6522, ROM del Basic: sfilati) è mandare a loop il finto kernal, nulla potrà apparire a video

Purtroppo a distanza e senza interazione diretta è difficile dare suggerimenti sensati....

[Niel]

Grazie. Certo capisco benissimo la difficoltà a distanza e in asincrono... Mi stai già aiutando moltissimo.
Per il discorso nulla a video era chiaro: il loop non abilita nessun output. Un po' il tuo kernel me lo sono studiato e ho visto cosa fa, e tra le altre cose volevo capire perchè l'istruzione di salto alla $EAAA è non solo in $FFC e in $EAAA (loop), ma anche altrove.

Non ricordo: hai verificato che a regime vanno alte le linee di RST, IRQ e NMI?

No, verifico.

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).

Questo non mi era venuto in mente ieri. MI ero limitato a fare controlli sulla continuità delle tracce. Lo controllo.

Ricordati che il goal in queste condizioni (3x 74LS245, 2xMOS6522, ROM del Basic: sfilati) è mandare a loop il finto kernal, nulla potrà apparire a video

Qui Mi sorge un dubbio... Io sto testando anche con la ROM Caratteri sfilata. Ma penso sia corretto, dato che senza rom caratteri dovrebbe comunque funzionare: Il Kernal modificato non vi accede.

[MCes]

La presenza della ROM caratteri è ininfluente in quanto posta oltre al muro dei 74LS245, inoltre un VIC20 funzionante se privato di questa ROM continuerebbe a funzionare, solo non rappresenterebbe a schermo in maniera corretta i caratteri.

L'indirizzo di salto (vettore) è posto sia dove la CPU preleva il salto da reset che da NMI che da IRQ facendo convergere nel loop ogni possibile attività della cpu, quindi quel vettore, oltre che a fine loop, lo trovi in 3 posti:
https://www.pagetable.com/?p=410

[Niel]

La presenza della ROM caratteri è ininfluente in quanto posta oltre al muro dei 74LS245, inoltre un VIC20 funzionante se privato di questa ROM continuerebbe a funzionare, solo non rappresenterebbe a schermo in maniera corretta i caratteri.

Si, già sperimentato con altro VIC.. Non ti ho detto che nel frattempo ne ho sistemati altri 2, ma con problemi più facili da risolvere.

L'indirizzo di salto (vettore) è posto sia dove la CPU preleva il salto da reset che da NMI che da IRQ facendo convergere nel loop ogni possibile attività della cpu, quindi quel vettore, oltre che a fine loop, lo trovi in 3 posti:
https://www.pagetable.com/?p=410

Immaginavo qualcosa del genere, ma così è chiarissimo!

Dimenticavo, tra le prove che elaboravo ieri sera, pensavo di alimentare la 5V con fonte esterna stabilizzata, evitando il regolatore 5V interno. Ho ancora il sospetto che possa essere la 5V non stabile il problema. Farlo comporta qualche rischio secondo te?

[DarwinNE]

Discussione sempre molto interessante, seguo con piacere anch'io!

Dimenticavo, tra le prove che elaboravo ieri sera, pensavo di alimentare la 5V con fonte esterna stabilizzata, evitando il regolatore 5V interno. Ho ancora il sospetto che possa essere la 5V non stabile il problema. Farlo comporta qualche rischio secondo te?

Io personalmente eviterei. Se hai verificato che la tensione sia corretta dopo lo stabilizzatore e non troppo rumorosa (si vede all'oscilloscopio), non c'è ragione di usare un alimentatore esterno. Se invece vedi problemi sull'alimentazione a 5V (ma dici sopra che sono stabili e puliti), non vedo perché usare un'alimentazione esterna dovrebbe migliorare qualcosa.

[MCes]

NON FARLO!
non puoi alimentare i 5V direttamente o rischi di distruggere lo stabilizzatore che non è progettato per avere in uscita tensioni superiori alla sua entrata (in alcuni schemi, come il drive 1541, è messo un diodo che scarica "a ritroso" questo eventuale potenziale dall'uscita verso l'entrata).

comunque schemi e quantaltro, se non lo avessi già trovato, li trovi sul fantastico sito di Zimmer
http://www.zimmers.net/anonftp/pub/cbm/ ... index.html

dove puoi trovare ANCHE uno schema di principio dell'organizzazione interna del VIC20 che mi sono preso la libertà di colorare:

La divisione della macchina tra "metà della CPU" e "metà del VIC" appare più evidente con i 72LS245 a fare da anello di congiunzione, unica eccezzione sono i MOS6522 che hanno l'address alimentato dalla CPU e i dati collegati al VIC, ma questo serve a rispettare le tempistiche dei segnali necessari al 6522, ne consegue che se vogliamo "spezzare" la complessità in due cercando di mandare a loop la macchina con il kernal farlocco allora dobbiamo sfilare i 74LS245 e i due MOS6522 (questi ultimi potrebbero dare problemi alla metà macchina "CPU" in caso avessero corti interni tra pin anche dell'indirizzo o di CR/W)