Chelnov Repair Logs
Repairer: Apocalypse
Source: Chelnov/Atomic Runner - Data East 1988 (repair log)
Some repairers have what they call a "too hard to repair" pile. I don't understand this concept, to me boards are either repairable or not.
Not repairable means a custom chip is faulty (so far I've always found a solution to circumvent faulty security chips).
Instead I have a "too long to repair" pile. In this pile you find boards I know I can repair but requiring a lot of time.
This Chelnov board was one of them.
First I swapped all the ROMs, PROMs and security chip on a Karnov board to confirm they were ok. Test was sucessful (meaning all ROMs, PROMs and security chip were good).
Then I started to repair the bottom board as it contains the only custom chip of the boardset, possibly being a repair killer.
The game was victim of the Fujitsu plague: I removed and replaced all Fujitsu TTL chips of the bottom board (only 5 of them) and then tested the board with the Karnov top board: it was now fully working.
This is where I left the repair for one year and a half. At this point I knew I could fix the board as all the ROMs, PROMs and security chip were tested OK, so as the only custom chip on the bottom board. I was left with a top board heavily populated with Fujitsu TTL chips and by probing few of them I could tell the damage was extensive...
When I got back to it I moved on the top board with the same treatment: I pulled all the Fujitsu TTL chips (probably 80+).
This took me several hours... (remember "too long to repair").
Out of curiosity I tested them on my programmer and 52 turned out to be bad...
Ok, after that game was still dead, showing only a garbage screen.
I found reset signal of the main CPU was too low to be considered as being a high level (below 3V): 68k was faulty and probably partially grounding/dragging down the signal.
I installed a new 68k, reset signal was now healthy but behaviour of the game didn't changed.
So I started to probe the data signal of the main CPU and found there was activity only for a fraction of second after power up.
To me this was a problem with code execution. All the TTL on buses were new now so I checked traces between the program ROMs and RAMs but they were all OK.
Last probable culprits in line were the work RAMs, unfortunately activity didn't last long enough to see anything on my old analog scope.
So I pulled them and both revealed bad on my programmer. Once replaced the game booted!
With sound, controls, texts and background but sprites were totally absent.
Probing TTL chips I found the outputs of the only 7425 (Texas Instruments) on the board were floating: sure enough it was bad.
I replaced it and finally obtained a fully working game.
- 1 * CPU 68000
- 2 * work RAMs (6264 type)
- 1 * LS08 (Fujitsu)
- 2 * LS10 (Fujitsu)
- 1 * LS30 (Fujitsu)
- 3 * LS32 (Fujitsu)
- 6 * LS74 (Fujitsu)
- 1 * LS125 (Fujitsu)
- 1 * LS138 (Fujitsu)
- 9 * LS153 (Fujitsu)
- 7 * LS157 (Fujitsu)
- 1 * LS174 (Fujitsu)
- 3 * LS194 (Fujitsu)
- 11 * LS245 (Fujitsu)
- 4 * LS283 (Fujitsu)
- 2 * LS374 (Fujitsu)
- 1 * 7425 (Texas Instruments)