Re: Asteroids Troubleshooting.

From: Kevin Moore <talon.k_at_gmail.com>
Date: Sun Jan 10 2010 - 18:15:19 EST

Yeah I just kinda figured that out. But I am correct there is a problem on
the MPU side of things right?

No to figure out how to go about T/S that section.

Thanks,

Kevin

On Sun, Jan 10, 2010 at 5:10 PM, Bill <sociableone@gmail.com> wrote:

> You have to get it to play blind with DMAGO lifted first before you can
> tackle the VG side. I socket L6 and have a 74LS42 with pin 1 broken off
> (from lifting pin 1 too may times).
>
>
>
> Bill
>
>
>
>
>
>
> ------------------------------
>
> *From:* owner-vectorlist@vectorlist.org [mailto:
> owner-vectorlist@vectorlist.org] *On Behalf Of *Kevin Moore
> *Sent:* Sunday, January 10, 2010 4:32 PM
> *To:* vectorlist@vectorlist.org
> *Subject:* Re: VECTOR: Asteroids Troubleshooting.
>
>
>
> I just re-read what I wrote. I think I need coffee :)
>
> So it looks like the problem is with the MPU side.
>
> On Sun, Jan 10, 2010 at 4:28 PM, Kevin Moore <talon.k@gmail.com> wrote:
>
> "To determine which section is causing the lock-up, clip and lift pin 10 of
> A-9 (Halt). If pin 40 of the MPU no longer has reset pulses, the problem
> lies in the program section. "
>
> Forgot to mention I did this, the CPU still resets, so that leads me to the
> vector sections.
>
> I isolated pin 1 of L6 to isolate the DMAG0, and it was still resetting.
>
> According to the encyclopedia of Asteroids repair, that means.
>
> "A board that is still resetting has a problem with the MPU and also
> possibly the VSM. Check the ROMS, RAM and especially the 74LS245 (or
> AM83048) at E2 (E3 on Asteroids)."
>
>
> So I've replaced the 74ls245, and I've already checked the Roms, and Ram. I
> think I can rule out the MPU from the previous removal of pin 10 from A-9
> correct?
>
> Which leads me to where I am now. Still trying to figure out what's up with
> the VG section.
>
> Kevin
>
>
>
> On Sun, Jan 10, 2010 at 3:43 PM, Colin Davies <
> colin.w.davies@btopenworld.com> wrote:
>
> Wasn't there a simple way to disable one VG Ready line (or whatever it was)
> - So that the CPU would run blind, and you could determine if the VG was
> faulty or the CPU side of things ? - I'm sure its in the asteroids trouble
> shooting guide on line somewhere....
>
>
>
> Cheers, Colin
>
> ----- Original Message -----
>
> *From:* Kevin Moore <talon.k@gmail.com>
>
> *To:* vectorlist@vectorlist.org
>
> *Sent:* Sunday, January 10, 2010 6:29 PM
>
> *Subject:* VECTOR: Asteroids Troubleshooting.
>
>
>
> I'm still trying to learn all this, so please bare with me. Basically I'm
> trying to figure out the best way to troubleshoot Asteroids boards. It
> shouldn't be as difficult as I'm making it out to be, or is it?
>
> Ok I've got several asteroids boards with the same symtoms.
>
> Test mode comes up good.
> No Ram errors, No rom errors.
> But under normal game play, get constant reset on pin 40of the CPU
>
> Currently just trying to learn how to trouble shoot 1 board, so I haven't
> done all these test on the rest yet.
>
> Have done the following
> Verified Rom sigs with Fluke
> Verified Ram with Fluke
> Verified Bus with Fluke
> Have written the following AVG test program to get + sign with Fluke
> And well I get the + Sign.
>
> WRITE @ 4000 = FF
> WRITE @ 4001 = A3
> WRITE @ 4002 = 00
> WRITE @ 4003 = 02
> WRITE @ 4004 = FF
> WRITE @ 4005 = 97
> WRITE @ 4006 = 00
> WRITE @ 4007 = 90
> WRITE @ 4008 = 00
> WRITE @ 4009 = A2
> WRITE @ 400A = 00
> WRITE @ 400B = 00
> WRITE @ 400C = 00
> WRITE @ 400D = 90
> WRITE @ 400E = FF
> WRITE @ 400F = 33
> WRITE @ 4010 = 00
> WRITE @ 4011 = E0
> DPY-CONFIRM PLUS PATTERN. CONT#
> DPY-+=EXIT%1#
> 0: LABEL 0
> WRITE @ 3000 = 00
> IF REG1 = 25 GOTO 2
> GOTO 0
> 2: LABEL 2
> DPY-##
>
> Went ahead and did sig analysis with the catbox to double check the address
> lines, and data lines.
> Ran Sig analysis on the VG Address selector,and address generator.
>
> I'm assuming since the sigs are good for those two areas, that the VG
> program counter is functioning correctly?
>
> I don't have sigs for the vector generator buffer, I'll have to work on
> that since I have several revision boards, some with R2, and some with P2.
> But I'm getting out what is going in, so I assume the buffer is ok.
>
> So that leaves the VG Memory data latches? Specifically K7, and J7?
>
> Does that sound about right, or am I just not getting it..
>
> Thanks,
>
> Kevin
>
>
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.725 / Virus Database: 270.14.132/2611 - Release Date: 01/10/10
> 01:35:00
>

---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Sun Jan 10 18:15:23 2010

This archive was generated by hypermail 2.1.8 : Tue Jan 12 2010 - 03:50:01 EST