Re: Speech board idea...

At 01:48 PM 6/26/97 -0500, you wrote:
>> The RipOff schematic seems to be the cleanest, my copy is water damaged, but
>> the schematics are pretty readable. Let me know and I'll copy a few pages
>> and send them off to ya.
>
> That would be nice. I just need the page that has most of the PROMs on
it. It also has a whole bunch of random logic gates too. I'm sure you know
which page I'm talking about....

Yup. While reverse engineering the thing, that was *THE* page always open,
I just about have it permenantly memorized at this point...

Send me a personal E-mail with your address and I'll send you a copy.

>
>> I've thought of test ROMs for the CPU card and it doesn't seem like there's
>> a whole lot you can do. How do you write software the tests *part* of a CPU?
>
> You get more coverage if you define more controlability and observability
points. You need to isolate those sections from each other.
>
> If you want to get decent coverage on that board, you need a diagnostic
BOARD. If you pull all the socketed chips (LS181s, ROMS, and DIP shunts)
you can get a reasonable amount of controllability/observability. I haven't
looked into this in detail, and probably won't for some time, as I have
basically abandoned this for my sound board project. That was the jist of
what I was going to do, though. If you want to take it over, feel free to
bounce stuff off of me, but I just don't have enough time to do both of
these projects at once.

NOOOOOOOOOO!!!!! [Hands held up in the form of a cross] I have plenty to
do, and for the amount of work I'd put into, I'd be able to fix all the
non-working CPU cards I have and still have time for a nice vacation.
>
> While you can't test individual components, you can isolate some important
sections. Then you have fewer ICs to test by hand, making your repairs much
easier.
>
>> If your verilog model can show that a limited number of usable instructions
>> could possible be run in different failure modes, then writing the software
>> to test these failures would be worthwhile. Ex: I believe you could write a
>> RAM test and flash an output indicating which RAM chip has failed using
>> non-RAM instructions.
>
> I was going to use it to make creating vectors at those controllability
points easier. I was hoping to be able to use some of the ATPG stuff here
to do it for me. You don't really have to use valid instructions, just put
a certain pattern at a controllability point, and check to see if you get
what you expect. You might need to clock the circuit a few times too...

Now your talking the Cinematronics Excersizor. Steve O. has one of these,
you'd be better off getting his working since all the expected signals are
already accounted for and marked on the CPU schematics.
>
>> For the most part the things I've seen die on the CPU card are: The firmware
>> PROMS, and I/O lines -- mostly the outputs include the latches that drive
>> the DACs.
>>
>> I doubt if you could write software the tests for faultly firmware PROMs,
>> but I/O should be pretty easy with a loop back adapter, or an LED board to
>> display the outputs.
>
> Maybe, maybe not. If NONE of your tests pass, that might be an indication
of faulty PROMS. Testing sytems is not an easy thing. You need to sit down
and look at what kind of controllability and observability you have
available to you. I never got around to doing this in real detail. I still
think a set of instructions can be found that can have a reasonable amount
of fault coverage of that processor (maybe 50%) that's just my gut feeling,
and I could be totally wrong.

If nothing works you obviously can't use software to test anything. If you
light up all the outputs by placing LED's on them and one doesn't work,
you've obviously found a bad output. Software testing get grey between
those two points. I spent 2 1/2 years as a hardware test engineer (as a
software engineer writing hardware test code) and know it can be pretty
tricky at times.

And just to be disagreable (since I have no intentions of verifying this ;^)
I think the %50 is a bit too high. There are too many parts on the board
that if they were to die, all software execution would come to a halt. I've
fixed a few of these boards, and the parts I've had to replace (outside of
I/O), would have kept even the first instruction from executing properly.

For those that might be interested I've found the best way to start in on a
non-working CPU card who's reset LED will not go out, is to start at the LED
and trace back all the signals that would hold, or strobe, the processor
into the reset state. Usually you'll find a stuck pin, or in the case of
the PROMs they seem to get into this weird state where there outputs are not
high or low, just toggling around somewhere in between, looking more like a
staircase than a digital signal.

>> Other useful tests are Monitor tests patterns for each of the different
>> types of monitors, include WG's if you're lucky enough to have a Cine->WG
board.
>>
>> And tests for sounding each of the different sounds on all the different
>> sound boards, using a menu and the control panel of the game who's
>> soundboard is being tested.
>
> This should be pretty easy, right? There are separate enable lines for
each sound that goes to the sound board.

Pretty much, many cards need more than 6 channels of I/O data, so latches
and shift registers are used to extended the I/O.

>If you have a working CPU board, a simple stream of intructions can test
each sound in turn.

Yeah I mention those test because they are very doable, just need a nice
assembler.

-Zonn
Received on Thu Jun 26 13:57:10 1997