Re: 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
>>
>>
>>
>>
>>
>>
>

---------------------------------------------------------------------------
** 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 17:32:18 2010