Newsgroup: it.comp.retrocomputing
Titolo: ROM diagnostica: nuovo esperimento col PET/CBM [Lungo]

 
Qualche tempo fa avevo postato il racconto di come, cercando di riparare 
un Xerox 820-II, fossi riuscito a realizzare una ROM diagnostica per 
individuare i chip di RAM non più funzionanti senza strumentazione e 
senza dover dissaldare tutto alla cieca.
 
Questa volta ho voluto ripetere l'esperimento sul 6502 e quale miglior 
cavia di un povero PET? :-) La scelta non è stata casuale, primo perché 
i PET serie 2001 e 3000 hanno un hardware video abbastanza semplice 
(basta scrivere i codici PETSCII nella video RAM ed ecco che compaiono i 
caratteri), secondo perché ne avevo un paio qui bisognosi di attenzioni. 
So che esiste qualcosa di simile in giro, ma non potevo non raccogliere 
la sfida ;-)
 
Come sapete, il 6502 ha solo 3 registri in quanto progettato sulla 
semplicità, la velocità di esecuzione e l'accesso diretto alla memoria.
Quando però si tratta di testare la RAM e fornire i risultati a video 3 
registri dove confinare tutto stanno un po' strettini... anche perché
1) Non posso usare la pagina zero (perché non so se è buona).
2) Non posso usare lo stack (per il motivo di cui sopra, quindi niente 
subroutine).
3) Devo comunque convertire i gli errori in qualcosa di intelleggibile e 
metterli a video.
 
L'unica arma a disposizione è lo spazio in ROM (visto che posso usarlo 
tutto per me :-P ). Il codice viene per forza prolisso e ridondante, ma 
tentare di ottimizzare in queste condizioni è una causa persa...
 
Mi viene in aiuto la solita FLASH opportunamente adattata, per non 
impazzire con le EPROM. Ed ecco il risultato finale, qui si vede la ROM 
che segnala un errore su un PET chicklet all'indirizzo $1800
 
http://imgur.com/qVQO3oE
 
 
Qui un brevissimo video della ROM che testa un 3032 senza trovare errori:
 
http://youtu.be/j0tHh5pj1Rw
 
 
Ed ora le noiose info tecniche (per chi non è interessato consiglio di 
saltare direttamente alla parte 2 - prossimo post):
 
Tutti i test sono effettuati scrivendo e rileggendo 4 diversi pattern 
per locazione:
 
FF, 00, 55, AA
 
Per prima cosa viene testata la pagina zero: ciò è possibile perché 6502 
ha OPCODE appositi per l'accesso diretto senza bisogno di usare la RAM 
per tenere l'indirizzo da provare (cosa invece necessaria per il resto 
del test, a meno che non si voglia duplicare il codice per 256 pagine 
diverse!). Se rileva un problema, fornisce a video il byte scritto ed il 
byte riletto convertito in caratteri ASCII. Forse è possibile ingegnarsi 
ulteriormente per fornire anche il byte basso dell'indirizzo, ma è 
praticamente inutile perché:
 
1) Per i PET con RAM statica, l'errore è sicuramente nel primo chip
2) Per i PET con RAM dinamica, il chip rotto si ricava dal confronto dei 
due byte.
 
Se la pagina zero è buona, ripetiamo l'operazione per la pagina 1, 
ovvero lo stack. Il codice è duplicato pari pari e l'indirizzo base è 
cablato dentro ($0100).
 
Se anche lo stack è buono, adesso ci sbizzarriamo: non solo posso usare 
le subroutine, ma anche la pagina zero: infatti mi prendo 3 byte da 
$0002 dove mettere l'indirizzo sotto test ed il pattern usato (da $0002 
e non da $0000 è più per scrupolo, metti che un giorno volessi fare il 
porting sul C64 o sul CBM-II... :-D ). Con tutto questo "ben di Dio" 
(seh... vabbé :-) ) posso mettere qualche informazione in più a video:
L'indirizzo sotto test, convertito in ASCII, viene mostrato in tempo 
reale. Se viene trovato un errore, a video compare quindi:
 
AAAA w XX r YY
 
dove
AAAA = indirizzo
XX   = byte scritto
YY   = byte riletto
 
e mi fermo. Se invece è tutto OK, compare la scritta "OK" (appunto :-D ) 
e dopo una breve pausa la routine riparte.
Essendo pensata per il PET, la ROM si ferma a 7FFF, ma il test potrebbe 
comunque essere esteso. Da notare che al momento non testo la video RAM, 
primo perché imbratterei tutto lo schermo e secondo perché se già non 
funziona sarà difficile vedere qualcosa di comprensibile... tuttavia non 
è escluso che si possa pensare a un qualche tipo di test.
 
Per poter funzionare, tutta la baracca ha bisogno almeno che:
 
1) L'hardware video della macchina sia buono (compresa la video RAM e la 
ROM carattere).
2) La CPU funzioni.
3) Non vi siano incasinamenti sul BUS dovuti a chip in coma.
 
Tutto il resto può anche essere scoppiato ;-)
 
*Gabriele*
 
 
 
 
 
 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

 1) Per i PET con RAM statica, l'errore è sicuramente nel primo chip
 
