(Topic ID: 286855)

Upgrading a 2-Ball Game to Three Balls With Software - Can it Be Done?

By idealjoker

12 months ago


Topic Heartbeat

Topic Stats

  • 31 posts
  • 10 Pinsiders participating
  • Latest reply 11 months ago by Billy16
  • Topic is favorited by 3 Pinsiders

You

Linked Games

Topic poll

“can/should this be attempted?”

  • possible 7 votes
    41%
  • not possible 0 votes
  • good idea 0 votes
  • bad idea 9 votes
    53%
  • who cares 0 votes
  • go stick your head in a pig 1 vote
    6%

(17 votes)

Topic Gallery

View topic image gallery

Outhole (resized).jpg
Trough (resized).jpg

#1 12 months ago

I own three Pinball games - Alien Poker, Jungle Lord and Pin Bot. While I love them all, I have serious 3-ball envy. Unfortunately, right now another game is not on the books, so the only option I can think of is to take one of my 2-ball games (JL or PB) and turn it into a 3-ball game. I want to do this with a software patch and a third ball alone, without modifying the game hardware. If successful, it should be possible to implement similar upgrades for other Williams System 7 - 11 games, and probably for games from other manufacturers as well.

I am not aware that a three-ball upgrade has been attempted before, so this thread is intended to document my progress and frustrations (a journey thread). If there is interest, I am happy to go into technical details, which may be useful for others who are interested in ROM hacking. If not, there will be at least some gameplay videos. There's a poll where you can let me know what you think about the topic. Feedback and comments are obviously appreciated.

#2 12 months ago
Quoted from idealjoker:

I own three Pinball games - Alien Poker, Jungle Lord and Pin Bot. While I love them all, I have serious 3-ball envy. Unfortunately, right now another game is not on the books, so the only option I can think of is to take one of my 2-ball games (JL or PB) and turn it into a 3-ball game. I want to do this with a software patch and a third ball alone, without modifying the game hardware. If successful, it should be possible to implement similar upgrades for other Williams System 7 - 11 games, and probably for games from other manufacturers as well.
I am not aware that a three-ball upgrade has been attempted before, so this thread is intended to document my progress and frustrations (a journey thread). If there is interest, I am happy to go into technical details, which may be useful for others who are interested in ROM hacking. If not, there will be at least some gameplay videos. There's a poll where you can let me know what you think about the topic. Feedback and comments are obviously appreciated.

You’d probably have to add a third sensor in the trough for the game to detect the extra ball. Why do you need them to be 3 ball? I’d only see this making sense in those old games that had multi-ball designed and then removed to save money. If it’s not designed for 3 ball it seems like it may make it too easy or just not flow as well.

#3 12 months ago

Certain one-ball games at the VFW have been modified into Multi-Ball games.

#4 12 months ago
Quoted from Isochronic_Frost:

You’d probably have to add a third sensor in the trough for the game to detect the extra ball.

If you bear with me for a few posts I intend to explain how I am going to avoid having to install a new switch and what problems this causes. I will also show several solutions for these problems.

I actually share your skepticism about whether it makes sense to upgrade a 2-ball to a 3-ball game from a game-play perspective. I suspect that the answer will be different for different games.

Quoted from MrBally:

Certain one-ball games at the VFW have been modified into Multi-Ball games.

I am aware of Oliver Kaegi's MB upgrade for Alien Poker, which requires serious hardware modification. (For me, having multiball with the Alien Poker rules does not make much sense, so I am not planning on upgrading mine.) If you have information about others, please let me know.

#5 12 months ago

I guess you could leave a third ball in the outhole, like some later gottliebs did, to get away with not doing any Trough modifications. Would still need major changes to the rom though...

#6 12 months ago

As a test bed, I going to use Jungle Lord, which is a Williams System 7 game with a split playfield. It is an underrated game with a great playfield layout, but it does have some fairly serious game-rule issues. So I was over the moon when I found technical information and even a programming manual for the WMS System 7 operating system on Jess Askey's GameArchive site (http://gamearchive.askey.org/Pinball/Manufacturers/Williams/PinBuilder/text/williams_lvl7_programming.html). I started modding the code and a few years ago I made a home ROM (Jungle Lord - new tricks, JLnt).

