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 12 months 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 quench.
Click here to go back to viewing the entire thread.

#21 1 year 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?


#24 1 year 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?

#28 1 year 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
#30 1 year 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.

#32 1 year 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.


#35 1 year 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.


#36 1 year 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.

#38 1 year 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.

#45 1 year 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.

Promoted items from the Pinside Marketplace
$ 149.95
From: $ 155.00
From: $ 25.00
From: $ 45.00
$ 9.00
Cabinet Parts
Third Coast Pinball
$ 5.00
Playfield - Decals
Doc's Pinball Shop
From: $ 155.00

You're currently viewing posts by Pinsider quench.
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