ArcadeItalia.NET

Sto cercando di riparare una PCB, tra le tante tecniche vari riparatori di PCB arcade fanno uso del Mame per poter identificare quale e' il chip difettoso tramite un sistema che non conoscevo, la procedura sembra abbastanza semplice e si basa sul fatto che all'interno della rom sono presenti tutti i chip della scheda emulata, modificando questi si otterrebbe lo stesso tipo di difetto su una reale PCB, questo tipo di diagnosi lo si puo' eseguire se si hanno problemi grafici o audio...qualcuno ne ha mai fatto uso?

"Bad ROMs
A bad graphics ROM should cause a well-defined subset of graphical elements to be disturbed. The easiest way to identify the problem chip is by running the game on MAME with a good set of ROMs and systematically ruin each graphic ROM image in turn (renaming some other random file is easiest) until the same subset of graphical elements is affected as your faulty board. The MAME source code will tell you which of the image files are related to graphics elements and will usually further help by suggesting whether they're characters, tiles or sprites.
Once the target chip has been identified try reseating it in its socket. If this doesn't work, try cleaning its legs with a pencil eraser and reseating. If this still doesn't work chances are you'll have to burn the known-good image onto a fresh EPROM. And if that doesn't work, check the integrity of the ROM sockets and the PCB tracks leading to it."
http://www.mailnet.co.uk/~mike/repair.html#badgraphics

"Using MAME as a debug tool
To generate the screen shots shown on my technical pages, I took advantage of MAME (Multiple Arcade Machine Emulator). Mame can be a very powerful tool, as well as the MAME source code contains very valuable game information. Using the MAME screen snapshot capability (F12) I was able to capture perfect pictures of what the screen looked like in both normal conditions and in failure cases. (I still needed to convert the images to .jpg files and also had to create thumbnails).
For the fault cases, I made a common assumption that when a prom or eprom fails, that it reads back all ones (0xff). To insert the fault, I would, replace each ROM file used by the game with a "faulty" ROM file that contained all ones (0xff).
So, one by one, I would save a copy the original ROM file, then overwrite it with a "faulty" ROM file of the same size, but that contained (0xff). Then I would run the game and see what happened. Assuming the game would function, I would then take various snapshot images of that particular failure. I would also keep notes of what images (as MAME will number the images sequentially) matched with which chip failures. Then I would restore the original ROM file, and move on to the next. One by one I would eventually cover all the ROM for the particular game.
For some games when the main CPU roms are replaced with blanks, the game will not even execute at all. Those failures are not as interesting from a video perspective. However, some games, like the Donkey Kongs, have lots of character and sprite eproms."
http://www.brasington.org/arcade/tech/mame.shtml

se sai dove intervenire sul codice, puoi simulare sul mame delle ram non funzionanti, ma al limite potrebbe servire per restringere il problema visto che il mame assume che tutti i ttl e PAL presenti sulla scheda siano poi OK.
Il mio metodo per isolare il problema, molto più veloce, è quello di cortocircuitare le linee indirizzi delle ram o ttl per vedere cosa succede e capire se ad esempio sto scipollando sull'hardware degli sprite, sugli sfondi o sul buffer video....
questo vale solo se la scheda è senza schemi elettrici.
Naturalmente il metodo è rischioso e bisogna assicurarsi di non andare a cortocircuitare magari una linea indirizzi che per ragioni di progetto è connessa al +5 e di fianco un'altra è a massa....in quel caso si fanno fuoco e fiamme

Invece per simulare una corruzione di una rom puoi sostituire quella del mame con una vuota e vedi cosa succede, ma è più veloce avere un programmatore e verificare che sia OK paragonandola con il romset del mame.
Al limite con il sistema di inserire una rom vuota nel mame e ottieni lo stesso problema ma la rom della scheda è OK, allora capisci che i ttl/pal che bufferizzano i dati di quella rom sono sminchiati e vai a cercare li intorno.

