Major Havoc repair

douglasgb

Well-known member

Donor 11 years: 2012-2022
Joined
Nov 17, 2003
Messages
3,393
Reaction score
485
Location
Santa Monica, California
Got a conversion board in that I suspect will have multiple problems. There is a lot of previous work that has resulted in damaged traces, which have been kludged back together with jumper wires. Make some popcorn for this one.

First, I remove the Alpha processor and hook up the Fluke. The bus test passes, as do the program RAM and ROM tests. Note that the ROMs at 1L and 1M/N can be tested normally, but the ones at 1N/P and 1Q have address line 13 controlled by MMUPAGE0, so they must be tested in two steps. This is done by writing different values to address 1740 to set MMUPAGE0 and MMUPAGE1 and then getting the checksum for ROM2 (2000-3FFF). Also note that the WDDIS must be grounded so the watchdog does not reset the LS74 flip flop @ 2N that sets MMUPAGE0 and MMUPAGE1.

Some may ask why not simply remove the chips and test them with a reader. You could do that, but I'd rather leave them in place and see what the CPU is actually reading (which tests sockets, traces, and all the supporting chips like decoders and buffers). Gotta justify the cost of the Fluke and pod!

Here's how writing to address 1740 sets the flip-flop to access the two halves of the two ROM chips at 1N/P and 1Q. Accessing that particular address means that the CPU will momentarily set address bits 12, 10, 9, 8, and 6 to a high logic state (since hex 1740 = 0001 0111 0100 0000 binary). Those address lines (after being buffered by 2Q and 2P) go many places, but we're interested in what happens when they hit the LS139 at 4N and the LS138 at 5N:

attachment.php

from sheet 5B

A high on buffered address lines 9 and 10 will go into pins 2 and 3 of the LS139, causing it to output a low on pin 7 (the data sheet tells you so). That goes over to the LS138 pin 5, which will enable that chip when pin 4 is also low... which happens when the CPU is writing. Other inputs are A, B, and C coming from address bits 6, 7, and 8. Six and eight are high, which causes the LS138 to make output pin Y5 low. That is the /MMU signal. Address decoding at its finest!

The MMU acts as the clock signal for the flip-flop at 2N, which is permanently in preset mode due to the +5v at pins 4 and 10. Preset means it will take whatever data is present on its input pin (D) and set and hold its output pins (Q) at that level when the clock is pulsed. What data is present on the input pins? Pin 12 is connected to (buffered) data bus line 0, while pin 2 gets BD1.

attachment.php



Putting this all together, when writing a zero to address 1740 the address bits cause a pulse on /MMU so the logic lows on BD0 and BD1 are transferred and held on MMUPAGE0 and MMUPAGE1 (and the LS74 also creates /MMUPAGE1 at pin 6 = the opposite of MMUPAGE1 eg logic high). Other values written to 1740 will set the outputs as follows:

0 = binary 00 results in MMUPAGE1 = 0 and MMUPAGE0 = 0
1 = binary 01 results in MMUPAGE1 = 0 and MMUPAGE0 = 1
2 = binary 10 results in MMUPAGE1 = 1 and MMUPAGE0 = 0
3 = binary 11 results in MMUPAGE1 = 1 and MMUPAGE0 = 1

These signals are then fed into the pins of the ROMs themselves. When MMUPAGE1 is low /MMUPAGE1 is high so 1Q is enabled and 1N/P is not. Meanwhile MMUPAGE0 is controlling address bit 13 of the ROM chip, so when it is low you get data from the lower half of the chip, and when it is high you get the upper half. So:

1740 = 0, ROM TEST @ 2000-3FFF gets the lower half of 1Q whose Fluke signature is 2057 (v3) or CA55 (v2)
1740 = 1, ROM TEST @ 2000-3FFF gets the upper half of 1Q sig FD30 (v3) or 52EA (v2)
1740 = 2, ROM TEST @ 2000-3FFF gets the lower half of 1N/P, sig C37C (v3) or 4876 (v2)
1740 = 3, ROM TEST @ 2000-3FFF gets the upper half of 1N/P, sig 2DF2 (v3) or D0B8 (v2)
 