First thing I did was remove the glass and play a few 3-ball multiballs. Turns out that it is super-hard to keep three balls in play with the two playfields. Once or twice I managed to keep all three balls in play for a while and that was great fun. Sufficient to convince me to to put some serious effort into this project.

I am going to base the upgrade to three balls on an add-a-ball ROM version that I have been playing with for a while:

This version is multiball heavy, which make it ideal for 3-ball debugging. (From a gameplay perspective, it is too multiball heavy, which is why I have not released this version. I made it mainly so I could train my multiball play for the league.) There are only 26 free bytes available in the game ROM. So the first task will be to free some more space. Since I cannot stand the FX at the start of Stampede mode (the timed 2-ball multiball mode with unlimited balls), I intend to replace that with something that is less code hungry. If I need more space I’ll worry about that later.

#7 12 months ago
Quoted from zacaj:

I guess you could leave a third ball in the outhole, like some later gottliebs did, to get away with not doing any Trough modifications.

Unfortunately this does not work with Jungle Lord. If you don't mind I prefer waiting with details until I have described the trough system first, including what switches there are and what they do in the original ROM. I think that this will make the information in this thread more understandable for others who don't have your experience with pinball code.

#8 11 months ago

BALL TROUGH

The image below shows the ball trough system, with a ball in each of the seven locations that I have seen balls come to rest when three balls are installed in the game. With only two balls installed (original game), the same positions are possible except for #4. The red ball positions have switches, the blue ones do not. A 3-ball game from the same vintage has the same ball trough with an additional switch in the #4 position. In Jungle Lord switch matrix there is a gap where this switch would logically be (switch 11) so, maybe I am not the first one to consider three balls on this game. The game code needs to be able to respond correctly to all possible ball configurations in the trough system. For example, when a new game is started, the original code must handle both configurations 5-6 (both balls in trough) and 6-7 (one ball in trough and the other in the shooter lane).

SWITCH HANDLERS

The Williams System 7 operating system is multi-threaded. Whenever a switch is triggered (usually when it is closed) the system spawns a new thread with the switch-handler code. Here's what the switch handlers of the trough system in the original code do:

#2 (outhole): The outhole switch handler is very simple. It energizes the solenoid to kick the ball from the outhole into the ball trough and sets a status flag indicating that a ball has drained.

#5 (left ball ramp): This switch handler is triggered whenever a ball passes through or comes to rest in trough position #5. If there is no ball in position #6 (multiball is in progress and the first ball has just drained), the ball is just passing through and the switch trigger is ignored. If there is a ball in position #6, however, it means that all balls have drained. In Jungle Lord a new ball is immediately launched (without ending the current ball), if either the Stampede timer is running or when the drained ball has passed through an outlane with a drain shield enabled, or when the switch was triggered when the "ball drained" status flag was not set. (The last condition handles the case when a ball is ejected into the shooter lane and bounces straight back into the trough.) Otherwise, another flag is set to indicate that game play is disabled and control is handed to the end-of-ball system routine.

#6: (right ball ramp): This switch handler is usually triggered during multiball when the first ball has drained, but also when a ball is locked and the second ball has been ejected into the shooter lane but bounced right back in. The second case is handled first by energizing the ball-shooter solenoid and exiting. If the timed Stampede mode is still going the lock lamps are re-lit. Otherwise the drain-shield playfield lamps that were disabled during Stampede are enabled again.

#7: (ball shooter): The handler routine for this switch is triggered both when the switch is closed and when it is opened. When the switch is opened (when a ball is shot up the lane), a sound is played. If the ball is launched as part of Stampede mode (which may by now have timed out) the switch handler sleeps for 6s and then simulates triggering of the playfield entry switch. This ensures that a locked ball is ejected even if the playfield entry switch is flakey. If the switch handler is triggered when the switch is closed (either a ball was just ejected from the trough or the serve was not strong enough and the ball rolled back down the shooter lane) any running "playfield entry switch simulator thread" is killed. This ensures that a locked ball is not ejected unless the other ball has really entered the playfield.

