Pole Position PCB problem - watchdogging

[RGP]

I've been looking at the Pole Position board that failed a few weeks ago, it failed with a RAM 73 error (means RAM 7 really, the 3 doesn't get cleared from earlier tests) which is a 2149@7K on the CPU board.

What I see on initial power on is half the screen is garbage, the other half is zero's - I checked in MAME and the screen should be all zero's so something's definitely wrong.

So I decided to make up a test loom tonight and pull the RAM and socket and replace.

No change!

I piggybacked another RAM on the 7K and got the screen to be covered in 4's with RAM 8 now bleeding through that.

I pulled 7J and socketed that and put a new chip in - no change.

So, if its not the RAM chips, is it something before it, like addressing - if the game can't talk to ram properly then it'll definitely report bad right?

Just before we go any further, the Z80 CPU is coming out of reset ok so I know its not watchdogging and I did some messing around in MAME's debugger to track the tests and the ROM test is done first then the RAM then bring the other CPU's alive to start the game.

So I start looking around that section near the RAM 7/RAM8 (7K/7J) area and come back to 2xLS157's at 6K/6J which talk to the address lines on the 2149's.

I figure that I should check the signals coming in and out of the 157's.

I get to the one at 6K and trace the lines, and find pin 7 is just stuck low, pin 7 is Y2 which is going to A4 on the 2149's.

I look at its inputs at 5 and 6 and they are nicely oscillating.

This seems odd - you'd think that A4 would have some activity going on and given that the adjacent gate at pin 9 is changing given that its inputs on pins 10 and 11 are also changing it looks to me like i've found a bad 157.

Ever for belt and braces, I have some 157's on hand and piggyback one - this is a trick i've done previously. Guess what, pin 7 is trying to show some signs of life, LO and HI are both on on my logic probe and pulse is lit up.

The select line on both the 157's is HI.

I'm not certain and I don't want to spend time pulling IC's I don't have to so I get out my next weapon of choice - the logic comparator but here's the confusing bit, it thinks the 157 is fine.

My hunch is its bad, if I push on pin 7 and power off/on I get different garbage in the left half of the screen. I've checked the traces to and from the two RAMs and they're fine, the CS and WE lines are working fine by the looks of it, however, I haven't probed those lines, /SNDCS feeds /WE, both are tied together and half the screen is fine so i'm fairly sure that's not it.

I took some pictures, i'll post tomorrow but if anyone has comments on the 157 i'd appreciate it.

RGP2014-08-17 19:27:38

 

[cmonkey]

Does the board fully boot, even with the ram error, or does it hang on the garbled screen? It just seems odd because the rams @ 7J/7K are the sound rams so I can't imagine they'd be causing a garbled screen?

 

[LukeWells]

The sound CPU (z80) is the master on Pole Pos.

It gets the master reset signal, starts up, checks the ROM and RAM on it's own bus, and sends the reset signals to the two z80002's sequentially, the first z80002 has to boot successfully else the second will not be started.

James, if the comparator thinks the chip is ok, then it probably is, I found it more likely to give a false negative than a false positive.

The thing that you cannot see with your logic probe, is whether there are valid input conditions (2A and 2B) when the chip is selected, all you can see is pulsing, as the inputs are likely shared with other bus items (no schems in front of me sorry) then its possible that the data is being directed to other devices and is not present during a valid address select of the 157 in question. To help with testing, you'd want to inject high speed pulses into both inputs in the hope of "catching" the chip during its selected state and thus be able to test the output

 

[RGP]

No, the board stops at the first sign of trouble in the code - i've taken a leaf from your book and played with the MAME debugger to trace through whats going on.

It performs the ROM test first, then the RAM - the ROM is passing no problems.

The RAM test goes from RAM 0 upwards to RAM 8 - some of the numbers have sub-rams like 20, 21, 22, 23 so its getting passed all those until RAM 7.

Ok, to be clear, RAM 73 was what I saw when it originally crashed, after switching off and withdrawing the board, it no longer shows RAM 73 but some garbage where it *should* write RAM on the screen.