Attachments

  • Screen Shot 2017-12-09 at 5.29.08 PM.png
    Screen Shot 2017-12-09 at 5.29.08 PM.png
    124.8 KB · Views: 275
  • Screen Shot 2017-12-09 at 6.09.12 PM.png
    Screen Shot 2017-12-09 at 6.09.12 PM.png
    229.8 KB · Views: 473
Last edited:
Thanks for sharing. I love reading stuff like this. Hopefully some day I'll understand half of it haha.
 
All the program RAM and ROM checks out OK, so it's on to testing the vector RAM and vector ROM. Vector RAM is straightforward, from address 4000 to 47FF for 6M/N and from 4800 to 4FFF for 6L/M. Vector ROM at 6K/L is also easy, from 5000-5FFF. The other two vector ROMs and 6H and 6J/K are more complicated, as they are paged like the programs ROMs discussed earlier. The signals which select these ROMs are MAP0 and MAP1, and writing certain values there (and keeping WDDIS grounded) will allow the ROMS to be checksummed.

All of the vector RAM and vector ROM tests fail, so that gives us a clue of the scope of the problem. If it were just one chip, it could be that chip is bad or the select lines that enable it weren't firing. For example, if the vector RAM at 6L/M passed but the one at 6M/N did not, we would know all the address and data lines that are common to both are OK (since one of them passes) but there is something unique about 6M/N that was not working... and about the only thing there is would be the /VRAM0 signal going into pin 18 (or a bad socket).

Since both RAMs and all three ROMs are failing, we concentrate on checking lines that are used by all five chips. Testing with a logic probe quickly reveals that all the address lines are pulsing but that some of the data lines (VGD0-VGD7) are stuck. This is the data bus between the vector RAM, ROM, and data shifters. But the CPU (and Fluke) access the vector RAM and ROM through the LS245 transceiver at 5M:

attachment.php

from sheet 6A

While one of the Fluke tests is looping, probing the CPU side (BD0-BD7) of the transceiver shows that some of the data lines on that side are neither pulsing nor stuck... they are doing a low buzzing as if they are trying to pulse but cannot. So I think the trouble is somewhere on the BD0-BD7 bus. Let's see where that goes.
 

Attachments

  • Screen Shot 2017-12-09 at 7.48.35 PM.png
    Screen Shot 2017-12-09 at 7.48.35 PM.png
    523.2 KB · Views: 257
Last edited:
Next is to make a list and check each chip that accesses BD0-BD7. The Atari schematics help by including a notation indicating all the other sheets with circuits where the bus connects. Similar to the real thing, the 'bus' means a collection of signals lines that are grouped together and make several stops to collect or deliver data. In this case there is a bus on both sides of the LS245 at 5M; they carry data so they are called data busses (as opposed to address busses)

The purpose of 5M is to connect or disconnect this vector data bus from the CPU: the CPU needs access when the program is loading the vector generator RAM with instructions, but the vector generator needs to be able to read vector RAM and ROM when it is actually doing the drawing (and the CPU has moved on to other tasks). To manage this traffic there are two control signals going into pins 1 and 19 of 5M that turn the flow of information on or off and dictate its direction through the chip.

On the left side of 5M is the VGD0-VGD7 bus carrying data amongst the vector generator chips when the vector generator is running. The drawing shows pins 11-18 of 5M are connected to pins 11-13 and 15-19 of 6K/L, but that they are also connected up and around and over to the same pins of 6J/K and 6H and pins 9-11 and 13-17 or 6M/N and 6L/M. The drawing shows all eight lines converging into a single thick line, but that does not mean they are all connected - it's done to keep from cluttering up the drawing with bunches of parallel lines. At the end of the thick line (on the right side of the drawing) is a notation that indicates which other sheets have chips connected to the bus (sheet 6B in this case). But this bus seems OK, it's just not interfacing with the bus on the other side of the transceiver.