ADDING A THIRD BALL

With this code, you can take off the glass and add a third ball to the game. The ball triggers the outhole switch handler, which kicks the ball into the trough, where it ends up in position #4. Without a switch the game does not notice this extra ball until a game is started and a ball is ejected into the shooter lane. After the eject the third ball rolls from position #4 to #5 where it triggers the left ball ramp switch. The game falsely assumes that the ball which just got served must have bounced back from the shooter lane into the trough and ejects a second ball into the shooter lane. The first step to upgrading the game to three balls is to modify the code to play the original game with three balls installed...

Trough (resized).jpg
#9 11 months ago

Modifying the game code to play the original game with three balls installed is not hard. The only changes are to trigger some of the switch handlers described in the previous post at different times. Specifically:

  1. There's always a ball in position #6. Therefore there's nothing to do for the right ball ramp switch, which is simply ignored. Implementing this requires a simple pointer change in the switch table.

  2. The original switch handler for position #6 must be called when the position #5 switch is triggered. Another pointer change in the switch table.

  3. The original switch handler for position #5 should be called when a ball arrives at position #4. Since there is no switch at that position, this is not possible. As a work-around, the switch handler is called instead from the outhole switch handler when a ball is kicked into the trough while there is already a ball in position #5. Implementing this requires adding a few bytes of code to the outhole switch handler to run the code as a separate thread.

All together, it took less than 2 hours to implement these changes. I installed a ceramic ball (power ball from TZ) into the game so it is clear in a video that there really are 3 balls installed in the game:

#10 11 months ago

Or you could just trade one of those games for a firepower....

#11 11 months ago

There’s no poll option to applaud and encourage your creativity and industriousness while at the same time expressing the opinion that most of those games probably are best left to be played as designed, even if that means they’re less full-featured than later games.

#12 11 months ago

So the game doesn't know if there's three balls in the trough when it's first booted?

#13 11 months ago
Quoted from idealjoker:

I am aware of Oliver Kaegi's MB upgrade for Alien Poker, which requires serious hardware modification. (For me, having multiball with the Alien Poker rules does not make much sense, so I am not planning on upgrading mine.)

The only way Alien Poker multiball would "work" would be if the drop bank was only utilized the way it is now in single ball only. Multiball makes zero sense to have a drop bank whose goal is to hit a single drop down in order when you've got 3 balls flying around.

I love Oliver for his trailblazing in this area for sure, but most of the multiball 'modes' and goals just don't make sense to me.

You can have plenty of romspace if you rejumper your MPU for hyperball style with 3x2532's. I don't doubt that there might be some crunch opportunities in there but the code is pretty efficient now, unless you're going to try and do it all in the gamerom and not touch the OS roms.

Quoted from idealjoker:

If you have information about others, please let me know.

Flash, Nitro Groundshaker, World Defender, Trail Drive (em). I might be mistaken on Trail Drive, but there was definitely at least one EM Clay did it to. All require adding or moving hardware (switches).

Going from 2 ball to 3 ball multiball isn't that much of a stretch for sure, some single ball games MIGHT lend themselves to multiball, but a lot of them don't without tossing out tons of old rules. I hadn't realized JL was only 2 ball MB I thought it had an option for 3 like Pharoah does. Unless Pharoah also doesn't and I'm misrembering.

I know I considered using the outhole on firepower to make it 4 ball multiball in just the way you're intending JL to work but never got around to trying it out. It would have been the same as 3 ball multiball but with 4x playfield scoring, when you launched the ball and hit the first target after locking the 3 it would release them. That's the way the other ones work at VFW BTW, ball is held in the game's saucer, then the second ball is served, and then MB starts on first switch hit after that. Those are "gottlieb system 80 style", where no ball will remain in the lock in between balls.

Quoted from PinballBJB:

There’s no poll option to applaud and encourage your creativity and industriousness while at the same time expressing the opinion that most of those games probably are best left to be played as designed, even if that means they’re less full-featured than later games.

