(Topic ID: 237281)

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


By acebathound

4 months ago



Topic Stats

  • 47 posts
  • 8 Pinsiders participating
  • Latest reply 31 days ago by barakandl
  • Topic is favorited by 6 Pinsiders

You

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
MPU_Bally_5101_Pullups.jpg
NewFile2 (resized).png
NewFile1 (resized).png
MPU200_DataBus.jpg
FM16W08_Endurance.png
20190228_155221 (resized).jpg
20190228_155209 (resized).jpg
pasted_image (resized).png

#1 4 months ago

Recently had a customer ask about the incompatibility I list with the MPU-200 NVRAM when used with Meteor. Got me looking again at what info was out there for this game and to see if there were any updates on what AFAIK are isolated cases of people having issues with using NVRAM on these boards.

The Facts:
1. Some people (not all) have reported installing NVRAM on Meteor caused the sounds to be "noticeably different" (esp the spinner).
2. Upgrading the game to EPROMs fixes the issue for some people (not all).

I hadn't really thought of Meteor being *THE* first MPU-200 game (1979). At least according to IPDB, it's game #113 (for reference, game #112 was Hot Hand). This right here tipped me off of a possible code or hardware issue related to it being the first game using the new board.

Then I see these threads about a bugfix for MPU getting bogged down, loop of counting the bonus 255 times..

And finally, dothedoo even mentions a problem with Zeropower NVRAM on an Alltek causing issues with spinner sound... which seems to be the same type of issues being reported with the MPU-200 NVRAM (or individual 5101 NVRAM Modules used at U8/U13).

Seeing as how a spinner sound issue is mentioned with Alltek + Zeropower, it has me wondering if the bugfix rom IS THE FIX for the MPU-200 NVRAM "incompatibility".


Can those with a METEOR and experience with this whole sound issue and/or bugfix code chime in?

If you had a sound issue when using NVRAM, was it fixed using EPROMs & if so, did you use the newer bugfix code?

If this has been addressed anywhere, let me know. I just thought I'd throw together a full discussion on it and even if the bugfix ROM isn't the solution for MPU-200 NVRAM compatibility, maybe we can see how widespread sound issues are. I've heard some people have upgraded Meteor to NVRAM without a problem.

---
http://www.pinitech.com - "Pinball Inspired Technology"
NVRAM, Bally/Stern LED Displays & Mods for pinball machines

#2 4 months ago

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.

#3 4 months ago
Quoted from barakandl:

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.

Did you use the bugfix code on the new EPROMs or was that the original code?

See what's standing out to me is the report of the Alltek having the same problem with a Zeropower RAM, but also running the original code. Not saying it may not be related to jumper issue you linked from Pinwiki, but it looks like it's either code or hardware. If we can get some people who own Meteor machines and have had sound issues to work things out here, maybe we can nip it once and for all.

#4 4 months ago
Quoted from acebathound:

Did you use the bugfix code on the new EPROMs or was that the original code?
See what's standing out to me is the report of the Alltek having the same problem with a Zeropower RAM, but also running the original code. Not saying it may not be related to jumper issue you linked from Pinwiki, but it looks like it's either code or hardware. If we can get some people who own Meteor machines and have had sound issues to work things out here, maybe we can nip it once and for all.

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.

#5 4 months ago

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.

#6 4 months ago

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.

#7 4 months ago

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.

#8 4 months ago
Quoted from kbliznick:

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.

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
#9 4 months ago
Quoted from barakandl:

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.[quoted image]

So your references to triggering of the NVRAM chip select are to the U17/U19 modifications mentioned on Pinwiki below right?
http://www.pinwiki.com/wiki/index.php?title=Bally/Stern#Schematic_Errors_with_Stern_MPU-200_MPU

In other words, very early MPU-200 boards had an issue & modifications were done to some of the boards leaving the factory at some point. Then the MPU-200 board was revised to include those modifications. Do I have that correct?


It seems like there's several possibilities of what's causing the issue with sound with NVRAM..

  • 4x Factory Masked ROMs Being Used (possible solution - try 2x 2732 eproms instead, with board jumpered appropriately)
  • Very early MPU-200 board being used, *without* the modifications mentioned in the Pinwiki link above.
  • Code issue in the early masked ROMs and/or possibly related to what the bug fix rom fixes.
  • State of the NVRAM/memory when first plugged into the board (ie. Alltek "system clear" had fixed the issue?)

This is why I created the thread, to try to get to the root of the problem via people's experiences installing NVRAM on Meteor. If we can get an idea of what ROMs or version of the MPU is being used on games the sound issue was experienced on, we might be able to flush out the actual cause.

It's interesting to hear a "system clear" on an Alltek cleared things up.

#10 4 months ago
Quoted from acebathound:

