Re: Speech board idea...

At 09:55 AM 6/26/97 -0500, you wrote:
>> After the 4th of July weekend I should be able to get back to my hobbies.
>> One of the things at the top of the list is to write an Assembler for the
>> Cinematronics CPU. It would make writing test code much easier. Not to
>> mention a menu system for multi-game systems, hacks for current games, and
>> maybe even a new game if someone were so inclined?
>>
>> -Zonn
>>
>
> Yes! That assembler is much needed!

>From past projects I have all the parsing routines needed for parsing any
complexity expression, the basic assembler is a straight forward state
machine, I just need to workout macro logic, since this being a RISC CPU,
macros would be *very* useful.
>
> While I was actually working on diagnostic ROMS (I've kinda scrapped/put
that one on the back burner) I knew I needed an assembler. I was just going
to hack something together in PERL....
>
> If you are going to work on diagnostic/test code, I have a pretty much
complete Verilog model of the CCPU if that will help. I will finish it up
if needed (the only part that is incomplete is the "PROM" page of the
schematics, which contains many labels that are damn near impossible to read
on my copies of the schematics.)

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.

>I also have the necessary "supporting" PERL scripts (i.e. to convert a
BIN/HEX file of the ROMs/PROMs to Verilog memory format, etc.) I made the
Verilog model because I was going to come up with my test vectors/ROMs and
then run the whole CPU, with its test vectors through Verifault and see what
kind of fault coverage I could get. Maybe that was just academic, but it
kinda seemed like a cool idea.

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?

The PC BIOS, on power up, tests the flags of the CPU for proper operation.
I always thought this was lame since after it detects a bad flag it jumps
off into some code that uses the flag to display an error message. If the
flags don't work what the chance of even getting to the test code? This
test make as much sense as my favorite PC BIOS error message: "Keyboard not
found, press any key to continue."

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.

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.

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.

These would help in monitor and sound board repair.

>
> Once that is finished, I can run it through Synopsys and map to FPGAs, so
we can have CCPUs on a chip! Heck, forget about multi-game sound boards, I
can make entire game boards with only about a half dozen chips! (Yes, I
know that the CCPU on an FPGA is by no means an original idea....)

Very cool, and like Ray said in his response, with a couple of DACs and some
glue you could play the games on Asteroid monitors.

-Zonn
Received on Thu Jun 26 10:33:58 1997