Topic: That other Terraforce PCB I mentioned  (Read 634 times)

Author Message

0 Members and 1 Guest are viewing this topic.

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1185
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
That other Terraforce PCB I mentioned
« on: December 12, 2015, 10:09:18 AM »
This was the board I decided was the least likely repair candidate of the two, which considering the shit-fight involved in fixing the first one was clearly going to be unlikely.

This too had signs that it had been someones repair project in the past. The CPU had been removed and replaced by a tatty looking, badly fitted CPU socket.

The soldering on the reverse was a mess, gloopy soldering, smears of solder splashes everywhere...

... and some of the socket pins were not visible through the board They had been pushed out of the plastic housing when the socket was forced down onto the board with only partially cleared plate through holes.

The PCB interconnects had their soldering touched up with is a tell tale sign that the previous repairer had absolutely no idea what they were doing.

This makes it hard to tell what's a good joint and what isn't, in reality you are more likely to make a good joint bad, than to somehow find an invisible bad joint and score a win.

Just to see what it would do in its original state I fitted a salvaged 16Mhz crystal, swapped in the known good ROM set, dropped in the sprite PAL and powered it up. All I got was black screen and no sound beyond the amplifier hum. While poking the various CPU bus lines I did get a few coloured lines on the screen for a fraction of a second, and some random bang and ping sound effects through the speaker.

As the fluke was set up already and I now knew the ROM checksums from the other board I hooked it up and went straight to sniff the RAM. This gave and instant Read/Write fail at 0x60000 the first location in the RAM space. Setting the test to loop constantly gave a blur of changing read back results.

The RAM was another pair of TMM2063 ICs which if not dead are likely to be flaky, so I removed them.

This board clearly wanted to be repaired as the desoldering was so easy that with a single pass the chips would literally fall out of the board.

The TMM2063s passed their off board tests, and I have no problem putting them back on the board in sockets when the repair is complete, but when troubleshooting they bring too much risk off adding craziness if they decide to play up or fail mid way through.

As desoldering was so easy going I took the CPU socket off to see what horrors lay beneath.

Turns out not much...

...especially after a good clean up.

Whoever desoldered the original CPU did a very good job but whoever soldered in the 64 pin socket did a horrible job, so I guess that someone guessed the fault must be a dead CPU, and took it off the board only to find it worked elsewhere and then gave up. So it ended up in someones scrap bin until someone else tried to fix it at a later date.

With no signs of track damage and the socket off the board I could straighten all the socket pins, realign the two pins that had been pushed out of the socket housing, give it a good clean up...

...and reinstall it, I am totally out of 64 pin IC sockets and they are hard to find these days in anything other than SDIP format. I also removed and tidied up the resistor network nearby as this was fitted at a strange angle and badly soldered.

With a pair of 28 pin sockets for the RAM and the known good 6264 RAMs from PCB #1  on board I put the fluke back on, and got the same result - constant read/write errors and a blur of changing readback results.

The issues clearly weren't related to the TMM2063s. If I wrote FFFF to 0x60000 and tried to read it back, I did get FFFF back, same with 0x5555, but With the test on continuous read loop it was a blur of random results. When I stopped the loop I did get FFFF back most of the time when doing it manually (ie much slower than the Fluke). I moved onto the chip select system with the scope, which is controlled by a nearby 74LS138. With the HP logic comparator connected  to that IC as well as the fluke running its loop test I could look for any misbehaving address decoding that would have the effect of sending reads to the wrong block of address space giving read backs from ROM rather than RAM. It reported no weird behaviour compared to a known good 74LS138 it had on board.

Time to buzz out the buses, and it didn't take long to find a fault, the A3 line only connected ROMs 6 and 7 to the CPU, but not the RAM or ROMS 1,2,3 or 8. As I had photos of what was under the RAM and the CPU socket I could recheck that I hadn't missed any damage. As the bus lines seem to take a U shaped path from the CPU, up the right-hand 3 ROMs, across the two RAMs and back down through the right hand ROMs I had to have an open track between the 7 and 8 ROM sockets. I think at the right angle you can just see a dark dot on the trace as it goes under the silk screening which is probably the rot spot. Am fairly sure this board got wet and water stayed under a number of IC sockets longer than elsewhere causing corrosion.

With nothing driving the A3 input across a number of ICs it was left floating and can wander about voltage wise depending on what the rest of the IC is doing. So sometimes it was a valid logic status and other times not, so the actual address being written to in the RAM would change over time, giving the random read-back failures, but ones that were hard to catch doing manual read/writes.

After fitting some hookup wire between these ROM sockets ...

...I hooked the fluke up and re-ran the tests. All read/writes to RAM were now stable, the board even passed the "Long RAM Test" which is designed to flush out even the weirdest decoding issues.

It could also calculate the correct signature from the entire set 6 CPU ROMs, proving the CPU buses were all working fine.

This should mean the board would at least boot and do something, except it didn't, it was still stone dead.

