This TRON board hates my Fluke

88mph

Well-known member
Joined
Oct 9, 2008
Messages
1,686
Reaction score
58
Location
Sutton, Massachusetts
Ok, here's an interesting scenario:

I have a Fluke 9010 that I have been using on some Tron boards. I have a 3 board set that runs fine apart from some minor sprite issues, so I hook up the Fluke. When I run UUT, the board comes up with RAM and ROM errors from the built in self test on the Tron boardset. (Keep in mind this board was running fine without the Fluke.) Rebooting will randomize the RAM/ROM errors, i.e. they are different every time you reset the board with the pod attached. When I pop out the Fluke pod, and pop the original CPU chip back in, the game runs fine.

The Fluke does fine in self test.

So--I figured it might be a bad 40 pin socket on the Tron board. I figured the Z80 chip was making good contact but the pod was not--this is something I have seen before. I replaced the 40 pin socket with a brand new dual wipe. I stuck a Z80 chip in the socket and the board runs fine. I stick the pod in, and I *still* get random ROM and RAM errors on startup.

Last but not least, and upon consulting with some friends, we thought the speed of the chip might be a factor. So I removed the Z80 chip in my pod and replaced it with the one that was running fine when connected to the Tron boardset. I pop in the pod, power up the board, and it is *still* giving me the same random RAM and ROM errors. This fluke works fine on other Tron boards--no problems whatsoever.

Can anyone think of a scenario in which a CPU will work on a board, but that same CPU will not run that board while it is inside a fluke pod? Is the Fluke pickier about things like clock pulses, etc? I have checked voltages at all the ROM and RAM chips with/without the Fluke connected and they are all within tolerance.
 
Test the pod with a different board. You may have issues with the pod.

The built-in tests don't test all the functions of the pod. There are some CPU signals not checked. Read the documentation for the pod.

RJ
 
This fluke works fine on other Tron boards--no problems whatsoever.
That's good info. Without more information, I'd suspect your z80 pod works and there's something wrong with the board.

Can anyone think of a scenario in which a CPU will work on a board, but that same CPU will not run that board while it is inside a fluke pod?
Sure, the pod adds delay and several inches of bus. Anything marginal could become a problem. Couple ideas:

  • Recheck voltage right at the cpu socket. I'd like to see 5.05v
  • You didn't mention doing this... Use your fluke to run a (long) RAM test and each ROM checksum. Great clue if this passes or fails. Also do the bus test, but this isn't too informative since most of the bus is buffered.
  • Disconnect the SSIO and re-test. Does the failure go away?
  • Replace the z80 on your SSIO. If your pod is working on other tron boards, then it ought to work on this separate bus too.
  • If all else fails, check the addr/data bus (and buffered side) and select lines with your oscilloscope. Sometimes you get lucky and find one line that looks terrible.

I've never had a pod be picky or cause much trouble. Start with the fluke test and see if it can read/write reliably.
 
Thanks for the tips. I did do the bus test, which was fine. I will do another voltage check and will run some of the more comprehensive RAM/ROM tests and let you know what I come up with.

Last night I did compare the clock signals on a 'pod friendly' and 'pod angry' Tron CPU, and they were identical. I'll put the scope on the other lines and compare to see what kind of signals I am getting.

It's funny--I am using an older TEK analog scope at home, and the camera on my Iphone doubles as a great way of 'storing' traces for comparison. :)

-Jude
 
Here's a memory map: http://www.coinop.org/kb_dl.aspx/KB/gametech/tronmap.html

But more useful, this site has the 9010A signatures assuming you're running a known ROM set: http://tech.quarterarcade.com/tech/game.aspx?g=3188

Finally every fluke owner seen this one but I'll link it: http://tech.quarterarcade.com/tech/Fluke/9010A/

Run the RAM test and ROM signature run several times (or let them loop for an hour) and see if they ever fail. This sort of test is a great chance to probe with the oscope too. My last repair had a data line hovering near 3v because a chip had a stuck-on output. Don't sweat the little things -- everything on my Kick looked pretty ragged, even working perfectly.
 