One could say that about any mod put onto a game. Thankfully just a rom chip swap away using/not using a software mod, or if space allows, making it optional. You might want to poke into the (several, at this point in time) various DickHamill threads where he's got an arduino replacing the games' processor and roms with entirely new rulesets. Most of these tend to be of the mission style type like later games have and I'm with you on that not being in the original spirit - I'm guilty of the 'mission' style type myself on Trident way back in 2011 or so, it actually ruined the gameplay so much for me that I sold the game.

There's no way to know you've "gone too far" until you've actually done it. Chalk it up to the learning curve.

See the bally/williams soren thread as well for changes that are evolutionary and make sense. I think what IdealJoker is proposing here isn't radical at all, 2 ball to 3 ball MB (which I thought the game had anyway.... it's literally been at least 25 years since I've played a JL). The changes he made to pinbot were more radical vs. this.

#14 11 months ago
Quoted from stuliss:

Or you could just trade one of those games for a firepower....

I like FP, but even that game is better with the home ROM, IMO. And the upper-PF 5-bank on Jungle Lord is my favorite trop-target bank in any game (not least because you can't cradle the ball), and I am sucker for drops.

Quoted from PinballBJB:

while at the same time expressing the opinion that most of those games probably are best left to be played as designed,

Thank you for the encouragement. I understand your point and I am not trying to convince anyone of my point of view, which is very much conflicted. I truly admire the games I have been working with and I have never released a patch that changes the game nearly as much as what I am playing with in this thread. What I am trying is to see is what the original hardware is capable of doing.

#15 11 months ago
Quoted from slochar:

I hadn't realized JL was only 2 ball MB I thought it had an option for 3 like Pharoah does. Unless Pharoah also doesn't and I'm misrembering.

Pharaoh is also two ball.

#16 11 months ago

It could possibly work well with Pinbot. Could have a mode where the 2nd ball locked in the helmet closes it then you play the 3rd ball. If you also lock that in the upper left then could release all three. I’m up to help with anything on the Pinbot.

While software only would be awesome I wouldn’t rule out adding a switch if it could use an unused input (original Code should just ignore it) and that is a reversible modification.

Robert

#17 11 months ago
Quoted from zacaj:

So the game doesn't know if there's three balls in the trough when it's first booted?

At the start of the game, it's easy to find out where the balls are if you eject the locks and give it enough time for the balls to drain and be kicked from the outhole into the trough. Now if both trough switches are closed you can check the shooter-lane switch to tell you whether there are 2 or 3 balls in the trough.

#18 11 months ago
Quoted from zacaj:

Pharaoh is also two ball.

See, misremembering it.... you'd think I'd know that since I owned one in 1989. That one didn't last long.

Quoted from Robotworkshop:

It could possibly work well with Pinbot. Could have a mode where the 2nd ball locked in the helmet closes it then you play the 3rd ball. If you also lock that in the upper left then could release all three. I’m up to help with anything on the Pinbot.

They certainly did this with Jackbot didn't they? (Come to think of games' I've not played.... I don't think I've ever played a Jackbot).

Quoted from idealjoker:

Now if both trough switches are closed you can check the shooter-lane switch to tell you whether there are 2 or 3 balls in the trough.

I don't think adding the 3rd switch to the trough would be that difficult, at least it's all routed out etc. for it. Single ball games, yeah, difficult.

#19 11 months ago
Quoted from slochar:

I considered using the outhole on firepower to make it 4 ball multiball in just the way you're intending JL to work

I am almost at the point where I can describe the problem with using the outhole to hold another ball, at least in WMS games of that vintage. It's not that it works any worse than what I have been doing (holding the 3rd ball in a trough location without switch), but I have manged to convince myself that it cannot work any better, either.

#20 11 months ago
Quoted from idealjoker:

I am almost at the point where I can describe the problem with using the outhole to hold another ball, at least in WMS games of that vintage.

The issue comes from having to move more than one ball off that switch when you need to. Double drains will be an issue.

#21 11 months ago
Quoted from slochar:

Double drains will be an issue.

Exactly. But there are solutions. Whether any of them are acceptable to the player is the question. That's what the poll in this thread really should have been about.

#22 11 months ago
Quoted from Robotworkshop:

It could possibly work well with Pinbot. Could have a mode where the 2nd ball locked in the helmet closes it then you play the 3rd ball. If you also lock that in the upper left then could release all three.

I think it'd be better to release the 2 balls from the visor after the 3th ball has left the shooterlaneswitch for longer than xxx seconds, so you know it's been plunged far enough (or when hitting the first switch somewhere on the playfield).

I've added a 3th switch at my Road Kings, but reprogrammed it using P-ROC. I've no idea how it'd work changing original code. Seems hard to me, but the unknown often seems hard .

Edit: I like the idea of a 3th ball in multiball for almost any game. 2 or 3 ball multiballs really feel different I think.

#23 11 months ago
Quoted from sven:

I've no idea how it'd work changing original code. Seems hard to me

It's not any more difficult than any other coding. You have to be comfortable with 8-bit assembler. And with the Williams System 7 - 11 virtual machine (WVM), which is described in Jess Askey's game archive. With my notation, the code that I inserted into the outhole switch handler just before the ball is kicked into the trough looks like this:

_If %closed: SW_leftTrough
begin6800
LDX #three_balls_drained ; execute code for 3rd drain
JSR WVM_spawnThread6800_id06
end6800
_EndIf

What makes modding pinball code hard is that you need to be able to move the original code around freely if you want to insert or delete anything. So what you need to do first is translate essentially the entire game from the ROM image into a format that is both human readable and that you can run through a compiler to re-create the original binary.

Translating the game into a compilable format cannot be done fully automatically. In the code snippet above, for example, no automatic disassembler can know that the argument to the LDX statement is the address of a subroutine in M6800 format. You have to analyze the internals of WVM_spawnThread6800_id06 to find this out. So you need to analyze essentially the entire game code to create a full translation. I have done this for two games and in both cases it has taken me hundreds of hours of serious effort.

There's another reason you need to analyze the game code. The code above has a serious bug: It is not uncommon when you kick a ball from the outhole into the trough that the ball bounces straight back out into the outhole. When this happens the routine three_balls_drained is called twice, which messes up the game. A simple solution consists in making sure that the routine is called only once, which is easy to do with a flag as follows:

_Unless F_three_balls_in_trough                                             ; execute code once
If %closed: SW_leftTrough
setBits F_three_balls_in_trough
begin6800
LDX #three_balls_drained ; execute code for 3rd drain
JSR WVM_spawnThread6800_id06
end6800
EndIf
_EndUnless

Easy enough, but you need to find a free flag, which requires you to know all the flags that are used by the game.

#24 11 months ago

RACE CONDITIONS

While writing/modifying pinball code is not particularly difficult, debugging the code is extremely difficult, especially for multiball games. The problem is that multiple balls zipping around the playfield randomly hitting switches means that almost any sequence of events is possible. This causes "race conditions" which are bugs where you have a set of events that should cause a common outcome, but where the outcome depends on the order of the events in the sequence instead. What makes race conditions nasty to debug is that there are some event sequences that are extremely rare, occurring only every few hundred games or even less. So when you debug pinball code, every new bug is likely related to a recent change you made, but some are related to changes you made months ago.

The outlane code described in the previous posts suffers from a race condition that needs to be fixed before double drains can be addressed. Starting from multiball with 2 balls in play, consider this sequence of events:


  1. 1st ball enters outhole from where it is kicked into the trough
  2. 1st ball arrives in trough position #5, where it triggers the switch handler to re-light the lock lamps
  3. 2nd ball enters outhole from where it is kicked into the trough; a thread is spawned to execute the three_balls_drained subroutine

This is the normal sequence of events for which the code was designed. A less common sequence of events has 3 happening before 2, which happens when the two balls drain one just after the other. In this case, the SW_leftTrough switch is open when the 2nd ball is in the outhole. As a result, this ball is kicked into the trough without spawning the `three_balls_drained' thread. The game never notices that both balls have drained, and no ball is kicked into the shooter lane until you start a new game.

This problem, too, is not hard to solve. I did it with another flag to mark the outlane as busy when the first ball is in the outhole. When the second ball enters the outhole, its handler (at this stage, two outhole handler threads are running) waits until the flag has been cleared. The flag is cleared by the first handler thread 0.75s after the ball is kicked into the trough.

#25 11 months ago
Quoted from idealjoker:

This causes "race conditions" which are bugs where you have a set of events that should cause a common outcome, but where the outcome depends on the order of the events in the sequence instead. What makes race conditions nasty to debug is that there are some event sequences that are extremely rare, occurring only every few hundred games or even less. So when you debug pinball code, every new bug is likely related to a recent change you made, but some are related to changes you made months ago.

One of the things I do when I'm planning modifications is to come up with tests for these scenarios (I had to with Flight 2000 because of all the code rewrite/crunching I needed to do to make space). I almost always spot an error when watching a twitch stream of something from a beta tester even when they don't notice, because even though I try to play in a different fashion that what I'm used to, my style of play on a game is different than other people's, so it's harder for me to just spot new bugs if it's just me.

For your flag finding mission, if you create the threads with different ID's you can use that as a flag, just check for a thread running with that ID, which you ONLY have assigned to the outhole routine - that way you have a built in way to tell if it's running instead of trying to identify a new flag. Finding new flags can be a real PITA when reverse engineering the code - even when writing a game completely from scratch, depending on the system. Some just don't have enough space available for stuff so you tend to get creative sometimes.

All the manufacturers around this time liked to use unused lamps as well for flags since there's rarely 64 lamps (for WMS) used. You could even use the special effect lamp mask and the special effects lamp matrix too for this, effectively getting 3 flags for each unused lamp, since you can test for lamp, mask, or sfx lamp conditions.

#26 11 months ago
Quoted from slochar:

For your flag finding mission, if you create the threads with different ID's you can use that as a flag

Yes, using a unique thread id avoids a flag. Thread synchronization is used a lot in Pin Bot but only in a couple of places in Jungle Lord. The way the thread masking is set up in Jungle Lord means that there are only 15 killable thread ids available, and they are all used. On the other hand, there is a block of 14 unused flags. So in this case it's easier to find a free flag than an unused thread id.

There is another advantage of using a flag. Instead of implementing a spin lock (a loop with a sleep) to wait for the first outhole thread to finish, with a flag the switch handler thread can just exit when the outhole is busy. The ball remains in the outhole and the switch remains closed. In the first outhole thread, which has set the busy flag, just after the flag is cleared you then manually clear the outhole switch. Next time the switch status is checked the system detects a switch closure and spawns a new switch handler thread. (Normally there is no ball in the outhole at this time and clearing the switch manually does nothing.)

This mechanism, which minimizes the CPU load, is used in JL for a super elegant way to deal with "abnormal" ball behavior, for example when a lock eject fails due to a weak solenoid, when the ball bounces back from the shooter lane into the trough or from the trough into the outhole, etc.

I know that it is surprising, but in Jungle Lord every available lamp channel is occupied. Bonus and magnasave lamps use up a lot, but Jungle Lord is also deeper than you think.

#27 11 months ago
Quoted from idealjoker:

It's not any more difficult than any other coding.

Thanks for the possitive response, but reading the posts after, I think it is (at least to me, for now)
Good luck with both your projects: I think a lot of people are happy with software-mods for older games!

#28 11 months ago

DOUBLE DRAINS

Quoted from slochar:

Double drains will be an issue.

As described above the game plays well most of the time. But once in a while, both balls drain simultaneously during multiball. The two balls end up in the outhole before the outhole switch handler fires the kicker solenoid to transfer "the ball" into the trough. There's always a ball in the proper outhole position (#2 in the picture) in this case, and the second ball can be in position #1 or #3. If it is in position #1, there is no problem: the outhole handler kicks the ball in position #2 into the trough (position #5) and the ball at #1 rolls into position #2 -- for the software this is the same situation as when two balls drain in quick succession. But when the second ball is in position #3, both balls are kicked into the trough at the same time. This is the problem: when two balls are in play and the outhole switch handler is triggered, there is no way for the game to know if there are one or two balls in the outhole. After the ball(s) are transferred into the trough, there is no way for the game to know whether one or two balls were transferred, either, because there is no switch at position #4.

Quoted from zacaj:

you could leave a third ball in the outhole, like some later gottliebs did

With this plan, too, you end up with double drains but now the Jungle Lord hardware would have to do something it cannot do: with balls in positions #2 and #3, the game must kick one of the two balls into the trough but not the other. I don't know the later Gottliebs your mention, but if you were to close the side of the JL trough at position #3 maybe it would not be possible for a ball to end up there, in which case this solution should work.

Outhole (resized).jpg
#29 11 months ago

BALL SEARCH

Modern pinball games lose track of balls all the time. That's why they have ball search. So an obvious solution of the double drain problem is to add a ball search. Simple ball searches are threads that run continuously, monitoring the game for lack of switch action. When there is a ball in play and there are no switch closures detected for a time, action is taken to attempt to release any trapped balls. Ball searches are normally paused while either of the flippers is up, potentially trapping the ball.

For what I want to do, I don't need a ball search to run all the time. I only need it to run in multiball when the outhole switch is activated with one ball already in the trough. Once the thread has been started, it first waits for 4s, looking for playfield action, exiting if there is any (because that means that the third ball is still in play). If there is no action, there are two possible reasons: i) there was a double drain, or ii) the third ball is either bouncing around stupidly without hitting a switch or, more likely, it is trapped on a flipper. Unfortunately, Jungle Lord does not have lane-change switches, and so the game does not know whether the flippers are up.

This is the first real problem of attempting this 3-ball upgrade with Jungle Lord: in later games (System 11 have lane change switches on both flippers for the highscore initials) with these switches the game knows when a ball can be trapped by the player. The second big problem is that I cannot chose a longer time for the ball search to wait, because Jungle Lord uses a timed multiball mode. The timer has to continue when a ball gets lost, because otherwise the player could simply trap a ball to pause the timer.

At this point I have two options: I can abort this attempt and try again with a game with lane-change switches. Or i can forge ahead to see if I can come up with an acceptable ball search.

1 week later
#30 11 months ago

This post illustrates the ball search that I implemented to solve the problem of double drains:

  • During multiball with one ball in the trough, when the outhole solenoid is activated to kick one or two balls into the trough, the ball search thread is started.

  • After 4 seconds without any switch activity, the game assumes that there was a double drain and a ball is kicked out from the trough into the shooter lane.

  • If, after kickout, there are still two balls in the trough, there had indeed been a double drain, and all is good. Four seconds are added back to the Stampede timer and the game continues normally.

However, if there is only one ball in the trough after kickout, that means that there was no double drain after all and the third ball is either trapped on a flipper or bouncing about. There now is a ball in the shooter lane that should not be in the shooter lane. The game cannot simply ignore this problem, because if the ball is launched before the other one drains, the unexpected multiball confuses the code.

The first quick solution that I tried to deal with this problem was to turn off the flippers and wait until the ball that's still in play has drained. That was a seriously bad idea - it feels like a (completely unfair) tilt. So I implemented a second solution, illustrated in the short gameplay video below: When a ball is ejected into the shooter lane by the ball search even though there was no double drain (at 00:49 in the video), the tilt lamp starts flashing. Next time a ball needs to be launched (at 1:27) the tilt lamp turns off and the ball can be launched normally. When a ball is launched while the tilt lamp is flashing, on the other hand (at 1:56), this is considered an attempt at cheating resulting in a tilt.

I have test-played dozens of games with this version of the ball saver. The switches must work perfectly, but when they are set correctly I have not had any problems. But I don't really like it. Both the (usually unexpected) ball eject and the blinking tilt lamp are distracting. Since most of the ball saver ejects are false alarms anyway, I think that I may eventually try another version where the player triggers the ball eject on double drains, maybe with the start button. However, the current version works well, so changing the ball search is not a priority.

#31 11 months ago

One pin that should be easy (easier?) to try this on is CFTBL, which already has three balls and used all three in multiball...until the design team decided it was better with only 2. I'd still like to try all 3 balls and decide for myself. If you are able to access a machine at some point maybe you could give this a go. There are tons of mods for CFTBL, I'm surprised no one has tried this.

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