But don't forget that there does not have to be a problem with address 0X5000, even if the processor is able to write to this address, it could also be that the problem lies somehwere else, causing the processor loose it's place in the program even before it should do the /WDCLR routine, causing the watchdog to bark...
That is what has been causing the watchdog to bark in all boards that I have fixed.
For example, if, on an Asteroids board, the Vector State Machine does not work properly, it will never tell the processor that it has finished drawing a frame. The processor normally 'sees' that it has finished by monitoring a single bit signal generated by the VSM whenever it has completed drawing what the processor has written in the VSM RAM.
If that signal never occurs, the processor keeps on waiting for it, and never even gets beyond that point, including not resetting the watchdog. The watchdog then correctly tries to reset the processor to get it out of it's 'hanging' state.
What could cause the VSM not to finish:
- The Processor cannot access the VSM RAM or the RAM is bad
- The VSM ROM is bad
- There is a problem in the state machine circuitry
- There is a problem in the data and address paths from/to the VSM RAM/ROM
- The Vector Program Counter does not work properly.
- The CPU and/or VSM address decoders.
Besides that, there can also be a problem in the CPU circuitry itself, thereby not even allowing the CPU to run it's own code properly.
In Asteroids, you can lift the 'DMAGO' signal coming from the CPU's address decoder. This way the VSM never even starts drawing anything. If the watchdog now stops barking, the processor runs the program fine, and the problem is indeed the VSM never finishes when told to start executing (by the DMAGO signal from the processor).
If the watchdog is still barking, the processor itself cannot even run its most basic program and you should look into that (faulty data paths, ROM, RAM, buffers, decoders ect). On Asteroids, it only needs the first ROM and NO RAM to run it's self test.
Kind regards,
Mendel
----- Original Message -----
From: Carlos Santiago
To: vectorlist@vectorlist.org
Sent: Thursday, April 22, 2004 4:25 AM
Subject: Re: VECTOR: Tech: Tempest (not)reset line & WD
Sorry, My previous posting shown here was incorrect. It was based on looking at the schematics for the Asteroids game.
The watchdog generates a reset because a timeout condition has occured.
Normally, the processor will periodicly send a pulse to reset the watch
dog(/WDCLR). If the processor gets hung-up due to a bad instruction from rom
it will not be able to reset the watchdog. When this happens, the watchdog
will expire and pulse the reset line to restart the processor.
A write to hex addrerss 3400 will reset the watch dog. I suspect that maybe
an address (AB9-AB14) is bad. Also check the LS42 decoder L6. To generate
/WDCLR, bits AB9 and AB10 must be high, AB11 must be low. L6 pin 12 must be
low. If you do not find a problem here, then you may have a data bit that is
stuck.
For data problems that keep the processor from writing to address 3400,
hence generating /WDCLR, you may need to look at the rom address and data
bits. Also consider that a buffer may have gone bad which causes the cpu to
get the wrong data. B2 and B3 are the address buffers abd E3 is the data
buffer. Any of these can cause a problem that will keep the processor from
generating /WDCLR.
The key to solving this problem is to figure out why the cpu can not write
to address 3400.
Although the above description is incorrect for a tempest game, the details are the same only the chip location and possibly the types of chips are different. This is because tempest uses custom chips. I do not have the schematics for tempest but I did read the troubleshooting guide.
On tempest, the Watch dog can be cleared by writing to address 5000. If i can get my hands on the schematics, I can provide more detail.
"Mark Shostak" <xx.vl@cinelabs.com> wrote in message news:20040403183101.A18399@cinelabs.com...
On Fri, Apr 02, 2004 at 07:44:08PM -0600, Roger Smith wrote:
> Hi Mark. Thanks for the info. Are the (not)reset circuit and the watchdog
> circuit the same thing? Looking at the schematics I can't figure out where
The reset line is _driven by_ the wd circuit.
> Basically, I looked over the schematics and pinpointed every place that was
> labeled as (not)reset. From what I could tell, this included the
> aforementioned chips along with A4, pin V of the Main edge conn., pin F of
> the Aux edge conn., and and J3 and H4 on the Aux board. I replaced all the
> chips and checked all the traces but nothing has changed. I'm baffled!
Sounds like you're fixing the symptom, not the cause.
> I've still got alot to learn, but I want to see if I can repair this myself.
> Any ideas? Thanks again!
A pulsing reset line is a very common _symptom_, which has many causes.
As such, and being new, READ THE ARCHIVES pertaining to this problem.
Note, you can search for watchdog problems on just about any Atari vector
board, as they were mostly 6502 based and very similar.
Here were some suggestions/questions from the previous email you didn't
respond to:
> >Have you checked your ram?
> >Have you checked your rom?
> >RAM is a common failure, and the cheap sockets on that board give
> >intermittent rom failures.
> >Of course, be sure to reflow the cracked solder joints on the mathbox
> >harness (both ends).
Start with that, let us know what you find, and we'll go from there.
-Mark
>
> Roger
>
>
> >From: Mark Shostak <xx.vl@cinelabs.com>
> >Reply-To: vectorlist@vectorlist.org
> >To: vectorlist@vectorlist.org
> >Subject: Re: VECTOR: Tech: Tempest (not)reset line & WD
> >Date: Thu, 1 Apr 2004 22:35:23 -0600
> >
> >Roger,
> >
> >On Thu, Apr 01, 2004 at 10:03:11PM -0600, Roger Smith wrote:
> > > Around what voltage level should the (not)reset line be at normally and
> >when
> > > the reset button is pressed?
> >
> >When reset is pressed, the !reset signal should be close to (not)zero
> >volts.
> >Technically, anything <.75V is fine. When the button is released and
> >everything
> >is working, !reset should be close to 5V.
> >
> > > Also, I am trying to figure out how to use the disabled watchdog as a
> >tool
> > > when troubleshooting. When I'm looking at the faulty (not)reset circuit
> >with
> > > my logic probe, and the WD is NOT grounded, the entire circuit is
> >barking.
> >
> >Sounds good.
> >
> > > When the WD IS grounded, the circuit is at the correct logic levels for
> >the
> > > most part, with only a small area barking. If I understand correctly,
> > > grounding the WD makes the program run properly for the sake of
> >
> >Not exactly. Grounding the WD disable signal only stops the watchdog from
> >reseting the CPU and the reset of the board (VSM, etc.). It can't make the
> >program run properly, if, say, you have a bad ram, or a bad rom.
> >
> > > troubleshooting, so I'm guessing the area that is still barking even
> >with
> > > the WD disabled is the faulty part of the circuit.
> >
> >I'm not sure what you mean by "area". The only area of the WD circuit you
> >should care about, is the output, and to a lesser extent, the input.
> >
> > > Am I interpreting this correctly? If not, could someone please clear
> >this
> > > up for me? Thanks.
> >
> >Not sure what your actual symptoms are (other than a pulsing reset line).
> >Have you checked your ram?
> >Have you checked your rom?
> >RAM is a common failure, and the cheap sockets on that board give
> >intermittent rom failures.
> >Of course, be sure to reflow the cracked solder joints on the mathbox
> >harness (both ends).
> >Does it self test?
> >Any picture?
> >
> >A pulsing watchdog is a common symptom. Search the archives at
> >vectorlist.org.
> >
> > > Roger
> >
> >-Mark
> >
> >---------------------------------------------------------------------------
> >** Unsubscribe, subscribe, or view the archives at
> >http://www.vectorlist.org
> >** Please direct other questions, comments, or problems to
> >chris@westnet.com
>
> _________________________________________________________________
> Is your PC infected? Get a FREE online computer virus scan from McAfeeŽ
> Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
> ---------------------------------------------------------------------------
> ** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
> ** Please direct other questions, comments, or problems to chris@westnet.com
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Thu Apr 22 04:03:20 2004
This archive was generated by hypermail 2.1.8 : Tue Apr 27 2004 - 19:50:00 EDT