Re: Major Havoc help (was: Vectrex on Vector Monitor?)

I think this is a great question even tho you didn't intend on sending
it to all of us.
I will add some comments after each question below...

Mark Jenison wrote:
> I've been keeping this e-mail around as debugging tips, but I realized that I
> have NO IDEA on how to actually do the things you mention. See my
> question/comments below...

> > What kind of problems are they exhibiting? I've had good luck fixing
> > vector boards just starting at the crystal and tracing through the game
> > with nothing fancier than a logic probe. (A LOT of vector boards are
> > "resurrected" just by replacing a dead crystal, IMHO.) Just step
> > through it logically:
> >
> > Is the clock running? (check crystal and clock on microprocessors)
>

Al has lots of CPU datasheets on spies that you can download as a .pdf
and print out
for reference. The pins are labled and described pretty nicely usually.
I learned how
a 6502 worked without even experimenting just by reading the data for 4
weeks when I
was 14. :-0

Using a logic probe (hook red clip to +5V and black clip to GND). Probe
on the CLK or
OSC pins of the CPU, they should be continuously pulsing and not a
constant level. If
they are constant either trace back to the TTL logic where the clock
signal is coming from
or checkout the crystal. The crystals usually are 'sitting upwards' on
the game PCB and any
force bending it down can destroy the innards even if it looks okay.
Somtimes you can actually
hear glass rattleing around inside.

> > Is the board coming out of reset? (check watchdog outputs and reset
> > pins)

The Reset line is usually pulsed low to reset the CPU and then should
remain high forever unless there
is some sort of powerline noise or if the CPU 'jumps the tracks' (starts
processing bad data). This is
where the watchdog comes in. It has been described in detail on RGVAC if
you do a dejanews search but
basically it will reset the CPU if it isn't 'told' by the CPU the the
CPU is doing things correctly. When
the CPU doesn't 'feed' the watchdog regularly the watchdog will 'bark'
and reset the CPU in hopes of setting
things right. If you have a constantly pulsing reset line, you can look
to the watchdog. But this usually means you have an IC directly on the
CPU data or address bus that is bad. RAM and ROM or those pesky 74LS245
bus transceivers can be the problem here.
  The CPU will not work correctly if the reset line is always low.
Sometimes reset circuits are designed using
electrolytic caps the set the time constant. If the cap is damaged the
reset circuit can just sit there staying logically 'high' or logically
'low' without actually resetting the CPU and getting it running.

> > Does it look like the processor is running? (check datalines and address
> > bus for activity)

Sometimes you can get lucky by probing the data and address lines and
seeing if one is stuck high or low constantly. Things that I have seen
cause this are boards that were removed from the game and stored on a
shelf with others, if something scrapes the board and bends a pin over
or even cuts a trace, you can have address or data lines which are
either shorted to a power supply line or disconnected from the rest of
the IC's. Also check both sides (in and out) of the bus transcievers to
see if the associated input and output look similar.
This is all pretty 'experience' based so it may be difficult to explain
what is a 'good' signal and what is a 'bad' signal, but you are looking
for inactive (not changing) signals here mostly.
 
>
> Which are data lines?
>
> > Is it doing something useful? (see if chip selects on multiple ROMs are
> > occuring)
>
> What/where is chip select?

The Chip Select lines are basically outputs from the address decoding
circuitry. The address decoder watches the address lines and divides it
down into single 'chip select' outputs. If you look at a memory map such
as....

  ROM 1 address F000-FFFF
  ROM 2 address E000-EFFF
  ROM 3 address D000-DFFF
  etc....

Each of these ROM's have a single 'chip select' line that tells it that
the CPU wants it's attention.
ROM 1 in this case has it's chip select line enabled when the CPU wants
info about the addresses between
hexidecimal F000 and FFFF.
The address decoder monitors all 16 address lines and breaks them down
into many indiviual 'chip select' lines that tell all the input and
outputs when the CPU wants their attention. The address decoder does the
job of decoding the hexidecimal info into single outputs for specific
IC's.
>
> > Is the Vector generator running? (check the signals in the vector
> > generator-- "GO, Reset, etc." is it hitting the Vector generator ROM?
> > Is the vector generator ASIC good?)

The CPU and the vector generator have a very nice relationship. The
vector generator only does what the CPU tells it too. Basically, the CPU
loads the vector RAM with all the data to draw all the lines on the
screen. Once the data is all in there, it tells the vector generator to
'go' and start drawing the vectors. When the vector generator is done
drawing it 'halts' and since the CPU is the brains in this operation..
the CPU monitors this 'halt' line. When the vector generator is 'halted'
the CPU knows that it is now safe to start changing all the vector data
in the RAM, if it did this while the vector gen was still running,
things would get messy. The VGGO (vector generator go) and the VGHALT
are probably the two most important lines to watch in the CPU and VG
interaction. If your VGGO line is constantly low then you know that the
vector generator isn't even being told to draw anything and you had
better find out why the CPU isn't telling it to do so. It may be because
the address decoder is screwed up and the VGGO output of it is bad -or-
maybe the CPU has found some other problems (maybe a RAM error) and has
decided that it would not be safe to try and start drawing vector data
with bad RAM (it may try and draw a vector 2 ft. off the side of the
picture tube and roast the monitor). :-(

>
> Huh?
>
> > Are the DACs getting input data?
> > Are the DACs generating output voltages that make sense?

If you see that the VG is getting a VGGO signal from the CPU then it
should logically follow that the vector generator should be drawing
something. Since the DAC's are the method of changing digital data to
analog data this is a great place to check and see if everything is
going okay. The DAC's have 10 (depending on which game it is different)
logic inputs. You can check them with a logic probe to see if they are
changing (getting data) or constant (not getting data). If they are
sitting there inactive, then you can guess that the VG has a problem and
the correct data is not getting transferred to the DAC's. I have seen
VG's do this when the AVG controller IC is bad or if the state machine
PROM has problems. The state machine PROM (stamped with 136002-125 I
think) is another great place to probe for pulsing pins to find problems
but knowing which pin means what is a different story.
  One scenario I found on MH once I thought was interesting...

CPU was running... Reset pulsed low for an instant after power was
applied and stayed high. The clock pins were running smooth as well. The
VGGO signal was also being pulsed telling the vector generator to draw
somthing. But the halt line was constant low. This meant that the vector
generator was being told to draw but it never finished. In fact, by
looking at the DAC pins, it wasn't even trying to draw anything. Hmmmm.
Swapped out the AVG controller (since it is socketed and they have been
failing a lot lately). Still nothing... but wait... the vector
generator needs a clock too. and after some probing with the
schematics.. it was dead. No clock for the vector generator, it surely
won't work without a clock since the clock to CPU's and state machines
is like a heartbeat.
 Major Havoc in particular has two crystals, the one for the CPU was
good but the one for the vector generator was not working. Check all the
crystals. (this problem was generalized a bit for the sake of simplicity
here)

> >
> > I find the majority of problems in the clock circuit, followed by the
> > vector generator (usually after the DAC outputs), and then the program
> > ROMs....
>
> I think this is all good advice in general, but us dummies who don't have
> volumes of computer chip books (I don't even have ONE) could use some herding
> in the right direction...

Al has some really good resources and the schematics are completely
necessary for doing board level repairs. Luckily Al (and some on
Gamearchive) has a good collection online.

Hope this helps a bit.
  jess
Received on Thu Oct 29 17:15:55 1998