That could mean the control signals are not getting to 5M, but probing them does not show any obvious trouble. Or 5M could simply be bad, but piggybacking a known good LS245 on top of 5M has no effect. That is not a guaranteed method for finding trouble, but as I have no means to test a 74LS245 we'll move on to the BD0-BD7 data bus on the other side of 5M.
 
Last edited:
The notation on sheet 6A tells us that BD0-BD7 also appears on sheet 5A and sheet 9B. Sheet 5A is the Alpha CPU (remember Major Havoc has two CPUs: the alpha and the gamma), and the bus connects to another LS245 at 3R as well as the LS244 at 5R. The notation there also repeats sheet 5A, which is the sheet we're looking at... that's because it also connects to the LS273 at 8M shown in the Alpha Input/Output section of this sheet:
attachment.php

sheet 5A

We'll check both sides of each of these chips, as well as their control signals. If one of them were stuck on or going on at the wrong time - connecting to the data bus when the CPU is not expecting it - it would try to put whatever functions it is in charge of onto the bus. This is called "polluting" the bus or bus "contention" since it competes with the information that the CPU actually asked to be put onto the bus.

The LS245 transceiver chip at 3R is right in the thick of things, as the primary arbiter between the CPU data lines and the BD0-BD7 bus. The control lines are pulsing as they should be, and there is activity on all the lines on the CPU side of the chip. Piggybacking a known good LS245 has no effect. Let's keep going and see if we get lucky somewhere else.

The LS273 at 8M is unlikely to be the culprit, since it is actually a one-way chip (flip-flop) that takes info from the BD0-BD7 side and ("D") copies it over to its outputs ("Q") when a pulse comes in on pin 11. At least that's how a functional chip behaves... who knows how a failed one could behave. Pin 11 is high as it should be (no activity requested) but piggybacking a chip causes the looping RAM test to suddenly pass. The piggybacked chip also begins to get warm, so this surprisingly becomes our leading suspect.

The LS244 at 5R is unlikely for a couple of reasons. It is another one-way chip but this time information does flow from the "A" side onto the bus "Y: side. Its control signals are both high so it is not active. Also, it only interacts with BD0-BD3 so that cuts the odds in half. Finally (though again, not conclusively) piggybacking a chip has no effect.

Checking sheet 9B we find BD0-BD7 goes into the LS374 at 6Q/R and comes out of the LS374 at 6P/Q. Control signals show both chips should be inactive, and there's no change with good chips piggybacked on top. This is for communication with the second CPU, DIPs, quad POKEY and such, and feels unlikely. We'll leave these be given that we have a better suspect in 8M.
 

Attachments

  • Screen Shot 2017-12-11 at 8.51.47 AM.png
    Screen Shot 2017-12-11 at 8.51.47 AM.png
    379 KB · Views: 140
Last edited:
Cutting out 8M allows all the vector RAM and ROM tests to pass. Installed a socket and new LS273 and the game is working!
d473c2d68e05e00bafc866a6b4486873.jpg
 
Not done yet... game ignores the self-test switch, and there is no sparkle for the Major's shield or the maze-through-space walls.

The self-test switch comes to the game board on edge connector finger F, goes past a pull-up resistor and debounce capacitor (so it registers as +5v unless the switch is on and grounding it). Then it goes into pin 3 of the LS257 at 13N, which, when the CPU asks for it, supplies the state of that line (as well as coin R, L and aux, cabinet, and diagstep) to the data bus. Whoops, another connection to the BD bus that I missed. In this case, it's BD4-BD7.

My first thought is that the failure of 8M could have messed up 13N as well. It's behaving differently in that the 8M failure was polluting the bus, while if 13N is at fault it's failing to put its data on the bus. That is certainly possible, but first I'll check the two control signals going into 13N. Pin 1 selects the information on either the A or B incoming lines, and pin 15 enables the chip to connect to the bus and share the data.
 
