I encountered this on my Dad's Meteor. It was working fine with a matched pair of 5101 SRAM and coin battery. This was an early MPU200 board with four masked ROMs. When installing NVRAM one audit would not save correctly and always revert to the same junk value. Also the spinner sound among a few other sound effects was wrong. This is the identical issue that comes up when you use two 5101s of a mismatched speed... IE a U8 is 150ns rated and U13 250ns.

The fix for my Dad's meteor was to change the MPU from four masked roms to two M2732A EPROMs the issue resolved itself. Other people have told me changing to 2732 ROMs also fixed this issue that can happen after installing NVRAM.

I think the problem relates to this
http://www.pinwiki.com/wiki/index.php?title=Bally/Stern#Schematic_Errors_with_Stern_MPU-200_MPU

which was fixed on later boards with a blue jumper on top side and then later on the PCB was fixed (i think?).

My replacement MPU using the same FM16W08 chip is fine in meteor. It is triggered a little differently tho.

It was the stock ROM but it shouldn't matter if using the bug fix rom as they are different issues that are not related as far as I know.

The "bug fix" is a software issue for the when the bonus multiplier value is allowed to roll backwards from zero to 255 in resulting in a 255x bonus countdown which feels like forever.

The sound issue is feels more like a hardware problem of the 5101 not being accessed properly that I speculate is related pinwiki fix link in my first reply. Stuff related to the sound must get written in the NVRAM. I say this because if you can take a NVRAM module. Write junk data to it, like leave the neoloch test pattern on it. Put that NVRAM module into a MPU200 game. Go into test mode BEFORE starting a game. The sound test is "funny" and not the normal tones. Once you start a game. THEN go into test mode. Sound test is back to normal. So when the game begins for the first time it must make up some data for the sound board that is saved in the (NV)RAM.

As a side note, potentially related -

The 'original' 7-digit ROM (unversioned number) used a hacked way of handling the additional digit. This caused the display routine to suck up a lot more cycles than was necessary. (The v24 version is based off of Stern's 7-digit OS.) But - because of the different times needed in the display interrupt (which happens quite often), this will cause sounds and speed of the game to be noticeably different. I didn't notice it affect gameplay, but it's possible that if the display interrupt timer is too quick (say, quicker than my MPU-200 was), it could start to cause other things to fail.

Oh, and the Bonus 255x issue was a RAM mapping error. The ROMs labeled 'Alt' on IPDB was Stern's fix for it. v24 does *NOT* have this fix in it.

Ran into this issue last month. Customer's meteor produced drastically wrong sound effects when using any NVRAM in any of the positions. Initially had installed the 2-in-1 NVRAM. Tried it with 2 individual NVRAM as well as 1 stock RAM and 1 NVRAM in both possible combinations. All produced the sound error. Ended up putting the stock RAM and battery holder back in and went back to normal. Have not tried again.

Alltek boards always have to have the system clear mode used (dip setting) for meteor even if it's the first use fresh out of the box before the sounds are correct. I've experienced this a few times, spinner is especially noticeable because it seems as if the board doesn't keep up with the spinner. Once you do the system clear, turn off then reset dip for meteor then all is good.

Four masked ROMs? If so it should work with two EPROMs instead. Also could try the VUA vs VUA-Q2 differences that is in the triggering of the NVRAM chip select.

Maybe I will find some time and grab my dad's meteor board and tinker with it. I bet if I go back to four masked PROMs the sound issue comes back... I also think if I change the NVRAM CS triggering to be like later boards it will also fix it.

pasted_image (resized).png

The four masked PROMs had the same code on them as the two m2732a EPROMs so I don't think its a software issue. Using four masked PROMs vs two 2732 changes the some of the triggering. Perhaps it is a timing issue since the same effect of bad spinner sound can be achieved by using two different speeds of 5101 RAMs. Also seems kind of strange the 5101s need to be the fast type for relatively slow clock speed. Perhaps the propagation through all the 4000 series requires the fast 5101s.

As far as the 5101/nvram triggering I think the original mpu200 design had the error which in most cases did not cause a problem with 5101 SRAMs. Stern identified there was a problem and started adding the blue jumper wire to boards during or sometime after or during meteor. Past that the MPU board was changed per the pinwiki picture. Users that do not have a sound problem in meteor with NVRAM probably have the fixed MPU200 board either with the blue jumper wire or a PCB where the layout was changed for the fix.

Here is a mpu200 made in 1980. This board has continuity where the factory blue wire fix normally is so should be a later mpu200 with the fix.

I looked and couldn't find any early mpu200 around my place. Can anyone post the same area of a meteor pcb that acts up with nvram to see what is different? Next time I am at my dad's house I will look at that early meteor board.

20190228_155209 (resized).jpg

20190228_155221 (resized).jpg

I just dug up some facebook communication I had with someone that fixes boards.

1/27/2017

Him: Any thought on a Stern mpu200 with a SB300 sound board not liking NVRam? Someone said you may have posted on this in the past

Me: Yeah. I have ran into it once with a meteor. 5101 sram worked fine. With nvram, the sound effects where off. Quite similar to the effect of using two different speeds of 5101 srams. It is a timing issue of some sort. In my case, changing from four masked roms to two 2732 eproms solved it.

Him: Interesting. Same game. I'll try changing it to 2732s.
Him: That fixed it. Thanks

Dumb question, but the 4x MASK vs 2x EPROMS, could it be a voltage issue?
Could the additional load on one or any of the lines be preventing an address or data line from getting high enough (current draw) for the NVRAM to see it, but is high enough for the SRAM to recognize it as a HIGH?

Why not upgrade to 7 digit displays? You could get the pinitech unos relatively cheaply.

It likely would not be too hard to put the 1a fix into the /10 romset as long as the /10 romset doesn't happen to modify the same rom. You could probably just put it in there - it would be a self-contained fix since it's not different in the factory set for u2 u5 and u6.

By coincidence, I (now) have the meteor sound issue described and most likely I have an early revision mpu200 in there so I can try the jumper fix tomorrow. I did not have the issue for years, though. It would be meaningless to describe what software I have in it though since it's a custom rolled homebrew (which does have the bugfix for the collect all rockets, although I left it reporting the version as 24 - probably should have incremented it. My version control methods left a lot to be desired in the past decade or so....I now keep diffs of all compilations and TRY to maintain a changelog....)

The thing that is odd is that it has been working completely flawlessly for years, nothing has changed in the machine. Moved it from one area of the room to another is it, it still worked in the new area but I was away for a while and cleaned off/turned on the machines for a mini party last weekend and now have the issue. Strange.

I think I have Andrew's (weebly's) nvram in there but it could be Wayne's (pinitech) - I've bought both in the past. I'll see if the non resetting audit is an issue, although I think I repurposed the last audit to use as a game rom variable instead. I have a couple of Andrew's MPU boards as well and will try those if the jumper doesn't work. It definitely didn't change with a new ribbon cable, a recapping of the sound board, or even borrowing the sound board from my working seawitch (I really should have done that first before recapping and building a new cable....)

So, the board I had in there already had the wire mod done, so that's not helping it. Now that I'm looking into it further, Stern did make a change in the way the sound board is controlled between the first three games and Big Game - as the software I currently have in my Meteor is the Big Game operating system (for the native 7 digit stuff instead of the earlier hack type stuff where it was grafted into the 6 digit software) - *BUT* the Meteor sound scripts play at the wrong frequency if you use the sound code in Big Game - so I reverted that part of the OS back to the original timing.

None of which explains why it was working fine and stopped working from a simple move from one part of the basement to another. Oh, I also pulled out the Weebly ram module in there and stuck in the Pinitech ones and same result so still NVram issues. I'm about to stick the software onto a 512 chip and put it on a newer revision Weebly mpu to see what the results are there I suspect it will work fine so I'll probably just leave that board in the game.

I know that NVRam can be subject to leveling issues I wonder if it will 'go bad' and it was just its time? Or if access time slows up as blocks are moved around (with whatever internal leveling algorithm they're using)? I would think it would have to be extreme though as we're talking modern NVram vs. the expected access time for the 1979 vintage mpu board. Just very speculative thinking, with nothing from datasheets to back it up.

OK, put the same exact software (I copied it off the 2732's from the mpu200) formatted into the 512 socket on the weebly board and it works fine. I think I'll just leave it at that, although producing modified software that won't work in the original mpu200 isn't really something I'd be a fan of. Unless I figure out how to re-format the sounds from meteor into what the big game OS expects, which won't happen unless I can figure out how to create sounds on an sb-300, then I think the testing is done for now, to be put into the 'I wonder why this doesn't work?' category - which is kind of a huge file at this point....

But I think I can say that putting in 2x2732 eproms into the mpu200 is not the solution.... it's really strange since it used to work fine. I might try to stick 5101s back in there.

Oh, the other thing that was kind of strange is that it didn't let me clear a couple of the audits when I went through them... that might be some kind of bug in my code though vs. something more serious.

These NVRAMs don't support wear leveling. FYI but unrelated to your problem below are the endurance specs of some FRAM chips.
There's also a difference in how the Chip Enable signal works with these FRAM chips (edge triggered latches address vs level state for standard RAM). But that doesn't explain why your game worked and then suddenly didn't.

Is there any low level timing you can tweak on the Meteor sound playback routine? If it heavily uses RAM in $200-$2FF range can you move any of it to the 6810?

FM16W08_Endurance.png

It certainly would, since the interrupt is where the sound data is actually stuffed to the sound board.

It heavily uses ram in the $2f4-$2ff range - that's where it stores the script pointers for the sounds and the registers. There's a ton of stuff they do in the 5101's from $200-$2ff - including the stack. If there was an issue here, it would be pretty specific to the top of the block as anything with the stack would crash the game almost immediately.

I'd say more on the timing end - I'm going to stick the board into some of my other stern games with their respective romsets in them and see if it messes up. Most telling would probably be Galaxy since it's the same code. The edge trigger vs. level timing might have been relevant, but I think we'd see a stack crash almost immediately if this were the case.

I know you said the Big Game OS sound code plays the wrong frequencies with the Meteor sound scripts, but do the wrong frequencies match between your MPU-200 board and @barakandl's MPU board? - i.e. with Meteor sound scripts, does Big Games sound code give consistent results across boards opposed to Meteor sound code giving different results?

Also keep in mind you can replicate the identical issue with NVRAM in meteor by using slow 5101s or mis matching speeds of a 5101s. Same sound problem and same audit problems.

Small changes in the CPU clock speed seem to effect the sound board sounds. You can sit two identical MPU200 games with the same hardware in each next to each other and they usually sound a little different than each other. Years back i bought some soviet cloned 6800 CM601P chips and noticed they even made pitch changes to the sound board when swapped in versus a moto 6800.

If its a timing thing I wonder if all the 4000 series gates and maybe the earliest MPUs used slow 74L which has a 3x longer gate delay than 74LS. The boards I make is all HC(T) logic chips for the most part. For my MPU the chip select the for RAM more like the Bally MPU with VUA+Q2 instead of just VUA at U17C

So put the big game sound routine back in, and use the meteor sound scripts again onto Andrew's board to see if it's the same as the mpu200 results? I should also remove some mpu200's from my later games (I have one out of f2k right now as that's slated for Andrew's board for a complete rewrite can probably try that one.... that one has a 6116 replacement NVRam using the old pinforge directions.....with lots of jumper wires for a 27256 config ala OliverK's) - could probably try that out.

I have had slow 5101's (-450 ns) ones in meteor before, and IIRC, they didn't work.... had to go with <300. Forget what the phillips ones were I think -100 but I had a lot of other issues with those going dead (seemed to be even more sensitive to static than others).

The sounds are close enough swapping the board in last night - I'll try out that credit up sound thing you described on the first boot up, that seems really odd.

On a tangential note, do you ever run into issues with people using your -35 to -200 upgrade kit with the sound? Might provide a clue there.

I should hook up my Rigol scope and get some actual information out here. I need a 2 month holiday to play around with all these projects!!

No problems with the -35 to mpu200 kit that has been reported to me. Its not a very popular item tho. I tried it in at least four games myself and never any trouble. I am pretty sure I tested it OK in a Meteor as well. Maybe slight differences in pitch of sound effects vs the original MPU200 board that was replaced, but within the normal range expected by original and aftermarket boards and not like Meteor where it is wrong sounds entirely.

Phillips 5101s where pretty good to me. I think they where 150ns. I bought big lot of used pulls of them maybe 6-8 years back and never had much trouble with them. When I was fixing original boards dead 5101s in general was really really common.... even beyond the corrosion thing.

Yes, I'm curious if the Big Game OS sound code has some timing improvements/fixes over Meteors OS sound code. ie. do both your MPU-200 and @Barakandl's MPU then produce the same or different sounds using the same Big Game OS sound code with Meteor sound scripts.

Hah! after 2 months holiday you'll need another 6 months for the new projects you've come up with!

So was just playing seawitch.... which has been working flawlessly re: the sounds just like Meteor was (on Saturday) - today, the 'noise' channel dropped (the kapow sound at match and target bank bonus completion, and the background sound as well). Same type nvram in the game although I didn't check yet for the factory mod wire to see what version of the mpu200 I have in there.

This time, a simple reboot 'fixed' this.... but it does make me wonder if it's related.

What do you think I should stick the scope probes onto to see what the timing differences are between nvram and 5101's? I'm thinking E, R/W, CS1, OD. I'll try triggering on each of those since I don't know which one would be 'first'.... and this will be new to me since I've never owned/used a triggering scope before (I picked up a rigol 4 channel 50mhz a month or so ago) - or if a logic analyzer (I have one of those USB 8 channel ones assuming I can find it....) if that might be better since I can monitor more lines.

Can you try modifying the MPU board by changing the (hardwired on the back) jumper E37-E38 to E37-E36?
I'd almost be inclined to try pulling the data bus high using 10k resistors maybe even at the J5 connector on the MPU board or at the SB300 itself.

Do you have the factory ribbon cable or aftermarket cable between the MPU board and the SB300 sound board?

Do you have any of @Barakandl's SB300 sound boards to try?

BTW what about brand of 6800 CPU chip? Can you try another brand?

It seems the FRAM is affecting the address/data/control bus in an unexpected way that's causing an issue with the way the sound board is accessed, i.e. if the issue was relating to how the FRAM was being accessed, I'd expect more than sound issues like the game ultimately crashing with invalid data all over the place from FRAM.

Both factory ribbon cables and one that I made up specifically to test this issue. All of them work great with Andrew's MPU board, and in other games with mpu200 and sb300 combos.

I do not have any of Andrew's sound boards I probably should get at least one.

Pretty sure all my cpu chips are motorolas... no AMIs in there.

I don't think the data out of the FRAM is an issue because all the mpu200 games use it for the stack. The game would crash in short order on any errors, and it just doesn't. The sound is just messed up.

I wonder if the data from the FRAM needs to be buffered in some way - it's working fine on the mpu board, but the travel time over to the sound board is causing a drop out. I should really dig out that logic analyzer and put a test rom in there that just plays a single sound over and over and compare all the results.

I think we already know that the sb300 is dropping <something> and the mpu program isn't, based on the survival of the game running. There's no noise suppression between J5 and the sb300 is there? (caps I would assume like the switch matrix/other PIA in/out puts has).

I can probably tell that right away as well if I just drag the scope out and hook it up. So, so, so very busy. Or, probably more accurately, lazy! I'll see if I can get near it this weekend. I did actually FIND the scope (actually, literally tripped over it....) as it ended up in the 'clean stuff off for a party' desperation aisle.

Agreed, it's not a problem with data going in/out of the FRAM. It's the effect of the FRAM on the bus.

Andrew uses Hitachi CPUs on his board. Have you got any AMI/Fairchild/other 6800 CPU to try?

No. In an ideal world that 30cm loose cable running the address/data/clock bus isn't a great idea, on top of that the SB300 doesn't have any termination. I wonder if a shorter cable would help.

If you're going to pull out the logic analyser, I'd probably hook it up at the SB300 to see the difference in bus signal performance of FRAM vs 5101 RAM.

Have you tried this yet? The E37-E38 connection is traced on the back of the board. It needs to be cut so you can jumper E37-E36.

MPU200_DataBus.jpg

Why would they have used the enable signal between E37-E38 into pullups? That doesn't really make sense does it? Or is that something for masked roms vs. eproms.

(Masked roms! I remember those.... I'm 100% sure I have none of those anywhere in any of my games....)

I don't think the logic analyzer will help on the sb300 unless there's some data missing, the output from it is not scope like - the software implies that everything is a supernice square wave. Also, I haven't run across where I stashed it yet but I did find the scope. I might have some time today to play with it (if I don't give into temptation to keep playing with Stars' code....)

The image on the top is Andrew's board just with the data bus D7 signal (since it's all the way on the right of J5 and easy to get the probe on) without the sound board hooked up. Pretty typical each time I ran/stopped it. (this is in attract mode). There were no tiny voltage spikes unless I just had bad luck stopping the signal randomly.

The image on the bottom is the MPU200 board in question, with 2xNVrams on it. Again, typical results but I did go out of my way to capture tiny spikes in the signal which may or may not be relevant, because when I pulled those NVrams out and put in 2xpihillips 5101's I had laying around (I really had to dig for those because I tossed most of my 5101s into a couple different places, and these were the 1st ones I found - they turned out to be good so there's that.)

