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