So your references to triggering of the NVRAM chip select are to the U17/U19 modifications mentioned on Pinwiki below right?
http://www.pinwiki.com/wiki/index.php?title=Bally/Stern#Schematic_Errors_with_Stern_MPU-200_MPU
In other words, very early MPU-200 boards had an issue & modifications were done to some of the boards leaving the factory at some point. Then the MPU-200 board was revised to include those modifications. Do I have that correct?

It seems like there's several possibilities of what's causing the issue with sound with NVRAM..

4x Factory Masked ROMs Being Used (possible solution - try 2x 2732 eproms instead, with board jumpered appropriately)
Very early MPU-200 board being used, *without* the modifications mentioned in the Pinwiki link above.
Code issue in the early masked ROMs and/or possibly related to what the bug fix rom fixes.
State of the NVRAM/memory when first plugged into the board (ie. Alltek "system clear" had fixed the issue?)

This is why I created the thread, to try to get to the root of the problem via people's experiences installing NVRAM on Meteor. If we can get an idea of what ROMs or version of the MPU is being used on games the sound issue was experienced on, we might be able to flush out the actual cause.
It's interesting to hear a "system clear" on an Alltek cleared things up.

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.

#11 4 months ago

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).jpg20190228_155221 (resized).jpg
#12 4 months ago
Quoted from barakandl:

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.

Cool, thanks for posting what info you have & the pics. I know we discussed this *WAY BACK* some.. and I just went with calling Meteor "incompatible" with the MPU-200 NVRAM after having a few people contact me with the sound issue. One guy tried a new set of EPROMs and no luck.

Unfortunately without a Meteor to test this in myself, I'd have to setup some kind of bench test to first reproduce the problem and I haven't seen/heard it myself to know exactly what's different At least with this thread sitting out there, some people having the issues can post a picture of their MPU and mention if upgrading to the 2x 2732 eproms fixed things.

#13 4 months ago

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

#14 4 months ago

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?

#15 4 months ago

This is a great thread. My first game was Meteor, and at one point a 5101 died and I put in a new one, immediately triggering the f-ed up spinner noise problem. On occasion I've swapped in an MPU-200 from another game to aid in diagnosis, and again have on occasion gotten the spinner-noise problem. I run my boards as original as possible (though I do install a super-cap instead of a NiCad), so have never tried the NVRAM, so never ran into that issue. I do have EPROMs since I've updated to divide-by-10 ROMs from Oka Egi's site.

I was unaware there was a fairly significant revision on the early MPU-200 boards, and will inspect my (likely original) Meteor board to see if I have the fix or not. I was also completely unaware of the "bug fix" factory U1 ROM (and have absolutely experienced the bonus-countdown infinite-loop: Typically on a game where I was about to defeat my high-score!). 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!

#16 4 months 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 50 days 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 50 days 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 50 days 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.

#20 50 days ago

slochar it's nice to see someone trying to look into this deeper, from a code and eprom standpoint even.

Looks like the needle-in-the-haystack search continues. Thanks for your efforts and insight!

#21 50 days ago
Quoted from slochar:

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

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.

Quoted from slochar:

Unless I figure out how to re-format the sounds from meteor into what the big game OS expects

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

#22 49 days ago
Quoted from slochar:

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.

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?

#23 49 days 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.

#24 49 days ago

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?

#25 49 days ago

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

#26 49 days 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!!

#27 49 days ago
Quoted from slochar:

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.

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.

#28 49 days ago
Quoted from slochar:

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?

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.

Quoted from slochar:

I need a 2 month holiday to play around with all these projects!!

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

1 week later
#29 38 days 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.

#30 37 days ago

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.

#31 36 days 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.

#32 36 days ago
Quoted from slochar:

I don't think the data out of the FRAM is an issue because all the mpu200 games use it for the stack.

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

Quoted from slochar:

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

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

Quoted from slochar:

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

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.

Quoted from Quench:

Can you try modifying the MPU board by changing the (hardwired on the back) jumper E37-E38 to E37-E36?

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

#33 36 days 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 36 days 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

#35 36 days ago
Quoted from slochar:

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.

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

#36 36 days ago

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.

#37 36 days 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.

#38 36 days ago
Quoted from slochar:

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

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.

#39 35 days 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 35 days 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 35 days 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 35 days 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 35 days 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 35 days ago
#45 35 days ago

F6800 CPU chips are indeed made by Fairchild.

Quoted from slochar:

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

More of a rounded signal.

The two spikes look a little unusual..

Quoted from slochar:

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)

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.

Quoted from slochar:

Now finally, it's the seawitch mpu200, with meteor software, and 5101's. The sound does NOT work.

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.

#46 35 days 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.

#47 31 days ago

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.

Promoted items from the Pinside Marketplace
From: $ 13.00
Electronics
Third Coast Pinball
From: $ 15.00
$ 7.65
Cabinet Parts
Third Coast Pinball
$ 10.00
$ 157.00
1,300
Machine - For Sale
Elkhart, IN

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