Anni fa avevo riparato un Pacland che mostrava un problema particolare: solo il secondo livello aveva la grafica corrotta, tutti gli altri erano OK.
Dopo aver verificato le rom che erano buone, ho iniziato a sostituire le rom di pacland sul mame con equivalenti vuote.
Ottenni lo stesso problema con una rom vuota, capii quindi che su pacland ogni rom grafica contiene i dati SOLO di un livello, e che l'hardware attiva solo la rom usata, le altre sono sempre in standby! (solitamente la grafica viene spalmata su più rom e il programma si prende quello che serve dalle varie rom arttivandole e disattivandole centinaia di volte al secondo).

Ritornando sulla scheda era chiaro che la rom del secondo livello era come sempre spenta, per cui andai subito a verificare il pin CE (chip enable che per essere attivo deve essere portato a massa). Invece era sempre a +5.
Morale della favola, uno dei pin di alimentazione di un ttl era schiacciato sulla pista del pin CE e l'aveva rotta cortocircuitando il tutto

kold666 ha scritto:se sai dove intervenire sul codice, puoi simulare sul mame delle ram non funzionanti, ma al limite potrebbe servire per restringere il problema visto che il mame assume che tutti i ttl e PAL presenti sulla scheda siano poi OK.

Vero, infatti se sul mame ci piazzi un file di txt e gli cambi solo l'estensione quasi sempre non parte, se invece si porta tutto il codice a FF (che poi e' cio che accade quando un chip e' resettato) si capisce cosa fa ogni singolo chip

kold666 ha scritto:Il mio metodo per isolare il problema, molto più veloce, è quello di cortocircuitare le linee indirizzi delle ram o ttl per vedere cosa succede e capire se ad esempio sto scipollando sull'hardware degli sprite, sugli sfondi o sul buffer video....
questo vale solo se la scheda è senza schemi elettrici.
Naturalmente il metodo è rischioso e bisogna assicurarsi di non andare a cortocircuitare magari una linea indirizzi che per ragioni di progetto è connessa al +5 e di fianco un'altra è a massa....in quel caso si fanno fuoco e fiamme

Questo e' piuttosto rischioso, se la scheda e' un po' rara meglio non usarlo

kold666 ha scritto:Invece per simulare una corruzione di una rom puoi sostituire quella del mame con una vuota e vedi cosa succede, ma è più veloce avere un programmatore e verificare che sia OK paragonandola con il romset del mame.

Con il programmatore sarebbe velocissimo, si legge e si raffronta con il codice presente sul mame...ne ho un paio ma per quel tipo di zoccolo no

kold666 ha scritto:Anni fa avevo riparato un Pacland che mostrava un problema particolare: solo il secondo livello aveva la grafica corrotta, tutti gli altri erano OK.
Dopo aver verificato le rom che erano buone, ho iniziato a sostituire le rom di pacland sul mame con equivalenti vuote.
Ottenni lo stesso problema con una rom vuota, capii quindi che su pacland ogni rom grafica contiene i dati SOLO di un livello, e che l'hardware attiva solo la rom usata, le altre sono sempre in standby! (solitamente la grafica viene spalmata su più rom e il programma si prende quello che serve dalle varie rom arttivandole e disattivandole centinaia di volte al secondo).
Ritornando sulla scheda era chiaro che la rom del secondo livello era come sempre spenta, per cui andai subito a verificare il pin CE (chip enable che per essere attivo deve essere portato a massa). Invece era sempre a +5.
Morale della favola, uno dei pin di alimentazione di un ttl era schiacciato sulla pista del pin CE e l'aveva rotta cortocircuitando il tutto

[/quote]
Ottimo lavoro...a volte bisogna ingegnarsi...ma quando si trova il problema la soddisfazione e' immensa
Io ho iniziato riparando schede madri del c64...era bellissimo riportarle in vita

X il momento lo schermo rimane cosi...sembra piu' un problema di ram che di rom..


Adesso provo a verificare se i 5v sono corretti su tutta la scheda...poi vediamo il da farsi...

Il difetto che provocava l'immagine nel post precedente era dato da una rom bruciata, esattamente la 330 7L, x curiosita' ho provato a modificare il file della rom 330 x testare il metodo del mame come "debug tool", ma sebbene il gioco parta mi rimane lo schemo nero e non ottengo la stessa schermata...