The sequence is this from power on:

40 x 25 screen, vertically split in half, left half showing garbage, right half 99% "0".

The proper boot sequence here is to have "0" everywhere on the screen.

The screen stays like this for about 1 second then clears to blue.

In the upper left area of the screen where "RAM XX" would be written, I have random characters but ONLY where the letters for RAM would appear.

The board halts at this point.

If I "fudge"* the address lines that are going to those chips from the Z80, I can get it to think its passed the test and it brings the other 2 CPU's out of reset and proceeds with the usual partial road and other things you see until it would want to do a sound - normally you hear an explosion.

At which point because something is wrong around the two sound RAMs at 7K/7J it resets again and goes back.

"fudge"* Lets not worry too much about what I mean here - i'm a curious explorer and we're dealing with logic level so grounding or connecting a few logic pins can demonstrate some testable effects - something that's certainly helped on other boards

 

[RGP]

The thing that you cannot see with your logic probe, is whether there are valid input conditions (2A and 2B) when the chip is selected, all you can see is pulsing, as the inputs are likely shared with other bus items (no schems in front of me sorry) then its possible that the data is being directed to other devices and is not present during a valid address select of the 157 in question. To help with testing, you'd want to inject high speed pulses into both inputs in the hope of "catching" the chip during its selected state and thus be able to test the output

Hmmmm, I have no idea how to do that and probably don't have anything that can do it.

What i'm seeing is 2Y just stuck low constantly - in the ideal world this should be changing given that 2A and 2B are changing in the same way that 3A and 3B etc are.

This led me to believe the 157 was not quite right and piggybacked a good one on it, this then started to show 2Y attempting to come to life.

 

[LukeWells]

Logic probe with pulser :-

http://cpc.farnell.com/tenma/72-500/tenma-logic-probe-pulser/dp/IN01196?in_merch=Featured%20Products

Or you can use a signal generator

When you piggy back the 157, bend the 2Y leg up and see if it is pulsing without the chip that is soldered in dragging it down

 

[cmonkey]

Now that the master fixer is on the case I'll slowly withdraw into the shadows.......

 

[RGP]

Now that the master fixer is on the case I'll slowly withdraw into the shadows.......

Do not, all help is appreciated.

Bend the 2Y leg up

I'll try that when I get back in as it'll only take a second to do, if its pulsing...?

I'll order the pulser today as it'll be a useful thing to have.

 

[Equites]

Now that the master fixer is on the case I'll slowly withdraw into the shadows.......

Lol, you can't mess with Luke when it comes to Pole Position.

 

[forcefulfil]

Great work guys!
Love reading these
top class

 

[jengineer]

I too love reading all these repair logs, I just wish I knew what you were all talking about....lol

 

[RGP]

Ok, photo time. Here's the obligatory board on the bench with the test loom tech-porn shot.



Here's where the board stops:



This is immediately after the power on blue screen that should have 0's - it jumps here and halts - note the garbage exactly where RAM XX should sit and no other.



This is after pulling the 2 x 2148's in 7K/7J and socketing and replacing the pair with 2 x 2114's - ok, I "know" the 2114's are slower but for the purposes it would demonstrate that it was indeed RAM 7 and should have moved on even if the timing was off - it would have passed a read test - the code has no timings.

I switched around the 2148's as well and no change - so you can see it moves on a stage.

It does this screen about 50/50 of the time - if I put a single 2114 in 7K and leave a 2148 in 7J it will do this, if I put 2114's in both sockets it does the screen in picture 2, if I put the 2148's in the sockets either way around it does the screen in picture 2.



I tried just piggybacking a 2114 over the 2148 and got the screen in picture 3 which is why I proceeded with pulling the RAM chips - it was the "fight" scenario i've seen before which causes the condition to change.



Now moving on the LS157 at 6J with the stuck pin 7, this picture above is what you get if you piggyback another 157 on top of it but lift pin 7.