Pin 1 of the LS257 is pulsing, which is the CPU telling the chip to alternate between using the set of information on the "A" input lines and the "B" input lines. For relatively low speed events like coin drops and self-test switches, this "time sharing" arrangement allows many different bits of information to be carried by a smaller number of wires or data lines. This is known as multiplexing.

Pin 15 is also pulsing, which is the CPU telling the chip to take its turn and present the information from the left side "A" or "B" inputs (according to pin 1) to the "Y" output pins and onto the BD4-BD7 lines.

attachment.php

from sheet 5A

Pin 3 of the chip does indeed go from high to low when the self test switch is flipped, so the switch itself and all the wiring and traces are good up to this point. What should happen is - when conditions (pin 1 and pin 15) are right - the incoming low on pin 3 is momentarily assigned to output pin 4 so BD7 becomes low and the CPU reads a zero for that bit. The memory map on sheet 3B agrees, with a D in the seventh column for address 1200 (address 1200 will trigger /INPUTS alpha to enable the chip via pin 15). If the PLAYER 1 bit is zero, bit 7 at address 1200 represents the right coin switch ("A" input pin 2 of 13N). When PLAYER 1 is set to one, bit 7 will represent the self-test switch ("B" input pin 3).

I'd rather think a bit than desolder, so let's try to be as sure as possible. Grounding pin 2 of the chip does cause the game to register a credit, so the selection of the "A" input and the enabling of the chip is working for that path. Grounding pin 11 tests the "B" inputs and it does register as if Aux Coin were pressed, so we now know the PLAYER 1 signal is toggling and the "A"/"B" input selection is working. The /INPUTS alpha signal is also present and working. We saw activity in these pins, but now we know it was the right activity and timing. Grounding pin 5 registers a left coin drop, and grounding pin 10 is seen as another Aux Coin input. The CABINET and DIAGSTEP inputs are not used by the game, so there is nothing more to poke at.

Breaking out the oscilloscope and probing the output pins 4, 7, 9, and 12 shows activity on all of them (they are half of the data bus after all, even when not under the control of this chip). However, the waveform on pin 4 is different from the other three. Also, monitoring a good output pin (eg pin 7) while toggling one of its inputs (eg pin 5 or 6) causes a change in the waveform (as the information is put onto the data bus). Monitoring pin 4 shows a change when pin 2 is grounded, but not when pin 3 is grounded.
83c1f47f43f273100cda4b8d4e99ef98.jpg
"bad" pin 4
314cac8e8b748ddd7abe78e172e388b9.jpg
"good" pin 7
b4f83d729be5d107fc5523fed43ddb1a.jpg
"good" pin 7 passing logic low to BD7
The top trace is the pulsing on the chip enable pin 15, the bottom trace is the output pin.
 

Attachments

  • Screen Shot 2017-12-12 at 11.31.23 AM.png
    Screen Shot 2017-12-12 at 11.31.23 AM.png
    196.9 KB · Views: 164
Last edited:
...The notation there also repeats sheet 5A, which is the sheet we're looking at... that's because it also connects to the LS273 at 8M shown in the Alpha Input/Output section of this sheet:

sheet 5A

We'll check both sides of each of these chips, as well as their control signals. If one of them were stuck on or going on at the wrong time...

Was there supposed to be a link or picture to sheet 5A here? It's not showing up for me.
 
So it sounds like your down to 3R, 5M, 6Q/R, and 6P/Q as the remaining suspects in the BD7 line having excess data on it?
 
Well a new LS257 did NOT fix it.There seems to be a problem with the PLAYER 1 signal after all, even though it seemed able to allow ground on both pin 10 and 11 to be read (alternating between "A" and "B" inputs). I found this by using the Fluke test script I've been slowly developing. It has a section for testing the address decoding and found that the PLAYER 1 signal pulsed 64 times when the test script only prompts it to pulse 32 times.

