RE: Tempest resetting problem

> These types of problems would be much easier to fix with the fluke
> unless you want to
> just start swapping RAM chips. Since you have a Fluke this is a good time
> to learn how
> to use it (then you can show me! ;-) I would see if you can write a 0x55
> and 0xAA to the
> RAM locations and make sure they are all okay. Also, maybe you have some
> address decoding
> problems?? Do rule out the 74LS245 RAM buffer either, I had one with a
> bad bit output
> depending on the data it was buffering.
>
Easier than that. Just fire up the Fluke, plug the 6502 pod into the
Tempest 6502 socket, turn on the game (I leave the monitor unplugged), and
hit "RAM LONG" then type in the address range of the RAM on Tempest (should
be on the schematics or in the MAME source code for the Tempest driver).
Hit "Enter" and wait a while. If the Fluke finds a problem it'll bitch at
you. ;-)

Another interesting experiment is to tell the Fluke to "Learn" the board,
and then compare your results with what it finds. It'll do a good job on
CPU visible RAM, but ROM might have some gaps (too many FF's in a row and
the Fluke will decide it's a break in the ROM map). You can then compare
the results (being mindful that the ROMs will probably be split along weird
boundaries) with the Tempest memory map and look for anything goofy. You'll
also be able to kind-of eyeball the memory map from the Fluke without any
other documentation-- if you see a checksum for a ROM are repeat (probably
an even number of times) you most likely have a stuck address line that's
corrupting the memory map...

Have you tried disabling the watchdog and running the game in self-test?
That's been able to point out every bad RAM my Tempests (Tempesti?) have
had...

-Clay
Received on Tue Oct 19 11:04:33 1999