With pin 7 (2Y) lifted so its not connecting it is stuck LO with no pulsing if I probe the pin underneath (the original 157) it is pulsing but stuck LO.

I think I need a bit of an explanation of what the pulsing/differentiation is here just so I understand what i'm seeing.

So, in a traditional RGP long-winded answer to Luke's question, its LO with no pulse on pin 7 of the piggybacked 157.

 

[RGP]

TENMA 72-500 Logic pulser arrived today....... Mule.... Spinning wheel comes to mind.

I got the board to halt at the immediate boot garbage i'm talking about:



This is when you power on, before the shots above.

 

[RGP]

Its been a while since I posted on this thread because i've been talking to Luke off-line, however, his time is a bit limited so i'm hoping someone can maybe help get me back on the right track.

Luke was round and helped identify a dead 4584 chip preventing /WDR from working properly, thats been replaced and the dog now barks as it should do.

I was tracing things down and discovered no signal coming from pin 13 on the PAL @ 7C - I messaged Mark @ Retroclinic and he agreed that those PALs do go bad and they are directly in line with where the original battery would have been etc, mine had had its battery removed before I got it so that's not a problem. A new PAL arrived but it turns out this isn't the issue either.

The following is an excerpt from a message I sent out about the state of play on this, no point refactoring it.

I'm using SP218 Sheets 6A, 6B, 7A and 7B which are the only 4 sheets regarding the sound CPU and that batch of circuits.

The 4584 has been replaced and the watchdog is barking - /WDR goes LO/HI transition properly causing /RESET on the Z80 to toggle.

I thought the PAL @ 7C was bad as I wasn't getting any action on the /OE line to 7F - I can see activity going in on pin 2 but just HI constantly for pin 13 which - on pin 1 and pin 12 for A12 through to 7H I have activity. I got a new PAL from Retroclinic but this didn't fix the issue. I lifted pin 13 out of the socket and I can see activity going on in that state so I thought something was pulling it HI constantly - like a shorted track but i've been over that part of the board and no short so it looks like something else causes pin 13 to stay HI.