Looking at the schematics, PLAYER 1 only appears at output pin 6 of 8M and input pin 1 of 13N. This is confirmed by checking an unpopulated MH board (thanks Tronic!) and following the actual trace across the board. Both chips have been replaced, so the first thing to do is to check that work. The sockets test fine, as do the chips. Time to check the trace for shorts.

Starting at 13N pin 1, the trace goes north under the reset test points and two resistors to a via. On the backside of the board the trace zig zags under the quad POKEY socket and then it gets very close to some other traces as it goes across the board to another via, but they all looks fine. Back on the top side, the trace goes down from near the NVRAM to get next to 8M. Here is runs right alongside a few traces and somehow in the shadow of the gamma CPU socket this has happened:

attachment.php


Testing these neighboring traces reveals they are shorted. I removed what seemed to be a bit of extra solder and self test is now working! In the most annoying of coincidences, that trace turns out to be BD7. That explains how everything else was able to function despite the short: the data bus was only polluted by PLAYER 1 when it was turned on. Plus PLAYER 1 still did its job (selecting "B" inputs of 13N) but it also clobbered the very low it was trying to read (the low of the self-test switch that 13N was trying to put on BD7 was in conflict with the high PLAYER 1 was shorting over to BD7).

Sadly, the sparkle circuit is still not working.
 

Attachments

  • IMG_0207.jpg
    IMG_0207.jpg
    556 KB · Views: 103
Last edited:
Gotta check under all socketed ICs too.
I fixed a MH board once with "screwdriver" damage under a socketed IC.
Those hidden broken traces are difficult to find. Though, in my case, my 9010A gave me some hints. :)

Visual inspection is key.

Hoping you get some "sparkle" soon ...
 
Yeah, I call those 'smudge shorts', and they are annoyingly common on these Atari boards.

Part of it is just due to the trace density, as things are pretty tightly packed in some areas. But the other part of it is the lack of solder mask on the parts side of the boards. I don't know why Atari did this, but it's one of the biggest issues with these boards, as it leads to so many other issues, particularly shorts between traces, and under sockets.

It's very easy if anything gets dragged across the traces for small flakes of solder to break free (or smudge), and make contact with the adjacent trace. In many cases you can see it was due to a tool, screwdriver, etc. But in some cases it's just from storage, or banging boards together, as anything being dragged across the traces can cause it.

And I've seen some that were unbelievably small, seriously almost microscopic. It's just a tiny wisp of solder that flakes off the edge of the trace and bends over to the adjacent one. (Those usually get the 'You've got to be effing kidding me' response, when I finally find them.)

One trick I use for spotting them is to hold the board up to a bright light, and look through the board. This will make them much easier to see, with the light transmitting through the board, versus reflecting off of it. This works for most Atari boards, but probably won't for MH, due to the internal ground planes, but that's one of the few exceptions.

I've seen these so many times that I've made a close physical inspection the first thing I do on all Atari boards, before digging into them (which should be the case for any board, but it's especially true with these, when you know to specifically look for smudge shorts). They're especially prevalent on the busses, where the traces are tightest, and people are more likely to stick tools under the chips.

But anyway, great thread.
 
Hold up to the light? Meh ... LOL :)
Glad I bought one of these awhile ago. Best piece of lab bench equipment for debuggin' boards and soldering etc.

Helps find those small solder wisps too ...

Douglas, you got one of these?

61yjhK1t34L._SL1500_.jpg
 
Yeah, I bought a couple of those microscopes at my last job. They are really nice, and quite affordable. We did a lot of SMD boards, and they were great for soldering small stuff. I could solder just about anything with one of them, and a fine iron (and no caffiene).

I'd totally get one now, but I don't have the space, and the need isn't as great. But they are totally worth it, if you can swing it. I thought they'd be thousands of dollars, but they're more in the hundreds range.
 
Sadly, the sparkle circuit is still not working.

I think you already know that the basis for the sparkle circuitry is just data from the address line being sent to the RGB so it comes out displayed visually.

Is there any of the COLA lines toggling on the inputs of 12J or 12K?
 
Back
Top Bottom