Re: Speech board idea...

> 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....

> 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.

        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...
 
> 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.

> 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. If you have a working CPU board, a simple stream of intructions can test each sound in turn.

Anyways, back to work....

Joe
Received on Thu Jun 26 11:51:25 1997