Results 1 to 7 of 7

Thread: Snow Bros Repair Log

  1. #1

    Join Date
    Oct 2007
    70 Post(s)
    375 Post(s)

    Snow Bros Repair Log

    I got this board sometime back in 2013 according to the dates on the photos I found, so it has been on the to-do pile for 6 years.

    The symptoms were basically that it appeared to be dead, giving a white screen on power up that turned black, or purple after a few seconds.

    I don't actually remember where I got it, but the early photos I've found show it was pretty dirty, with a few minor of signs of abuse.

    A smashed resistor array at RA10 (which is just a 9 pin pull-up which was easily replaced)...

    ... and a dribble of paint, or worse, across a 74LS245 on the CPU data bus.

    My initial suspicion was that the board was crashing on boot, as there was a burst of activity on the main CPU buses and then everything went quiet. On the scope the CPU data bus looked pretty horrible...

    ... and the usual culprit for such ragged signals is failed RAM.

    As the 68000 CPU was soldered into this board I would need to remove it and fit a socket before I could connect the pod, and desoldering CPUs is something I generally try to avoid doing unless I hit a wall with less intrusive troubleshooting.

    So the logical step was to just desolder the RAM, and prove it was faulty by testing it off the board in my EPROM reader.

    Except it wasn't faulty...

    ...and nor was its partner. With the ROMs off the board as well the data bus went quiet, as the board does nothing, so the glitching had gone. Testing a chip off the board in isolation is fine, and a fail is a fail, but a pass just means it behaves on its own, it doesn't conclusively say the chip can behave when on a shared bus with other parts.

    So I desoldered the 68000 CPU...

    ... fitted sockets for the RAM and the CPU, and wheeled out the Fluke.

    Boards that don't boot usually have a fault with something hanging off the CPU buses, either RAM, ROM or the control logic that stitches it all together, or potentially the CPU itself. The Fluke 9010 lets you effectively become the CPU on the board and test what it can "see" out on the buses, as opposed to a real CPU that will either work, or crash, after which point it sits in a twitching mess until either a watchdog system resets it, or you pull the power out. Not a helpful state when you are trying to troubleshoot with a logic probe or scope.

    Withe the Fluke I was quickly able to check the CPU could drive all the lines, test the RAM and read the main ROMs. The main system RAM test passed with flying colours...

    ...but the ROM test feature was where my past problems were with this pod.

    The ROM test asks you for a start address, and end address and the signature you are expecting for the data sat between those two locations.

    The memory map in the MAME drivers are godsend as they contain a huge amount of information about how the board is put together, including where the RAM and ROM sits from a CPU's perspective.

    map(0x000000, 0x03ffff).rom();
    map(0x100000, 0x103fff).ram();

    To get the signature you just run the ROM dump through the CalcSig application, and if you have proven the ROMs on the board are valid you can then check whether the CPU can read those ROMs when they are on the board, which tests the buses and the control logic.

    The first problem was that the main ROMs are a pair of 8 bit EPROMs, but the data bus on a 68000 CPU is 16 bit, so the CPU doesnt see them as two ROMs worth of data. The ROMs actually work in parallel with each ROM contributing 8 bits to the 16 bit word, so I had to interleave the bytes to get a merged ROM file I could get the Fluke Sig for, and when merged, the signature I got back from the app was FFF3.

    The Fluke came back saying the data it found between those addresses gave a sig of 260A...

    ...despite the fact I could consistantly read WORDs from all over the ROM space and always get the right value back the actual signature always failed to match,

    I'd met this problem before while testing the 68000 pod on a Rainbow Islands board, and after far too much time expended, a lot of discussion on Klov, with a variety of people trying it with their Flukes it was agreed that CalcSig program everyone has been using for years only works for 8 bit pods, and that the 16 bit algorithm was a mystery. So trying to use the ROM test function on my new 68000 pod was a waste of time, all I could do was run dozens of read tests and check I always got what a hex editor on the PC said I should get for that ROM location. So from what I could see the ability for the CPU to read the full ROM was probably OK, but not 100% certain.

    At which point the Snow Bros PCB went in the drawer and according to the photos I turned my attention to the pair of badly shagged Sega System 16A Shinobi PCBs that had arrived.

    Fast forward 6 years and Snow Bros was back on the bench, next to a Snow Bros from my own collection that had fallen over with a very simple fault - just a dodgy ROM socket.

    With one working one and the dead one on the bench I noticed that the time it took the working board to complete its self-test and boot into the game (or report an error if I introduced a short to the sound CPU bus, or palette RAM bus) was the exact same amount of time the bad board took before everything went quiet - 2.5 seconds, which I had assumed to be the board crashing back in 2013. But what if this board wasn't crashing, what if it was just reporting an error that I couldn't see because of another fault?

    If I created a fault with my working board it looked much the same as the faulty on the data bus, a brief burst of activity before everything went quiet. Now a fully working board plays a short sound on boot up when the tests pass, but doesn't make any noise if they fail.

    So I restarted troubleshooting by assuming the CPU could read the RAM and the ROM fine and that there was an issue in the video output. A good place to start seemed to be around the Sharp LH5116 palette SRAMs at 6N and 8N.

    Despite the burst of activity on the control lines and the data bus there was never any activity on the data bus, which is buffered to the CPU through a pair of Hitachi 74LS245. With no data hitting these chips there would be issues with the video. Hitachi TTL chips seem to be the most resilient TTLs on this era of boards, I've never met a bad one that wasn't physically damaged, so the SRAMs themselves were a more logical place to start.

    Both came off the board and were tested on my EPROM burner. One was bad...

    ...but replacing it change anything obvious.

    So in the absence of any schematics I traced out the addressing for these chips to a 74LS157 and 74LS158, again Hitachi TTLs, which both had activity on the outputs, but each gate had a floating input pin, all of which traced back to the D42101C-3 IC at IC22.

    This is basically a line delay buffer, a very uncommon chip for arcade PCBs, and all of it's 8 output pins were floating.

    Digging through the datasheet one states that the outputs are tri-state, meaning they can be disabled and put in high impedance state, but this seemed to be only triggered by the behaviour of input signals and the timing of it all, not from a specific /CE pin as is often the case.

    But going over the working board with the scope and noting the behaviour of the inputs and comparing with the bad board I couldn't seen anything majorly different, although as the timings would be critical I was really only looking for things that massively different rather than anything more specific, but all signs pointed to a bad D42101C-3 IC

    My only real option was to desolder the D42101C-3 from both the good and bad boards, fit sockets and swap them over.

    Swapping the suspect D42101C-3 into the good board produced a white screen, that went a very black after 2.5 seconds, but then the board then played the "test passed" chime noise and started attract mode, playing blind.

    Putting the known-good D42101C-3 on the faulty board gave me this. The board booted, did its self test stuff...

    ... silently displayed a badly corrupted "test passed" screen (no chime sound)...

    ...and then went into attract mode, with messed up graphics, colours and a crazy white flashing interference across the entire screen.

    So the D42101C-3 was dead, and it was hiding the "COLOR FAULT" error message that the bad SRAM IC was causing, which was causing the board to halt.

    As the board doesn't display a Sound Error the Z80, and the Z80's RAM and ROM were probably fine, and as I could get speaker hum by touching the amp pins, the audio fault was probably just a dead DAC, fairly common, but next up was the horrible graphics.

    Aside from the violent white flashing the colours were wrong, there were blocks of colour in the wrong places and everything had a speckled appearance.

    Every dead Snow Bros I've fixed has a fault in the DRAM section, they are very static sensitive chips and are right by the PCB edge where lightning infused fingers can get to.

    The likely cause for all of these is multiple failures in the 41464 DRAMs at IC23 to IC 26...

    ...I've never met a Snow Bros that doesn't have one of more of these bad, and touching the underside of IC25 seemed to calm the flashing down majorly

    Only one of the ICs looked like it was putting out useful data on its output pins...

    ...the others looked pretty unwell on some or all of the 4 data pins.

    As 3 of the 4 DRAMs looked suspect they call came off the board...

    ...I replaced all 4 with a matching set of new old stock ones, in sockets so I could swap the old ones back in one at a time...

    ...and on power up...

    ...the test message was readable again, and

    ...fixed graphics.

    Swapping in the old DRAM ICs one at a time confirmed that 3 of them were shot, with only one survivor.

    With that fixed the remaining issue was the sound.

    As the sytsem booted without giving a "Sound Error" I figured the Z80 subsystem was probably fine. The Z80 basically acts as the conductor, loading up the YM3812 chip to get it to play the music and generate the sound effects. This chip then spits out the digital data for the audio into a YM3014 DAC, which goes into an Op-Amp to and then finally into the power amp.

    A DAC failure is fairly common but in this case the digital data being delivered to the DAC was just a steady stream of pulses, that never changed. The DAC was also missing the clock input as that pin was just floating. Both the data and the clock come straight from the YM3812 OPL chip, and as the YM3812 was getting the master clock, the fact it was not giving out the DAC clock meant it was dead.

    So it came off...

    ...where to borrow one in a hurry?

    Off an original Soundblaster card of course!

    With that installed in a socket I now had clock back at the DAC and got a few chirps and farts out of the speaker. This proved the op-amp and the main amp were OK but clearly there was more at faults to find.

    I was now getting a signal that looked more like data to the DAC, and the clock, but either the DAC was also bad, or the data wasn't viable. I've met so many dead YM3014 chips I just desoldered the one at IC32...

    ...fitted the only 8 pin socket I had left and swapped in a known good one - no change.

    At this stage I went a bit off into the weeds, I had assumed all along that the Z80, its RAM and ROM were fine because it passes the self-test without showing up a sound error, and any time I interrupted the data or address bus in this area the self test would fail. But now having swapped out the YM3812 and the DAC there wasn't much left in the audio digital section except the CPU, RAM and ROM.

    Comparing the signals on a working Snow Bros board I found a couple of differences in how the YM3812 was being driven with the /INT and /IRQ lines.

    /INT is the signal that is sent by an external device to the CPU, requesting an interupt, and in this case it was just held high. The YM3812 was known good so the lack of any activity was a symptom of the YM3812 not being driven correctly rather than the cause.

    The /IORQ signal comes from the Z80 itself on pin 20, to connected devices, and on the scope this signal was flickering, with the scope showing flashing patches of high and then no signal, which isn't a valid signal at all, but it was late, I was tired so I took the wrong path, and took it to mean that the CPU was likely bad. So I desoldered it fitted a socket and dropped in another Z80B...

    ... and of course there was no change.

    In reality, bad Z80s are very very rare, but bad SRAM (like the one sat right next to the Z80, and one of three 6116s on the board, of which one had already been found to be dead) is very common, and of course a crashed CPU does all sorts of crazy shit. Shouldn't repair boards at midnight

    Anyway, I pulled the 6116 RAM and of course it was faulty.

    Replacing it fixed the final fault and restored all the sound.

    Clearly the boot up sound system check is so half-arsed that a board with a bad SRAM can still pass. Swapping back in the YM3812 and the YM3018 back onto the board showed they were dead anyway, so it wasn't a total wild-goose chase.

    I generally try to avoid using sockets in repairs, as they are a future point of failure and are not cheap. Where I do use them is when I can't rule out the part coming off the board is bad or not, as they do let you swap parts back in once the fault is finally solved to check if they were part of the problem or not. Plus the pins have such a low thermal mass it is very easy to desolder and remove them later.

    So the finally tally of the guilty for this board is fairly extensive.

    3x 41464 DRAMs
    2x 6116 SRAMs
    1x D42101C-3 Line Buffer
    1x YM3812 OPL Generator
    1x YM3014 DAC

    What the hell happened to to this board to kill that lot???
    Last edited by Womble; 15th January 2019 at 09:14 AM.
    Sic transit gloria Atari!

  2. #2

    Join Date
    Dec 2014
    101 Post(s)
    612 Post(s)
    Great post.

    I read it all, didn't understand a lot of it, but can see the amount of work that went into that board.

    I am always impressed with the knowledge and skills some of you guys have to bring these old things back to life.

    Great job @Womble

    My Twitch stream -

  3. #3

    Join Date
    Dec 2006
    Parramatta NSW
    35 Post(s)
    132 Post(s)
    Wombles awesome. I can say first hand his work is as neat as a pin

  4. #4

    Join Date
    Oct 2007
    70 Post(s)
    375 Post(s)

    Thanks guys, I managed to give the to-do pile a bit of a slap over Xmas, so have some more of these coming up in the next few days.
    Sic transit gloria Atari!

  5. #5

    Join Date
    Mar 2015
    66 Post(s)
    441 Post(s)
    Another awesome write up, thank you again for sharing so much of what you know with each of these repairs.

  6. #6

    Join Date
    Jan 2014
    13 Post(s)
    124 Post(s)
    Love these write ups, thanks for taking the time to put it all together.
    Look forward to the next one.

  7. #7

    Join Date
    Jun 2009
    0 Post(s)
    2 Post(s)
    Great repair as always. Since the 68000 checksums aren't known maybe it's worth trying to document checksums from known good boards? I've got a few konami boards with socketed cpus.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Snow Bros Repair Log
    By Womble in forum PCB and Monitor Repair logs
    Replies: 12
    Last Post: 13th January 2013, 07:39 PM
  2. Lets repair a Snow Bros 2 PCB
    By stu in forum PCB and Monitor Repair logs
    Replies: 27
    Last Post: 2nd January 2012, 07:42 PM
  3. snow bros repair
    By RaMpAgE in forum Arcade Technical and Repair Questions
    Replies: 28
    Last Post: 30th June 2008, 11:42 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts