XENON Voice ROM help

sblair

Active member
Joined
Nov 8, 2009
Messages
905
Reaction score
36
Location
Texas
I've got a Xenon pinball that sounds like it may have a bad Voice/Sound ROM. Problem is this game has a lot of them.

Is there any kind of map out there for which Sound/Voice from the Self Test Menu is mapped to which ROM # so I can just order the one(s) I need and not all of them?

Thanks.
Scott
 
Scott:

Been at pins for 11 years and am aware of no such beast. First and foremost, on your sound/speech boards, do any of the ROMS have tarnish on the legs (are any blackened at all)? If so, each chip needs to be gently removed and the legs cleaned with light (400) sandpaper. This is the first step.

If there is no issue there, or this has been done, and gthe problem(s) persist, there's no real roadmap for sound mapping. Sorry.

Chris
 
Good points Chris,

Any other suggestions on best way to diagnose which sound ROM is the issue then? Kills me they put the self test in to listen to each sound clip but then don't tell you which ROM it is stored on.
 
You know, let me dig around a little.

Best case - I'll "disprove my theory" and find some info - long shot.

Worst case - You'll have to "punt"

Possibility - I HAVE a Xenon, and some extra sound and speech boards, I could probably go through your board and do some swapping to figure it out/get you running again.

Chris
 
A couple of ideas...

IF some of the sound ROMs are data-only (no executed code), you could try putting zeroed out versions into the romset in pinMAME to see what ICs affect what sound(s).

IF a local pinball/videogame friend has an EPROM programmer... pull 'em, read 'em, compare to the proper checksums.
 
To that point - again, if you need help - I have an EPROM programmer, if you want to send me the board I can evaluate all of them for checksum, figure out which are bad, burn new ones and replace.

Chris
 
Thanks guys. I was also thinking about swapping the ROM's between locations on this board to maybe figure out which one is bad too.

The PinMAME idea is good though!
 
Bit rot does exist. If you have a burner you could dump the ROM and do a MD5 hash check against a pinmame ROM or simply order new sound ROMS if you don't. ROMS can loose and corrupt data.
 
Bit rot does exist. If you have a burner you could dump the ROM and do a MD5 hash check against a pinmame ROM or simply order new sound ROMS if you don't. ROMS can loose and corrupt data.

I know that. Just don't have a burner and would prefer not to buy 7 programmed ROMs if I only need 1.
 
I know that. Just don't have a burner and would prefer not to buy 7 programmed ROMs if I only need 1.

You're still kind of shooting in the dark anyway. If you're going to be doing this kind of work with any frequency you might want to get a cheap EPROM programmer, eraser and some EPROMs on ebay.

Is there any kind of map out there for which Sound/Voice from the Self Test Menu is mapped to which ROM # so I can just order the one(s) I need and not all of them?

I doubt you'll find anything like that, unfortunately.

EDIT:

Thanks guys. I was also thinking about swapping the ROM's between locations on this board to maybe figure out which one is bad too.

That's not going to work.

Your problem could just as easily be with a socket, the interconnect between the sound boards, etc...
 
Last edited:
There are only a couple sounds that seem affected and there are 7 ROM's to deal with, so I highly doubt the issue is more than a single ROM that is bad and there is a big different in cost between buying 1 ROM and 7.
 
There are only a couple sounds that seem affected and there are 7 ROM's to deal with, so I highly doubt the issue is more than a single ROM that is bad and there is a big different in cost between buying 1 ROM and 7.

What exactly convinces you that your sound problems will be solved by replacing one ROM after doing no troubleshooting whatsoever? Sure your problem may be related to a single ROM going bad, but it could just as easily be a number of other things. Some of which I already mentioned.

Have you tried re-seating the ROMs and the interconnect cable? What do the sockets look like?
 
Last edited:
What exactly convinces you that your sound problems will be solved by replacing one ROM after doing no troubleshooting whatsoever? Sure your problem may be related to a single ROM going bad, but it could just as easily be a number of other things. Some of which I already mentioned. You can be sure that there is sound data that spans more than one ROM. Again, one bad ROM could cause this problem but I see no reason to assume that's the case at this point.

Lindsey, I see you edited the post from your first one saying I have no clue what I'm talking about... I have a degree in Electrical Engineering and 15+ years experience designing embedded systems. Yes, the problem *could* be something besides a failing ROM, but ROMs are known to fail. Identifying which ROM(s) are associated with the issue is the first step in the troubleshooting regardless of whether it is actually the ROM itself or not. As I said before all the sounds/voices appear to be fine except for just a few.
 