With scope data lines on ROMs were still mashed, the most likely cause for the widespread nasty signals was that the CPU had simply crashed, this can leave the bus pins in weird states that look like something horrible has happened external to the CPU. There isn't much directly on the buses outside the RAM, ROMs, CPU some LS244s and the LS347 at B4 that caused problems on the other board.

It had active inputs but vague outputs on a number of gates, so I took it off the board. The PCB can run without this as it just disconnects a large lump of the spite graphics system. With the IC removed the board still gave a black screen but started to produce a cacophony of sound effects and long sections of background music. It started playing the theme tune early on and it sounded like it was playing blind, but the effects and music were just random, its junk data going to the sound CPU that it is interpreting as instructions to play music track X or sound effect Y, at least the sound system seems to be working. The 74LS374 tested OK on my EPROM reader by I am not over confident in it, it is possibly a coincidence that a degree of life returned when it was removed but possibly not.

Another change was that every so often the screen would now flash up blue zig zag patterns, clearly it was still crashing, but something had changed.

As I was sttill looking for something nasty on the main CPU buses, and with the constant shifting sand of faults on PCB#1  fresh in my mind, I hooked up the Fluke and re-ran the RAM and ROM tests, which it still passed, but with a CPU in the socket the board stayed resolutely dead.

You can actually use the CPU in the Fluke pod as a normal CPU and get it to try to run the board with the "Run UUT" button, UUT being "Unit Under Test". I had had no luck with a real 68000 CPU but the fluke is easier to reset rapidly as you don't need to constantly flick the power to reset the board. I tried to reset the board and issued the Run UUT command with a start address of 0x0 and the first 3 times I got no response, but on the fourth time it booted up and the board ran and stayed running.

The board had weird faults while running, there were B's everywhere...

the ship in the intro was a golden colour rather than silver...

... the sea was the same colour as the land...

...and there were blocky halos around some features.

Also the priority system has the text behind the foreground so you see it in the distance between the trees on the forest level in attract mode.
Sic Transit Gloria Atari

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1185
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Re: That other Terraforce PCB I mentioned
« Reply #1 on: December 12, 2015, 10:09:42 AM »
If the board was reset and I tried "Run UUT" again, it would usually refused to start multiple times and then would leap back into action on the 5th, 6th or 7th attempt. Once the board was running it would stay running until powered off, so I suspect there was something causing it to fail the boot up RAM/ROM tests most of the time, at which point the program is set to just halt. If whatever causes that halt doesn't trigger it, then the board will run happily for extended periods of time - a useful clue.

Poking around with the scope I started at the colour RAMs, since I had colour issues and the address space for the colour SRAMs is right next to the address space used by the CPU. Schematics here would be really useful but none seem to exist. The colour SRAMs were the known to be problematic TMM2015 chips and pin 3 (Address line 5)  was not behaving correctly, it was very weak, and spent a lot of time stuck high. This tracks to the pin 16 on the LS244 at H10 (which is the output for input on pin 4 which had a strong and normal looking signal) and also pin 17 on the 47LS374 which is the data input for flip flop 7 out of 8 on the chip.

By shorting pin 4 and pin 5 on the SRAM I was able to copy the data signal from pin 4 to pin 3, which annoyed the colour fault, the sea turned blue again and the ship on attract mode flipped back to silver. The data would clearly be wrong on A5 but some signal tells me more about the issue than a quiet line.

At that point I turned it all off, intending to take photos of the effect later, when I got back to it a couple of days later the board would no longer run at all, the best I could get out of it with the Fluke trying to Run UUT was the "RAM NG" message, but even then only on about 1 in 20 attempts.

I was fairly confident that something was interfering with that address line and causing the board's self test to fail, or the board to crash before it failed. Candidates were either one of the RAM ICs, or the 74LS244 at H10 (if it had lost the strength to pull the line low) or alternatively the input pin on the 74LS374 at H11 (if it was somehow tying the line high).

The fact I could inject rubbish onto the SRAM at that pin and get a response suggested it wasn't the RAM, the board can actually run quite happily with neither of the colour SRAMs on the board, so I knew they themselves were not causing the RAM test to fail, the issue was that something was interfering with the board's ability to test the 6264 RAMs that the CPU uses. It also suggested that the incorrect address line was being weakly driven, as a normal siganl could overcome it, which pointed to the 74LS244 at H10. So I desoldered that and tested it off the board, it passed.

The next on the list of likely candidates were the SRAM chips themselves, so I desoldered them and tested those, both passed off-board tests. This just left the 74LS374 At H11, which also passed off board tests.

So with all four ICs off the board...

...I decided to fire it up and see what it did. I knew the board would no longer output any video but I was expecting the board would be more active if the mysterious handbrake had been removed. Signs of life would be visible as activity on the buses with the scope, or sound effects if the board was now running.

On power up I got a black screen with the odd flash of colour at the very top, and then the theme tune started playing, accompanied by sound effects, which played through, went silent and then looped. This was the board running through attract mode normally. With a 68000 CPU on the board it would now run every single time I powered it up.

