New! Dark mode!

Browsing Pinside at night? Getting tired of all the white? Switch to dark mode using the button in the top right (or CTRL-B)!

(Topic ID: 237281)

Stern Meteor ROM Issue - Bugfix, Sound Issues, NVRAM Discussion

By acebathound

1 year ago

Topic Stats

  • 89 posts
  • 11 Pinsiders participating
  • Latest reply 1 year ago by I_P_D_B
  • Topic is favorited by 13 Pinsiders


Linked Games

  • Meteor Stern Electronics, 1979

Topic Gallery

There have been 12 images uploaded to this topic. (View topic image gallery).

NewFile6 (resized).png
NewFile6a (resized).png
NewFile5 (resized).png
200and3637modNewFile4 (resized).png
NewFile2 (resized).png
NewFile1 (resized).png
20190228_155221 (resized).jpg
20190228_155209 (resized).jpg
pasted_image (resized).png

You're currently viewing posts by Pinsider slochar.
Click here to go back to viewing the entire thread.

#16 1 year ago
Quoted from Dr_Dude:

I'm curious if anyone knows of divide-by-10 ROM images with this fix? I do like running 6-digit displays on Meteor, even if it is blasphemy to have no trailing always-zero digit!

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.

2 months later
#17 1 year ago

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

#18 1 year ago

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.

#19 1 year ago

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.

#23 1 year ago
Quoted from Coyote:

Random thought - if the display interrupt timer starts to shift over time (55 chip and RC networks), is it possible that the interrupts are affecting timing for sounds at all?

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

Quoted from Quench:

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?

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.

#26 1 year ago
Quoted from Quench:

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?

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.

Quoted from barakandl:

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

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

1 week later
#29 1 year ago

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.

#31 1 year ago
Quoted from Quench:

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.

#33 1 year ago

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

#34 1 year ago

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

#37 1 year ago

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.

#39 1 year ago

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.

#40 1 year ago

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
#41 1 year ago

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
#42 1 year ago

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
#43 1 year ago

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
#44 1 year ago
#46 1 year ago

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.

1 month later
#49 1 year ago

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.

#51 1 year ago

Big game and up use more RAM for the sound counters/steps than the earlier games. That's the only difference. I've been through both's software multiple times trying to pirate sounds from Big Game to put into Meteor

Not been successful in that endeavor yet

1 month later
#74 1 year ago
Quoted from Coyote:

Eventually, the v24 version will be fixed to correct the sound issue and bonus bug.

That's already been done. It's just not on ipdb yet since they are slow as heck to post updates. I sent them the requested scan of the eight ball deluxe manual they were looking for almost a year ago (maybe more) and it's not posted yet.

#76 1 year ago


I suppose it helps if you are the author of the mod, then you always have the latest version.

#78 1 year ago

Well, I did think it was "done" but after finally nailing down what seems to be the fix for the bad sound being a couple locations needing zeros, then watching some new players get screwed by the spinner still turning on drain (spins went into the next players' ball) I decided to tweak it a little.

I also found another bug where if you start p1 game, score a bit and decide to add p2, your score zeroes out until you score again (it doesn't wipe any of the score) - really it's the 'last player' that gets zeroed (p2 on p3 add, p3 on p4 add).... plus I made it freeplay with a dip instead of all the time. The stock rom footprint is very full at this point. Oh yeah, the 25k rocket sweep bonus is in there too, now dip switch settable.

I think I sent IPDB v26 I'm still testing v27.

If you add some mods to yours then you'll have the latest codebase (of yours!)

2 weeks later
#80 1 year ago

v26 didn't have the options to turn on/off the sweep bonus and freeplay which I put into v27 but I am still working on v27 I think there might be a major bug in there (actually might be all the big game based versions)

I'm going to swap a stock board back in there next week to see if I'm hearing things wrong. If I am as a suspect, the sound code is going to need more massaging. Ever notice any "extra" silence between sounds? I played a stock meteor a couple weeks ago and noticed the sounds flowed together better.

The stock code was ported to the big game base but that doesn't mean the timing is 100% correct on things. The stock data didn't work with the stock big game code which is why it was changed anyway. I'm on a long uphill battle trying to understand how an sb-300 produces sounds, so that new sounds can be produced. I'd really like to have an in-circuit debugger for the hardware in the game along the lines of pinmame but hardware is not my forte.

#82 1 year ago

Yeah I don't think the silence is normal. I'll play around on my large supply of OEM boards with and without NVram as well as probably every revision of Andrew's boards. Probably send you a test version once I determine what's different (probably a timer somewhere.....)

First things first is I have to remove the non-working background sound quash that doesn't work... like, at all. I'd always assumed it did from RGP years ago but I guess no one (including me) ever tested it until v27. I don't WANT to remove the bg sound, people that get meteor, get it, and all other people that don't like it.... tough

#84 1 year ago

No, the Meteor folded into Big Game's operating system sound.

I don't think I've heard the dog whistle big game sound in big game yet, but my hearing high frequencies isn't what it used to be. One bonus of getting old.

Probably the only bonus.

#87 1 year ago

No, it was one guy several years ago re: the BG sound in meteor. I posted a fix that apparently no one (including me) ever tried.... and it didn't work.

RGP is dead as a doornail, it's people posting accidentally on old threads, John Robertson replying to everything, JT amusements replying back to John, and franknfurter trolling as usual.

Promoted items from the Pinside Marketplace
$ 100.00
Playfield - Protection
Beehive Pinball Co.
$ 5.00
Playfield - Decals
Doc's Pinball Shop
$ 149.95
From: $ 155.00
$ 100.00
Gameroom - Decorations
The Flipper Room
$ 49.99

You're currently viewing posts by Pinsider slochar.
Click here to go back to viewing the entire thread.

Hey there! Got a moment?

Great to see you're enjoying Pinside! Did you know Pinside is able to run thanks to donations from our visitors? Please donate to Pinside, support the site and get anext to your username to show for it! Donate to Pinside