Stern Meteor owners- Good News, Everyone!

[seymour.shabow]

Hey, remember all that discussion that went back and forth over the
years about the "meteor bonus multiplier bug"? (Which I did fix but
also with other added things).

Hey, ever wonder what the difference was on the ipdb files between the
"alternate" set and the original?

Stern fixed the bug in the factory :) They used the lower part of the
stack to save the multiplier instead of re-using a memory location that
the collect all rockets routine uses (which is the source of the error).

So, anyone that didn't want all the various fixes over the years because
they weren't stamped 'offical' from the factory.... you now have a
source for it.

Although.... dipping into the stack can be dangerous I'd assume since
they went to the trouble to fix this way back when, it's been tested
thoroughly.

Thanks to Mike Fox for some back and forth and verifying roms in his
machine for this info.

[trader...@gmail.com]

Good to know. So it's the one in the archive labeled U1A with checksum $C47C that doesn't have the bug? TIA.

viperrwk

[John Robertson]

Can you refresh our memories about the bonus multiplier bug?

John :-#)#

--
(Please post followups or tech inquiries to the USENET newsgroup)
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
(604)872-5757 or Fax 872-2010 (Pinballs, Jukes, Video Games)
www.flippers.com
"Old pinballers never die, they just flip out."

[barakandl]

seems like the cpu gets over loaded when lots of switches are going on and it is doing something to the bonus count. If the ball drain befores the CPU catches up, you get stuck with a infinite, or really large bonus countdown.

Meteor also will skip scoring the drop targets if lots of stuff is going on. I can't remember this behavior in other stern games.

[barakandl]

** bonus multiplier i should say, not the rockets.

[John Robertson]

On 08/20/2016 12:02 PM, barakandl wrote:
> On Saturday, August 20, 2016 at 3:01:04 PM UTC-4, barakandl wrote:
>> On Saturday, August 20, 2016 at 1:42:48 PM UTC-4, John Robertson wrote:
>>> On 08/20/2016 9:21 AM, seymour.shabow wrote:
>>>> Hey, remember all that discussion that went back and forth over the
>>>> years about the "meteor bonus multiplier bug"? (Which I did fix but
>>>> also with other added things).
>>>>
>>>> Hey, ever wonder what the difference was on the ipdb files between the
>>>> "alternate" set and the original?
>>>>
>>>> Stern fixed the bug in the factory :) They used the lower part of the
>>>> stack to save the multiplier instead of re-using a memory location that
>>>> the collect all rockets routine uses (which is the source of the error).
>>>>
>>>> So, anyone that didn't want all the various fixes over the years because
>>>> they weren't stamped 'offical' from the factory.... you now have a
>>>> source for it.
>>>>
>>>> Although.... dipping into the stack can be dangerous I'd assume since
>>>> they went to the trouble to fix this way back when, it's been tested
>>>> thoroughly.
>>>>
>>>> Thanks to Mike Fox for some back and forth and verifying roms in his
>>>> machine for this info.
>>>
>>> Can you refresh our memories about the bonus multiplier bug?
>>>
>>> John :-#)#
>>>

>> seems like the cpu gets over loaded when lots of switches are going on and it is doing something to the bonus count. If the ball drain befores the CPU catches up, you get stuck with a infinite, or really large bonus countdown.
>>
>> Meteor also will skip scoring the drop targets if lots of stuff is going on. I can't remember this behavior in other stern games.
>
> ** bonus multiplier i should say, not the rockets.
>

Interesting, we had two Meteors pass through here in the past couple of
months and I do not recall any oddities in the scoring. We play
tournament style at the end of our work day for chores so certainly if
the game was 'cheating' we would have heard about it. Six guys playing
two or three games each to resolve the daily winner shows up most bugs
in games!

Did finally track down the wiring errors for the 2X lamp and the Clear
Switch (posted both a week ago here on RGP), but nothing else of annoyance.

[coy...@gmail.com]

On Saturday, August 20, 2016 at 1:14:47 PM UTC-4, trader...@gmail.com wrote:
> Good to know. So it's the one in the archive labeled U1A with checksum $C47C that doesn't have the bug? TIA.

Yeah, that's the one. That's the 'fixed' one - the one marked U1 is the one with the bug.

> Interesting, we had two Meteors pass through here in the past couple of
> months and I do not recall any oddities in the scoring. We play
> tournament style at the end of our work day for chores so certainly if
> the game was 'cheating' we would have heard about it. Six guys playing
> two or three games each to resolve the daily winner shows up most bugs
> in games!
>
> Did finally track down the wiring errors for the 2X lamp and the Clear
> Switch (posted both a week ago here on RGP), but nothing else of annoyance.

From what I understand, in normal game play you would have like a one in 100 change of getting it -
You would need, essentially, to have the ball -
- Have 7x bonus.
- Shoot fast and hard through the spinner, and have the ball immediately come around and drain down a 'Collect All Rocket' lit outlane, and hit the outhole.

Since the spinner, in some configs of the game (DIP switches) make the outlanes switch on and off, it's not a common issue, for sure.