I verified that the game played the sound correctly with those 2x5101's - I forgot to save the waveform with the 5101's in there, but it looked the same as the 2xnvram, with some tiny spikes in there.

The sound being messed up is all sounds except for the background sound - not just the spinner sound. This issue might be related to the software difference though, as it's built on top of the big game raw OS but with the Meteor sound routine in the IRQ grafted in.

I'll have to look on the sb300 itself to see what signals to probe there... I see the 6840 enable is tied to the o2 signal.

I'll also have to look through my board stock to see what else I can toss in there and see if it works - I know I have a working mpu200 with the old forge site's 6116 nv replacement mod on it and I probably have several other stock mpu200's (especially since I plan on replacing all those with Andrew's mpu boards anyway) to play with. I'll try and find one that is the later revision so that I don't have to worry about swapping the components back and forth so much.

I think the goal I have in mind is just documenting what all the differences actually are, with testing the sounds to see if whatever revision works.... then I guess seeing if applying the difference to the early board fixes the sound or not.

The thing that's really bugging me is that it was working 100% before a couple weeks ago.
NewFile1 (resized).pngNewFile2 (resized).png

Not sure but it's not for ROMs. If you look at the Bally schematic, only 4 data lines have that enable signal pullup setup which are the data lines going to the 5101. The other data lines not connected to the 5101 have pullup resistors connected to 5 volts so that's the reason to test the E37-E36 jumper setup since you're not using 5101 RAM chips.

