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.

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.

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

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.

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.

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

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.

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

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.

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.

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

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.

v27

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

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

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.

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

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.

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.