Lindsey, I see you edited the post from your first one saying I have no clue what I'm talking about... I have a degree in Electrical Engineering and 15+ years experience designing embedded systems. Yes, the problem *could* be something besides a failing ROM, but ROMs are known to fail. Identifying which ROM(s) are associated with the issue is the first step in the troubleshooting regardless of whether it is actually the ROM itself or not. As I said before all the sounds/voices appear to be fine except for just a few.

You are definitely on the right track. I have a degree in electronics engineering myself, and have been in the PCB manufacturing/assembly realm for many years. I concur with your approach and again, if you need help with the ROMS, let me know, I have a burner and can read checksums/burn new ones if required.

Chris
 
Lindsey, I see you edited the post from your first one saying I have no clue what I'm talking about... I have a degree in Electrical Engineering and 15+ years experience designing embedded systems. Yes, the problem *could* be something besides a failing ROM, but ROMs are known to fail. Identifying which ROM(s) are associated with the issue is the first step in the troubleshooting regardless of whether it is actually the ROM itself or not. As I said before all the sounds/voices appear to be fine except for just a few.

If you're an embedded systems designer then it probably won't kill you have to have $50 EPROM programmer kicking around to solve this little mystery for you. Chances are good the sockets are crap too so it wouldn't hurt to have some of those on hand as well.
 
Is there any kind of map out there for which Sound/Voice from the Self Test Menu is mapped to which ROM # so I can just order the one(s) I need and not all of them?

Originally I thought you could use pinmame in debug mode stepping through the sound test code, looking at the pinmame source and sound board schematics where necessary to create a map. Pinmame will tell you where the code lives in the memory map of the 6802 on the sound board, then you need to look at the address decoding logic on the schematic to figure out which EPROM contains which chunk of memory. Then step through the sound test and see what the CPU is addressing and when.

Then I looked at the vocalizer schematic and realized that Bally used a PROM to do the address decoding (yeah... look at the schematic). That makes it a little tougher to figure out which EPROM is enabled for which chunk of ROM (U1-U8 = 8000-ffff) because you don't know the contents of the PROM. It's still possible, given that you've got the PROM, but reading it could be problematic ;)
 
Scott:

Been at pins for 11 years and am aware of no such beast. First and foremost, on your sound/speech boards, do any of the ROMS have tarnish on the legs (are any blackened at all)? If so, each chip needs to be gently removed and the legs cleaned with light (400) sandpaper. This is the first step.

If there is no issue there, or this has been done, and gthe problem(s) persist, there's no real roadmap for sound mapping. Sorry.

Chris

Just to toss 2cents into this conversation. Don't use sandpaper on your IC legs. If tarnished - use Tarnex as available at most any grocery or drug store. Much safer on the legs and easier & more thorough as well.
 
Hey Ed - no worries, I rtealize it's not a great idea but have been doing it for years. I only use 400 grit or finer. I understand your concern.

Chris
 
If you're an embedded systems designer then it probably won't kill you have to have $50 EPROM programmer kicking around to solve this little mystery for you.

Honestly, the need for one has been very very rare. Everything I design with is all in circuit programmable flash so nothing I deal with professionally requires having one.
 
Honestly, the need for one has been very very rare. Everything I design with is all in circuit programmable flash so nothing I deal with professionally requires having one.

That's pretty much what I figured. Not too many people designing stuff using EPROMs any more, though they're still nice and cheap if you need a big chunk of parallel ROM. Definitely no one doing new 680x processor based designs (other than in VHDL). Modern microcontroller based systems are conceptually very similar to 8-bit pinball systems but physically very different. Working with both makes me appreciate the brilliance in some of these pinball circuits. It also makes me wonder what the hell they were thinking sometimes.

It would be cool if someone could come up with a truth table for the PROM doing the address decoding. Not only would it make developing a sound ROM table easier but it would facilitate designing a PAL/GAL based replacement, though I'm not sure how much demand there would be. If that thing fails you're pretty much screwed. Actually... the best thing a truth table for that PROM would do is make a single EPROM conversion easier which is probably the best solution of all, should that PROM or any of the ROMs fail. The ROM on the vocalizer exists from 8000-ffff in the memory map making it really easy to use a single 27C256 EPROM using A15 as the enable. There's even an unused inverter on the schematic. The trick will be determining in what order the original ROMs need to go in the EPROM. I'm intrigued enough that I'll probably figure that out if I ever get my hands on one of those sound boards.

EDIT: Actually... I designed a PCB that's a 680x series CPU socket daughter board with a 27C512 EPROM and programmable logic for address decoding across the whole bus. This is just another example of where I could use it. Drop it on the vocalizer in the CPU socket replacing all the ROM in one shot. hmmm...
 
Last edited:
Back
Top Bottom