MPU_Bally_5101_Pullups.jpg

Do you also ever see those rounded front edges on data line 7 on the MPU200 board?

Andrews board shows the data line going to 5 volts for a logic high. The MPU200 shows the data line going to about 3 volts for a logic high. This is below spec for a logic high at CMOS chips (powered by 5 volts). The SB300 has the data lines going into two 4042 CMOS chips at U14 and U15.

I can answer the pullup question for the bally board - it's the low nibble d0-d3 that's always $F on bally boards (so that software written on bally to inc $253 for instance will always increment the most significant nibble, but the same software on an mpu200 will generate an error since you'd have to inc it the full 16 nibbles to increment the upper nibble. Most of the software I've looked at both bally and stern it's programmed 'correctly' in that it's not assuming the nibble is always high, but eight ball deluxe, that era and up seems to take advantage of this programming shortcut. (Not good practice IMO, but I understand they were trying to shoehorn stuff into a very small footprint and took whatever optimizations they could get).

I don't think there were rounded edges on the mpu200 board at all, but clearly 3 volts isn't enough. I will get together some more mpu200 boards and try them out to compare and hopefully remember to save the waveforms this time.

I guess the 36-37 is to provide pullup for the data bus going to J5 - I'll modify the one board later today and take a pic of the jumper wire. I'll have to start pulling other boards out but I'll have to get it together and start burning some 512's for them for the upgrades. Thanks to my notoriously sloppy version control, I'll have to pull the roms to compare to 'what i have' to make sure I'm compiling some kind of untested version. I do now keep all the updates in an archive folder, but it's not always clear what's IN that version.

To be honest, I'd find it hard to believe this was by design, rather it was an accidental byproduct that Bally later realised they could exploit. The early Bally games didn't use the 5101 for arithmetic data.

Having data lines (and address lines too for that matter) pulled high is nothing unusual and I've seen it in other CPU circuits. I don't quite get why D4 - D7 are only pulled high via the VUA-Ø2 signal - again the importance is that they're the only data lines which the 5101 is connected to.

I wonder if it's a timing issue requirement.... I know the cpu cycle can be kind of a bear if you were designing a board since certain operations need to occur within timing windows.

this one is the original meteor mpu200 with the 36-37 jumper mod and nvram. Sound still messed up.

More of a rounded signal.

200and3637modNewFile4 (resized).png

this one is the seawitch mpu200 that does NOT have the u17 jumper but does have the corrected route tracing. This has nvram as well, with seawitch software running (sound is ok in the meteor machine but obviously is playing seawitch background sound)

NewFile5 (resized).png

this one is the same seawitch mpu+nvram but with the meteor software installed. Sound is messed up, but in a different way. The 'kapow' sound (match or meteor downed) is working, the pop bumper sound now works, but the rest is still messed up (although sounds differently)

NewFile6a (resized).png

Now finally, it's the seawitch mpu200, with meteor software, and 5101's. The sound does NOT work. Same thing as with the nvram. I did look at the cpu chips, they aren't all motorolas - the seawitch one has an F at the start (fairchild?) and the meteor one is some kind of no name (maybe one of the williams marked ones although it didn't look like it.) Neither looked like AMI's though. Kind of puzzling, but might point towards the software timing being the issue instead of something else, unless you see something in the waveforms. I don't see how seawitch software could run the same sb300 through the same cabling and the 4042's not have an issue, but the same exact setup with different software does. The 5101s were the same ones I tried in meteor's board, too.

