Atari Fire Truck. Board repair's...

[smarty]

If you were lucky enough to make it down to the South Coast Slam a few weekends back you might had seem and had a play on my FT cab. Unfortunately when I fired the cab up on the Saturday morning of the show, a graphic fault had developed on the Tail part of the vehicle. A quick re-seat of all socketed IC's didn't help the situation and the show went on and Fire Truck had a graphic fault as shown below. (Horizontal black lines running through what should have been the truck.)

Lines running through the truck graphics.

So it's time to get the schematics out and fix the issue, but first let me step back to the original fault when I turned the cab on after firing it up for the first time... See the image below, the game was not playable, the background was scrolling madly and a constant audio tone was coming out of the speakers.

Original board fault from September 2013

I sent the board to Andrew Welburn (P-Man) who fixed the game and sent through the following diagnosis along with the fully working board.

"

> Your pcb is now fixed... brief fix summary : Address buffer at 1A had a couple of stuck

> bits and was replaced.. the cpu was dead as a doornail and was replaced, the zero page

> ram @ N2 was bad so it was replaced along with a socket install too. There was also a

> loose patch wire on H5 the graphics ram buffer that was rectified.

"




So where did I start with the current issue; Reading the Operation & Service manual confirmed that the tail cab data is stored in two ROMS at positions J5 & L5. These can be read as 2716 ROMS and in my programmer the checksums they gave matched the checksum I generated looking at the MAME rom file in a Hex Editior so these weren't the issue, and I must say I had a good look for dry solder joints before looking into component failure, my initial assumption was that the road journey to the show had caused some of the 35yr old solder to fail...

Fire Trucks Tail circuitry

So testing with my logic probe I confirmed the Address and Data lines were happily pulsing away, the data lines from the two ROMs pass through an LS273 at position M5, again the data was coming out of this pulsing away looking like what I think is OK. I did note that If I shorted and Input pin to Output pin (i.e. 2&3 or 4&5) It would create a similar fault to what I was already there but in a different position on the graphic. Next in line to check was an LS151 at M6 this is where all the ROM data is turned into a single output called TAILVIDEO. The select lines on this chip were pulsing away and none of the data inputs seemed bad so I was a bit stuck...

Hoping for the day that I find a leg on a chip that is dead, stuck low or high, I decided to order an LS273 and an LS151 and try piggybacking them to see if the problem is fixed, first up I piggybacked the LS273 at M5 and it made no change to the fault. BUT I had more luck with the LS151 at M6. Boom upon piggybacking this chip the video fault had gone. YES! I removed the faulty chip, put in a new socket, inserted the chip and the fault was gone. I suspect that one of the Data bits of the LS151 was internally shorted.

It would have been nice to find the exact fault, but I'm happy it only took a few hours in total to get the cab running 100% again. Until the next time...

Fixed! )

 

[cmonkey]

Awesome work dude! Well done

 

[ben76]

Nice job

- ben

 

[guddler]

Well done on the fix!

For future reference, you can't usually get away with "Piggy-Backing" a chip that has tri-state outputs. And to check something like the same for pulsing at the outputs at least won't help as the idea of a tri-state output is to take the outputs to what's called a high impedance state. This means it effectively removes the chip from the bus so it is not seen by and does not interfere with the rest of the circuit. So sadly just because you have activity on the outputs doesn't mean it's the activity of the chip itself, it will likely be the rest of the circuit.

To properly see what's going on with the outputs of a tri-state chip you need more complex tools. Could be a logic analyser or a signature analyser, both tools that allow you to visually see the actual data values at the inputs and compare them to the values at the outputs (sampled at a given time), or it could be something like a scope. In the case of a scope, while you will still see the rest of the circuits activity, a stuck output will make the signal look like it has an unusually strong high (or low) bias.

Sorry, got a bit carried away there but I thought a bit of insight as to why these things are the way they are might be helpful. Obviously in this case it wasn't the 273 anyway.

 

[IDCHAPPY]

Smarty pants

 

[cmonkey]

guddler - colour me confused but I'm pretty sure that the LS273 (and indeed the LS151) doesn't have tri-state outputs? I'm pretty sure its outputs are either clearly defined logic high or low levels. I do agree with you that piggy backing chips with tri-state outputs rarely works though.

 

[guddler]

Haven't looked it up as I'm in the middle of some coding. If it doesn't have tri-state outputs then ignore everything I said

I've never had any luck with piggy-backing them though so just assumed (without looking it up) that 273's were tri-state

 

[smarty]

Thanks for the info re Tri state outputs guddler. I really wanted to find out exactly what the fault was but with a logic probe I couldn't seem to get any further than I did. At least its sorted now so I can move on to some other faulty boards...

Cheers, Mart.

smarty2014-05-08 10:25:53

 

[RGP]

Gotta say I admired this cab at the slam, didn't get to try it out.

Glad you got the fault sorted out, I tend to use a scope and a logic comparator more than a logic probe as I don't have an analyser or signature checker.

Another one up for keeping these awesome machines going.