Scusate ho detto una bischerata: l'errore è sicuramente nei primi due 
chip in quanto controllano 4 bit ciascuno e si vede dal confronto dei 
nibble.


[PARTE 2]
 
Dopo aver messo insieme uno straccio di ROM funzionante, mi è venuta 
voglia di estendere la cosa anche ai CBM serie 4000/8000. Come sapete 
l'hardware video di queste macchine è abbastanza diverso in quanto 
montano un chip video apposito (6545 CRTC) che deve essere 
opportunamente programmato, altrimenti non si vede niente.
 
Ammetto che non avevo voglia nè di studiarmi il 6545, ne di fare il 
reverse engineering del Kernal del PET. Per fortuna ho trovato uno 
snippet in rete che mostra proprio come inizializzare il 6545: sono 
pochi byte, ma fondamentali.
 
Inserita la routine e fatti gli opportuni aggiustamenti, ho potuto così 
adattare la ROM anche ai CBM "professionali".
Mi è però sovvenuta una domanda esistenziale: cosa succederebbe se 
l'hardware video fosse KO? Il 6545 potrebbe essere andato, oppure una 
delle logiche di supporto, o la video RAM. Cosa si potrebbe fare in tal 
caso?
Sappiamo che i CBM4000/8000 hanno un output in più rispetto ai fratelli 
minori... il cicalino!
 
Ho provato quindi a realizzare una versione "blind" della ROM 
diagnostica, basata su codici "sonori".
La routine è ciclica, in modo da permettere all'utente di annotare la 
sequenza sonora.
All'avvio viene prodotto un suono da "pistola spaziale". Se dopo un po' 
risentite lo stesso suono senza sentirne altri, vuol dire che tutto è 
andato bene e la routine è ripartita.
Se viene trovato un errore la routine emette:
 
1) una sequenza di beep (da 1 a 4) per identificare il pattern di test 
(1 beep = FF, 2 beep = 00, 3 beep = 55, 4 beep = AA)
 
2) La codifica binaria del byte errato, dove un beep "alto" significa 1 
ed un beep "basso" significa 0
 
Dopodiché riparte.
 
Poiché un esempio vale più di 1000 parole, ecco un piccolo video sul mio 
8032: riuscite a riconoscere i byte di test e quello errato? :-)
 
http://youtu.be/pjc_aSwxVRU
 
 
[SPOILER]
.
.
.
.
.
.
.
.
.
.
.
.
 
Bene, le risposte sono FF ed FD :-D
Infatti si sente 1 beep di patterm (pausa) e poi
 
alto alto basso alto alto alto alto alto alto
 
pari a 11011111 il che incolpa il terzo IC 4116.
 
Per processare il byte errato, in pratica faccio il ROL e scelgo il 
suono in base al valore del carry, per ogni bit.
 
Purtroppo la routine è incompleta perché attualmente mi servono 4 byte 
di pagina zero per l'implementazione e quindi i test di pagina zero e 
stack page in pratica sono skippati.
D'altra parte ho bisogno di X ed Y anche per il loop di durata del suono 
ON/OFF, dunque sono proprio alle strette...
Comunque un modo forse c'è, devo magari studiare un po' meglio 
l'assembler del 6502.
Inoltre non potendo visualizzare l'indirizzo, l'errore può essere sia 
nel banco alto che in quello basso (comunque la cosa potrebbe essere 
risolta con un suono ad hoc che identifica il banco sotto test).
 
Se riesco vorrei combinare le due routine, in modo da avere sia il 
supporto a video sia quello sonoro.
 
Il cicalino è controllato dallo shift register del VIA, quindi è 
necessario che questo integrato funzioni (oltre ad almeno la CPU ed il BUS).
 
Bene... spero di avervi intrattenuto... quasi quasi mi metto a vendere 
ROM diagnostiche! :-DDDD :-p


 Bene, le risposte sono FF ed FD :-D
 
Ehm... volevo dire DF  ;-)


 *Gabriele*
Molto interessante, bravo !
Con il supporto video sarebbe completa.
Tienici informati, ho un 3032 un po' zoppo ...
 
 

 ROM diagnostiche! :-DDDD :-p
Beh, ottimo lavoro! Grazie per aver condiviso l'esperienza :)
(Nel caso dovesse poi sfumare l'idea di un business basato sulle rom 
diagnostiche, se non e' chiedere troppo, sarebbe interessante dare una 
sbirciata al codice :P)
 
Ciao,
   Gabriele

 senza dover dissaldare tutto alla cieca.
 
affascinante e ingegnoso, complimenti!
La Forza (anzi, "lo Sforzo") scorre potente in te.


 
Cos'ha il tuo PET esattamente?
 
*Gabriele*
 

Interessante questa cosa sulla rom diagnostica. .
Si riuscisse a fare anche per l m24...
Sinceramente non saprei da dove iniziare pur avendo le giuste eprom e il programmatore. ..


 
Inizia a guardarti l'assembler 8088 e come si programma il chip, poi la 
mappa dell'M24 e il disassemblato della ROM originale (chissà se sul 
manuale c'era il listato...), cerca di isolare la parte di 
inizializzazione e diagnostica, se capisci come funziona puoi provare 
migliorare quella invece di partire da zero.
 
*Gabriele*