This proved that one of the 4 ICs I removed was the cause of the fault, but it was faulty in a way that the off board tests did not detect, either pull up ability, line driving ability or ability to run at speed, it's hard to tell. To rule out the SRAM I put them in the 1st PCB set and it ran fine, which left the one of both of the TTL ICs as culprits.

With the RAMs back on the board, and without the 74LS244 and the 74LS374...

... the game was clearly running.

Unable to prove conclusively which of the 244 or 374 was faulty I just replaced them both ...

...and the graphics system lit back up and the board was stable again, but all the original faults that were visible back when the Fluke could get the board to run were still there.

The attract mode was missing large portions of the graphics, the text was still in the background and some of the colours were still wrong, namely the ship and some of the objects in the background plane.

The most obvious was the lack of the scrolling foreground and all the missing character plane text.. I'd already run the EPROMs from this board through the tester when I was reading the set from the other PCB, all had passed except ROM 4 which showed up as totally shot. As it was not a critical ROM I had not bothered to replace it, leaving the socket empty, especially as there was obvious track damage under the socket anyway.

After dropping in ROM 4 I got a lattice of graphics fragments over the entire screen that that scrolled continuously downwards during the game-play sections of attract mode.

Poking around ROMs 4 and 4 with the scope showed that the /CE and /OE were common on each ROM, but not between them. All address lines and data lines looked busy but the /CE and /OE were permanently high on ROM5 and permanently low on ROM4, so ROM 4 chip was always active and ROM 5 was always shutdown. These lines tracked back to pins 4 and 5 on the 74LS138 at C9...

... and are outputs 1Y0 and 1Y1 on the first decoder of the pair, with pins 1,2 and 3 as the inputs. Pins 1 and 3 were tied together and to ground by the board and pin 2 was always low, but not a firm low, it wandered about a bit. With the pins 1 and 3 tied to ground it was clear that pin 2 had to be doing something otherwise the chip would be totally useless, and it was clearly not connected to what it should be. Sweeping across the working board I found that pin 2 should connect to pin 16 on the 74LS273 at H1, but on the faulty board it didn't. I could follow the path of the trace by eye across the board on both sides, and there is a very small area of track rot between the two ROMs, in much the same place as the previous broken track.

When those two pins were re-joined with some hookup wire, the cage effect vanished and was replaced by the scrolling rock clouds again.

At this point I decided to focus on the nasty looking tracks under ROM 4 and see what was actually disconnected...

... rather than approaching it from the symptoms backwards. Most tracks were actually OK but one track between pin 17 of the 74LS374 I replaced earlier and H11 this is the input pin for the gate whose output goes to A3, I had missed the inactivity earlier. Once that was joined up...

... all the previous colour faults...


The game was getting pretty close to being perfect, all I was missing now was the text overlay (score, game over etc), and also the actual game title itself. I knew this was probably just another graphics plane issue as I could see the text actually hiding behind the background sometimes.

From PCB#1 I knew that all that lived in ROM 9 and even though ROM 9 was being drive correctly as far as I could tell with the scope, underneath the socket were some more nasty looking tracks and a totally corroded out via...

...this actually has nothing to do with ROM 9, it is just a track passing through the area. With the working board I quickly buzzed through to find that the via was part of a track that connected pin 5 of the PAL at J11 in the screen plane assembly area to pin 10 on the 74LS174 at F13, on this board there was no connection between those two points.

I tracked down which section the break was in by hoping from via to via and bridged the gap with another wire link on the back of the board...

... the text and the game title on the splash screen popped back out in front.

Game fixed, or so I thought, but while play testing in my cabinet I noticed some small graphics artifacts in the side scrolling level foreground elements, the stalactites were often just blocks at their tips...

...and areas of the wrecked buildings were more mangled than they should be.

As this was a very slight issue, affecting only a small section of the graphics and was a foreground issue in both cases this looked like an upper address line issue on either ROM 4 or 5. With the multi-meter I quickly found that pin 23 (A11) was not connected between the two ROMs, so ROM 4 had no signal on address line 11 leaving it floating.

When these were joined with another small length of hookup wire...

... the final issue vanished.

Board fixed, now I just need a way to clone the single PAL I have between the two boards.
Sic Transit Gloria Atari

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1185
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Re: That other Terraforce PCB I mentioned
« Reply #2 on: December 16, 2015, 12:12:42 AM »
And now with a new GAL burnt using the file from Porchy's site the board is fixed and complete again.

Sic Transit Gloria Atari

Offline DC The Juggler

  • Moderator
  • CPC 464
  • ******
  • Posts: 202
  • Kudos 5
  • Gender: Male
    • View Profile
Re: That other Terraforce PCB I mentioned
« Reply #3 on: January 01, 2016, 04:39:54 PM »
Once more congratuations, I love reading your logs.

Elite since 1987 on the BBC B, so why does Elite Dangerous on my PC say I'm only Deadly?