Re: Tempest resetting problem

I think "Address Decoding" sounds about right. One thing about the Fluke
tests I've doing... I can actually write a bit pattern to ram and I can
read from ram (I always get 0xD7 read back or basically 11010111). What
the fluke *can't* do is write a bit pattern and read it back correctly.
Perhaps there's a stuck bit somewhere? That's probably why the fluke's
LEARN function doesn't see any ram on the board - although it does pass
the BUS test. On a working Tempest (or any working board) - it will detect
all the ram and be able to give you the memory map.

Hmmmm....

Matt

_____________________________________________________________________

On Tue, 19 Oct 1999, Jess Askey wrote:

> When the RAM fails on those atari games you can get some pretty strange results,
> especially if the RAM that is used during the RAM test is bad or the 74LS245 for the
> RAM is flaky.
> On your roomates idea that the CPU will not see the RAM since it is resetting... the
> CPU is actually running quite a while between those resets. One of the first things
> the program does is set up the RAM and test it.
> 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.
>
> One weird thing tho is that the CPU RAM is not being addressed while the Vector RAM is.
> The program should be checking out and using the program RAM right away. Check the address
> decoders maybe.
>
>
> Matt Rossiter - Verio Southern California wrote:
> >
> > Well, I've ruled out the Power Reset and Watchdog counter along with the
> > clock circuit. I used a logic comparator and tested every chip in that
> > circuit and they all test out fine.
> >
> > My roomate seems to disagree with my "it's a ram problem" theory because
> > if the CPU keeps resetting it will never see the ram.
> >
> > I do have a question though. There are 4 2114 ram chips which make up the
> > program ram and about 6 which make up the vector ram. Right? Well, I
> > tried pulling out the roms as suggested below and looked at the chip
> > select pins on the ram chips. All the program ram chips stayed high while
> > all the vector ram chips were pulsing on the chip select line. In fact,
> > they pulsed at about the same frequency as the reset line pulsed. Could
> > there be a clue here? hmmm....
> >
> > By the way - I ordered some of those Braemar tapes for the Fluke 9010a
> > troubleshooter and they are $16 bucks a piece (yes I also know how to use
> > the RS232 interface) and they only sell them in packs of 10. I got them
> > anyway - don't ask me why. Well, whoever can give me a solution that
> > works for this tempest problem will get a free blank tape on me! Oooh
> > Ahhh! You don't even have to pay for shipping.
> >
> > Matt
> >
> > _____________________________________________________________________
> >
> > On Mon, 18 Oct 1999, Chris Loggans wrote:
> >
> > > > ...
> > > >2) I'm not so sure of the ram. My fluke 9010a can't do a read/Write to
> > > >anything in the ram address space (both program ram and color vector
> > > >ram) - so either one of the buffers is bad or a ram chip is bad.
> > >
> > > I think this is your best guess right here. If the Fluke cannot reach the
> > > RAM, then the CPU can't reach the RAM and nothing will work. As you
> > > mentioned, it could be a buffer issue. It could also be a chip select
> > > issue. If this is the case, then either the chip select lines are not
> > > functioning or there is a chip that is stuck "on", regardless of whether or
> > > not is is selected. Even though you know the ROM's are OK, I would remove
> > > all of the ROM's and then try to do the RAM test. If the RAM can now be
> > > reached, then put the ROM's back in one at a time and see when the problem
> > > re-occurs. You should be able to narrow it down from there.
> > >
> > > Good luck,
> > > -Chris
> > >
>
>
Received on Tue Oct 19 10:41:20 1999