[coy...@gmail.com]

Thanks for putting up with my numerous questions. :)
Now that I'm home tonight, I'll be burning my original ROMs back in place, and record the speed difference for you.

[barakandl]

How fast the game plays influences the likelihood of this bug. When i used to have meteor I would get this infinite bonus multiplier count every once in a while. I had I my games setup really fast and steep. My dad's meteor is setup with less slope and it plays slower. Never once had it happen to me playing on his slower playing meteor.

[seymour.shabow]

seymour.shabow wrote:
> Hey, remember all that discussion that went back and forth over the
> years about the "meteor bonus multiplier bug"? (Which I did fix but
> also with other added things).

OK, to refresh everyone's memory as to what the bug is and what causes
it....

If you have all rockets lit on the outlanes, AND you have a lot of other
scoring things going on (usually related to a spinner hit since that
keeps repeating) you can overload the thread engine in the game, such
that the 'collect all rockets' thread (which unnecessarily gives a sound
effect and scores for each rocket instead of just scoring it at
once...i.e. there are delays built into the thread which turn out to
cause the error.).

Once the collect all rockets thread is running AND the thread starts
that collects the bonus in the outhole, you will get a zero inserted
into the bonus multiplier.... which will count down 255x (if you wait
long enough). It's not infinite, and has nothing to do with the speed
of the game. Its simply because the collect all rockets thread isn't
finished when the collect bonus thread starts.... and the error is
because the multiplier in the collect bonus thread is stored in the same
memory location that the collect all rockets thread uses as well. 2
threads that were never intended to run at the same time using the same
memory location is sure to cause errors.

It's more likely to happen the more rockets you have (since that extends
out the collect all rockets thread execution) and with the spinner as it
keeps adding another thread onto the execution (the spinner thread is
exceptionally long as it has almost 2k (that's 25% of the entire
codebase!) dedicated to seeing which lamps are lit, what multiplier you
have, and moving those lamps around.) This is extremely sloppy in
stern's thread language and really could be changed to inline assembly
to save TONS of space. If I needed more romspace I'd probably do just that.


The fixes?

My (ultimately working) fix was to repurpose one of the audits that's
used to track replay levels 2 and 3 and use those locations instead to
store the variables in the collect all rockets thread.

Stern's fix from way back when was to utilize the lower part of the
stack to do the same thing. I don't think that way is 100% safe (they
didn't use the BOTTOM of the stack - they used somewhere in the middle)
- but it's probably safe enough. Put enough extra threads in play
though and you'd probably clobber it.

There were a lot of red herrings in duplicating the error, and until I
disassembled the original code 100% and commented it all didn't even
realize the duplicate memory location until I laid them out next to each
other.


Some failed fixes along the way....

check the multiplier during bonus countdown and if it ever became 0x, or
something else invalid, just make it 2x. That's not fair... you lose
multiplier because the game screwed up. This did work but was sloppy,
unfair, and reactive. This came about from not understanding the entire
codebase!

add a delay to the outhole thread running/starting so that other threads
had a chance to finish. I think this would have worked but it drove me
NUTS when the ball drains and just sits there for 3-4 seconds.

Several more failed stratagems where checking the spinner and collect
all rockets threads all of which lasted about 5 minutes in the machine
before I rejected them.

What pointed me in the right direction was when I didn't take the
spinner into account AT ALL in getting the bug to activate. I got a ton
of other switches going first and then I collected all rockets and STILL
got the bug.... so I knew it was in the collect rockets thread. Once I
could ignore the 2k long spinner code.... a lot easier to spot it.

[Kerry Imming]

On 8/21/2016 12:46 PM, seymour.shabow wrote:
> and the error is because the multiplier in the collect bonus thread is
> stored in the same memory location that the collect all rockets thread
> uses as well.

Impressive detective work.
It's amazing the things that were done to save a byte of memory back then.

[John Robertson]

Memory was expensive in those days - and folks programmed in assembler
for this vintage of pinball games as far as I know...

[seymour.shabow]

John Robertson wrote:
> On 08/22/2016 10:25 AM, Kerry Imming wrote:
>> On 8/21/2016 12:46 PM, seymour.shabow wrote:
>>> and the error is because the multiplier in the collect bonus thread is
>>> stored in the same memory location that the collect all rockets thread
>>> uses as well.
>>
>> Impressive detective work.
>> It's amazing the things that were done to save a byte of memory back
>> then.
>>
>
> Memory was expensive in those days - and folks programmed in assembler
> for this vintage of pinball games as far as I know...
>

It's a mix of assembly and Stern's own byte code language (similar to
what williams did). Bally stuck with 100% assembler for a long time.
Stern's mpu-200 operating system is multi-threaded. They switched to
inline assembly quite freely but whoever wrote the move the lamps
sequence on the spinner did it in stern's bytecode (a 2k series of
if-then statements... covering EVERY permutation of lamps possible).
They should have done it in inline assembly with some logic instead, or
hell, lookup tables. (Bally liked lookup tables)