The following has been checked - including having to pull and socket (i've got very good at clean desoldering now).

LS74 @ 6C

LS161 @ 6A

Z80 @ 7D - tested by substitution

EEPROM 2764 @ 7H - verified as poleposa (Atari set 2)

EEPROM 2732 @ 7F - verified as poleposa (Atari set 2)

PAL @ 7C - replaced by new but old verified as good

6116 @ 7E - tested in my rom reader

LS367 @ 6F - pulled and tested as I thought this wasn't right and you'll see why in a bit.

LS368 @ 6E - tested in circuit via scope - all pins show activity according to TTL data book

LS368 @ 6D - tested same as 6E all good

CUSTOM 08 @ 8H - tested by transposing with the one in column 6 - also scoped all the pins, everything seems good

--- entire sheet 6A tested as good ---

LS157 @ 6K

LS157 @ 6J

Pull-up resistors R57-R60 all good, signals SBAB5-9 going in fine to rams at 7J/7K

LS138 @ 8D

LS259 @ 8E

NB: We believe the 7J/7K probably ok but have spares on hand and no change by substitution

--- entire sheet 6B tested as good ---

Then I moved on to 7B...

LS273 @ 10H

LS174 @ 11H

LS283 @ 10E

LS283 @ 10F

LS174 @ 10D

LS374 @ 10C

Then I got to LS273 @ 10J and found all the inputs were fine but the outputs were inactive - I thought this might have been bad but looked at the /CLSON signal and nothing going on there - now that's supposed to be active LO but if it never state transitions then nothing happens - its permanently LO.

So I jumpered /CLSON to +5 to generate a HI signal - something that's paid off a few times on other boards and wallop i'm seeing output activity but nothing changes on the game itself.

Now this is where i'm getting stuck.....

/CLSON comes from the LS258 at 8E on pin 6 (Q2), however, the G pin on pin 14 never gets the mode set for the Q0-Q7 to ever get any other state other than LO.

G is fed from Y0 of the LS138 at 8D.

Both the 8E and 8D check out good when I pull them and test them out of circuit.

The 138's outputs are set via a combination of G1 and (G2A+G2B) and then A,B and C. A & B are from SBAB8 and SBAB9 - both of which I have signals, I'm not sure what R/W1 is supposed to be.

The interesting thing is that something must be going right there as /WDR is twinkling correctly out of that 138 at Y1 so something must be right there.

The only signal I can't determine is the /IOCNT which comes from the PAL which we know to be good.

ARRRRGGGGHHH.

In case its any use, the /RESET line to the Z80 doesn't hold for very long on power up before going HI.

What am i missing here?

 

[Equites]

James - How did you get on with this?

Sounds like the PCB is firing, but not running code? I know you have eliminated the ROMs, but have you checked the ROM and PROM sockets? These do get flaky on Atari stuff, as matter of course I replace them on all Atari stuff. It has paid dividends in the past (think your Star Wars PCB set).

Regarding RESET line on the Z80, it's fine for it to flip from LO to HI rapidly. It's the 68K CPU that gets a bit confused if it flips too quickly.

 

[RGP]

Hi Nad

That's where I left it from last week, the main issue I can see is that the code in the first EEPROM at 7F $0000-$1ffff is trying to access $2000-$2fff which is in 7H.

Board is not in front of me so I might have those rom locations backwards.

I can see address line activity on all the pins going into both chips and the upper lines on A13 going to the PAL's input pin.

I think the Pin 1->12 , 2->13 just acts as an inverter, however, pin 13 on the PAL is constantly HI when in the socket.

If I lift pin 13 of the PAL out of socket and scope it, I see normal activity the same as I do on pin 12 for addressing. Put the pin back in the socket and it goes constant HI.

I have metered the pin on the socket to ground and there's no short there and pin 13 goes nowhere else on the board other than the /CE pin on the 7F.

My guess is this is what's keeping the board from continuing.

Does anyone have a working Atari Pole Position board they could scope boot activity for me on pin 13 of the PAL @ 7C on the CPU board?

 

[RGP]

Right!

A few minutes more investigation and i've found that i've either got a bad trace or a failing EEPROM

If I lift pin 13 of the PAL @ 7C which is the address select (/CE) for the $2000-$2FFF block at 7F and scope it I have proper activity, if I lift pin 18 out of 7F and jumper the two together with a lead i'm shorted HI still.

I metered out the socket to +5v and pin 12 of 7C is about 38megaOhm and pin 13 is about 17megaOhm.

The continuous voltage at pin 12 is about 2.8v fluctuating, pin 13 is 3.8v constant.

Either:

problem with EEPROM 7F

OR problem with a resistor or cap on that line somewhere causing higher voltage on the line.

OR totally off base and barking up the wrong tree altogether with it crashing before it tries to access that bit of memory.

Last is unlikely because with the epprom disconnected and pin 13 lifted on 7C I have activity.

I did put the 7C back in without the pin 18 of the 7F in socket and its shorted HI there in that condition.

 

[papapopop]

Hi,
you can disable the watchdog as following:

-remove the 74ls161 at 6A and left it empty.

Works fine.

It is only a counter and always set back, in case of overflow

you will have a Z80-Reset.

I did it with several pcbs and all of them work fine.

Bye

 

[RGP]

You can also disable WD by grounding the WD circuit after power on but I can see your approach, i'll try that tonight and see what happens.

 

[papapopop]

Hi,
grounded the WD Circuit , but sometimes this doesn´t work.

When the 161 is bad you always get a RESET.

You also can cut CR4.

I kick the 161 off.

But this doesn´t help you, it is only the WD disabled.

I think your bug is elsewhere, think the Z80 starts

and comes not far enough. But where he hangs up ?

Sometimes I use this:

http://www.tauntek.com/Z80-In-Circuit-Emulator.htm

Therefor I always had to cut off the WD.

Greetings