NewFile6 (resized).png

F6800 CPU chips are indeed made by Fairchild.

The two spikes look a little unusual..

The 'kapow' sound is made by the noise generator circuit on the SB300 which is U11 through to U6. The 'seed' (or maybe it's the duration, can't remember) for the noise generator is loaded through the CMOS chip connected to the data bus at U15 on the SB300.
The Up/Down ramp circuit U8, U12, U2 and U3 create the sweeping effect on the kapow and maybe other sound effects.
Looking at the SB300 schematic, the other CMOS chip (U14) hanging off the data bus sounds like it might be operating ok.
So guesstimate at the moment is some synchronisation issue loading data into the 6840 PTM (Programmable Timer Module) chip at U18.

Data is loaded into the 6840 on the falling edge of the "E" input which is connected to the "Ø2" signal from the MPU board. Note, Andrews board uses a 6802 CPU which generates the "Ø2" signal out of the CPU. The factory Stern board with 6800 CPU generates the "Ø2" signal from discrete external clock circuit.

In order for the signal captures to be useful they need to be taken from the same reference trigger point. You'd need a number of probes for this but for simplicity try taking a data line and address line capture with reference to the "Ø2" signal. The falling edge of "Ø2" signal is when data is loaded into the 6840.

The SB300 doesn't use the VMA (Valid Memory Address) signal from the CPU which might be an oversight. VMA is required when accessing ROM, RAM and PIAs.

Did the sound work properly with the Meteor MPU200 using 5101's? BTW as Andrew previously mentioned the 5101 should both be the same brand/type.

The sound did indeed work properly with 2x5101's in the meteor mpu, just not in the seawitch mpu. Same 5101's, as well I just moved them from one board to the other. (Phillips, if that matters - they were the first matched set I found in my stash).

This is what leads me to think that there's a software timing issue. What I should probably do next is put dead stock software in the boards and see what that does.

VUA-Q2 has a 150ohm (wow thats stiff) pullup. Wouldnt that pull the data bits up to 4.4v or so with the series diode voltage drop? I never fully understood what they where trying to accomplish with that vs just pulling up all eight data to 5v.

With a FM16W08 the system works fine with all the data bits pulled up to 5v. The 5101s are also powered by a circuit that drops the 12v down to around 5v. As the 82ohm resistor drifts the voltage to the 5101s rams will change which may effect timing? The replacement MPU powers the fm16w08 right off of the 5v.

VMA to the 6840 will actually lock up some MPUs. I think its a fail mode of the 6840 chip itself but appears somewhat common as I ran into it numerous times back when I used to repair original boards. I'd fix a MPU200 that worked fine for me but is locked up in another game. Using a 32pin ribbon cable or lifting the VMA pin out of the 6840's socket resolved it and the sound board and MPU work fine.

I just had a message from someone using the nvram.weebly.com aftermarket MPU in meteor that was having the sound problem with the free play version and divide by ten versions. When he switched the software the factory bonus x underflow bug fix rom the sound problem cleared.

Testing around various things when the NVRAM chip is blank I can use any meteor software version and the sound is fine. If I boot a Bally game first, then go to Meteor, the spinner sound and other sounds is wrong. I can always use the factory bug fix rom no matter the RAM contents and the sound works fine.

Something saved in the RAM chip seems to be able to cause the sound problem in certain cases. That makes it seem like a software bug but why on original MPUs does mixing the speed of the RAM chips do the same thing???? Odd issue but using the "factory bug fix" ROM seems like a solution.

That kind of mirrors what's going on with mine, although of course the software I'm using doesn't exist any where else yet, but it is based around the original non-factory bugfix software.

I can tell other games must save stuff in RAM related to sounds. Like in Big Game when I first time boot with a blank NVRAM and you add credits, the credit noise is wrong and sound test is wrong. Once you start a single game then the credit noise is normal and sound test goes to normal for big game. So something happens at game start that effects what the sounds are in Big Game.

Maybe compare what happens at game start in the factory bug fix version of meteor and the other versions.