Ok, I have done some more extensive testing. First off, I did the full self test of the pod as outlined in the Z80 manual. (This is the one that has you set up a socket adapter with no pin 29, so the Z80 pod can simulate a UUT.) Bus tests, reading, and writing all went fine. The 'normal' self test still comes up ok. According to the procedure in the manual, the pod is good. I also hit the things recommended above:

  • Recheck voltage right at the cpu socket. I'd like to see 5.05v

    I have 5.05V. The voltages on all the buffer chips attached to the CPU are the same.
  • You didn't mention doing this... Use your fluke to run a (long) RAM test and each ROM checksum. Great clue if this passes or fails. Also do the bus test, but this isn't too informative since most of the bus is buffered.

    The bus test is good on both boards.

    The RAM test on my 'good' board gives me one solitary error--a DCD error at C000. (This is a repeatable error.) The RAM test on my 'fluke hating' board is riddled with numerous DCD errors here and there throughout the entire range of the RAM.

    The ROMs on my 'good' board test out fine. On my 'fluke hating' board, the ROM tests fail. If you repeat the same ROM test over and over, you get random checksums.

    I did a good amount of individual reading/writing checks but was never able to get an error or an inconsistency on one of those. These events were loooped, so we're talking about thousands of events without error. I broke out the fluke probe, synced it up and started checking out the individual bits on the address bus and the data buss; so far so good on the buses. I typically read or write a single address and loop the event, so I can look for the address/data across the appropriate bus. (I still need to do some more testing here.)
  • Disconnect the SSIO and re-test. Does the failure go away?

    This did not make the failure go away.
  • If all else fails, check the addr/data bus (and buffered side) and select lines with your oscilloscope. Sometimes you get lucky and find one line that looks terrible.

    I still need to check this out. I will probably sync up the scope to the trigger out on the fluke and see if anything looks ratty..

Once in a blue moon, the fluke hating board (with fluke attached) will boot to a screen where it actually draws some of the MCP cone, and then freezes up... this points to a problem that is at times intermittent. But usually, it's just junk screens or RAM/ROM error messages. As always, if you pop out the pod and slap a Z80 in there, it works perfectly... and the pod still works fine in other Tron boards.

p.s. thanks for the memory map!
 
Last edited:
The RAM test on my 'fluke hating' board is riddled with numerous DCD errors here and there throughout the entire range of the RAM.
The ROMs on my 'good' board test out fine. On my 'fluke hating' board, the ROM tests fail. If you repeat the same ROM test over and over, you get random checksums.
I can't find the DCD acronym in my manual but neither of those results sounds acceptable. I might've guessed a (ram or eprom) that isn't rated for the correct speed, but if they're all failing then a bus fault seems more likely. And finally since we're thinking of speed -- is the clock at the correct frequency, maybe it's running too fast?

I did a good amount of individual reading/writing checks but was never able to get an error or an inconsistency on one of those.
The individual locations won't flog the bus quite as badly because it's the same value each time. All lines wiggle much more during ram/rom tests.

I will probably sync up the scope to the trigger out on the fluke and see if anything looks ratty.
Sounds cool, I've never used the trigger feature. Maybe you can run the RAM test, generate a trigger on failure, and capture what it's doing? My wild guess is you have a rare select line problem (two at once? sluggish?) or one of the bits on the buffered addr/data is having trouble. So if you can't find it, there are only a few chips worth shotgunning.

The main cpu bus goes over to the video board right? You might try swapping video boards to ensure that the problem is on the main cpu board, and that it doesn't follow the video board. That may further-refine which PCB has the failure.
 
The clock is something I was considering earlier. I ended up looking at the clock traces on my good and fluke hating CPUs, and they were essentially identical. I will take another look at it to make sure that they both aren't fast though... The types of errors I am getting certainly seem like the kind you could get from mismatched speeds.

I don't think RAM speed is an issue, as I can swap my RAM chips from one board to another and the fluke problem doesn't follow the RAM.

Regarding the video board--the way I am testing these CPU boards is putting them on a bench with known working sound and video boards. The CPU board is the only board I am swapping. Both CPUs work fine with a Z80 installed, but only one will run UUT on the pod.... so I am pretty sure that isolates the problem to the CPU board.

You have given me some food for though here though.. I'll see what I can do to isolate/troubleshoot the select lines. I think I am definitely dealing with some sort of intermittent bus error (either data or address) that is somehow getting exacerbated by the more comprehensive RAM and ROM tests. I guess the RAM/ROM tests are a pretty good surrogate for the board booting up..

Thanks for your help--I'll let you know if I make any progress on this.
 
You should probably simplify the bus. Decide if you want to focus on the RAM or ROM test. The RAM/ROM are socketed so remove all but the one you're testing. 74ls245 (F4?) connects data to buffer-data. You don't need this to check ROM/RAM so install a socket and test with the chip removed.

See if your problem goes away. If not, you have way fewer things in-circuit that could possibly affect the bus.
 
88mph - What's the latest on this issue? Did you ever figure out why the Fluke didn't work on that board?

LeChuck
 
Back
Top Bottom