RE: Fluke 9010

> Here is what I get and the
> "correct" checksums"
> Fluke: Normal:
> 3C61 A1A3
> 225B 325D
> FD8B 1C21
>

I just use the Fluke's checksums as that-- Fluke checksums. It's really
best as a "make a record of a good board, save it to tape, and then use it
to check bad ones" tool. I use it as a sort-of a multiprocessor ICE for my
multigame work. VERY handy just being able to go out and read and write
memory-- particularly when you're messing with the memory map. (It's also
very nice to use as a manual-tester for setting registers and whatnot when
troubleshooting.)

The RAM checks are slow-- but they beat the hell out of the memory they're
testing. Full walking bits, edge and column sensitivity test, etc. It's a
thorough check with real access speeds. If it doesn't find bad bits there
probably aren't any...

"Auto" is slow too, but once again it's doing a lot of stuff-- multiple
checks for ROM, RAM, I/O, etc. It does a pretty respectable job, although
large areas of "FF" in ROMs can throw it off. On unknown boards watching
the monitor is pretty educational during bus-test-- easy to see where screen
memory, sprite RAM, etc. is...

The "Bus" test has saved my ass a couple times on the Exidy Multigame
already-- solderpaste had shorted out an address line, but the 9010 caught
it immediately. Same situation on a control line. It the Fluke complains
while doing an operation (like a read or a write to memory) about anything
funny on the bus-- believe it. I ignored it (figuring it was just a glitch)
and lost about two days thinking there was something wrong with my FPGA
until I just hit "bus test" and found the shorted lines...

In general, with most PODs you can tell the Fluke to ignore or respect the
CPU status lines (reset, bus request, bus grant, whatever). My 6809 pod
(for instance) tells me when reset triggers.

I haven't really had any problems with my pods reliability-wise.

-Clay
Received on Sun Nov 28 18:10:38 1999