Gottlieb (Premier) Victory competition/tournament patch to improve scoring

One of my favorite locations to play in Indianapolis (PinVault) has a Gottlieb/Premier Victory that seems to have a cult following (one that I’m a member of). When playing competitive 4-player games, we’ve been burned by the checkpoint scoring issue described in an earlier post.

Out of curiosity, I started disassembling the ROM and I have some ideas on how to “fix” the issue, but wanted to get feedback from the community to see if there are better options.

Summary of Issue
This game has a sequence of “checkpoint” shots to hit. Completing a checkpoint lights the next shot with a hurry-up. On a 3-ball game, the hurry-up value starts at 100K and increases by 100K. On a 5-ball game, it starts at 50K and increases by 50K. Early checkpoints have a slower decay than later checkpoints.

The initial “race” is referred to as a qualifying heat. After any “driver” (player) completes the race by hitting the last checkpoint shot, checkpoints start at a fixed 800K (3-ball) or 400K (5-ball) value for ALL players. This gives a potential advantage to other players because everyone benefits from the increased hurry-up values.

Additionally, whenever someone completes a race, all players get reset back to checkpoint 1.

Simple Fix
Based on my understanding of the code, it would be simple to track each player’s completion of the qualifying heat separately. After making that change, a player would need to finish the qualifying heat to max out the hurry-up (800K/400K).

Options
With that scoring change (each player needs to complete the qualifying heat), is it “fair” to reset all players back to checkpoint 1 when someone crosses the finish line?

Should checkpoints after the qualifying heat stay at a fixed value, or continue to increase?

Details
This game uses 32 dip switches for configuration, with all switches in use. 15 switches are dedicated to setting coin chute pricing. I could repurpose some dip switches to selectively enable changes. Is that worth implementing?

Should I could change the “TEST MODE” text to include a version/revision number to aid in identifying that it’s running a modified ROM? One of the test modes displays a checksum of PROM1, which could be used to identify the revision.

Are there other scoring imbalances to address? I know a common strategy is hitting drop targets “up top all day”. Would players be more likely to go for checkpoints if completing the qualifying heat didn’t benefit all players?

Do we need spinner rip counters?

Have other people released updated ROMs for Gottlieb 80B games? Should I coordinate my changes with existing updated ROMs?

Copyright and distribution
I could make these changes for personal use, but distribution of an updated ROM seems impossible based on how the owner of Gottlieb’s intellectual property currently prevents distribution of manuals and ROMs on sites like IPDB.

Early Soren ROMs were released as a patchset that required original ROM images. Is this a feasible way to get updates out? The changes would be in PROM2, and would probably require an update to the PROM2 checksum stored in PROM1.

1 Like

no each player has there own progress.

I think just free play mods for all of them.

also any way to add real Multiball to this game?

I’ve seen the free play mods, and would consider integrating that or re-implementing a version of it myself.

I think that’d be really difficult, and require significant changes to outhole/trough handling. There’s only one trough switch, so you’d have to keep the second ball waiting in the outhole until you have a switch hit on the playfield. With two balls in the trough, you’d have problems if the trough kicker failed to serve the ball properly. It could also get ugly if the second ball drained before the game could get the first ball transferred from the outhole to the trough.

I think that there are also times in the game where it holds the ball at a VUK and performs light shows without checking other switches.

I’ll leave a possible multiball to someone else, perhaps using an updated controller that isn’t constrained to 6502 assembly.

Test mode text describing change = absolutely. Otherwise no one will ever know what’s installed or that’s there’s something different. You should add it to the text that scrolls on the display as well during attract mode.

Dip changes = (especially to coin dips) - operators’ feedback on doing this is clear, DO NOT change options where there is money concerned! (if at all possible).

As for the actual fix, if you can track each player for the finish of the race, yes, do that, but a simpler fix might be to just never increase the checkpoints and give a score for finishing instead. As for one player’s finishing resetting everyone, I don’t think that’s fair at all. Nothing one player does on their ball should affect another players’ ball/status if at all possible (stuff like lock stealing should be minimal, but single ball game no worry there). The playfield field in a contest should be as level as possible.

After watching/participating in many tournaments and participating in many rom changes, I’ve found that unless there’s some overwhelming reason to do so, the players will STILL use the tried and true safe strategy. Now, if the game becomes more balanced because of the changes, AND you still can do that preferred strategy, you’ll have an edge on winning.

For the patches, always release patches for each rom detailing what’s in each patch. (Even if it nothing changes, make it clear what rom to use) Checksums before and after would be helpful as well.

The simple thing is would be require a multiball trough upgrade for these types of changes. That’s what all the other MB added games do, even if it’s something simple like adding a switch under the apron for the 2nd ball.

what about adding tilt warnings?
no system 80B games have them. But other games at the time had them.

This game was not designed for multiball. The only reason it has a multiball trough setup is for the lower eject to capture the ball when lit for extra ball (in addition to the normal extra ball award, you get what’s effectively a ball save when the ball in play drains as the captured ball is then kicked out).

I’ve completed an initial version of the patch, which I was able to test on a physical pinball machine (in addition to Visual Pinball testing).

I’m releasing the patch as a Python script that modifies the ROM files, but I’m open to using other common tools. I think Python 3 is probably present on more systems than a binary patch tool, and it allowed for me to verify checksums of the original/patched files.

This first version just fixes the competitive play issue. Only the current player resets to checkpoint 1 and gets credit for finishing the qualifying heat. It identifies itself in self test by replacing the TEST MODE text with VCTRY 1,01.

Download from my gottlieb-victory-patch GitHub project. Please leave feedback here, or open issues on GitHub.

Good work. (re: python - I don’t think it’s on most people’s systems, though… a patch that can be applied with an online tool or something reasonably well known like IPS is the way I’d go) - but I’m sure a place like vpinuniverse will get the patched file lickety-quick. (Actually you could probably just u/l it there anonymously, don’t know where they’re hosted, but they have tons of gottlieb roms on there.)

Nice to see someone else’s python work that you clearly know more than I do about higher level stuff - mine looks like basic :slight_smile: and all the yuck about that implies.

and it may showup as an full rom in the mame / pinmame rom sets after this mod is added to the next pinmame.

Thanks for the guidance on IPS files. I wasn’t aware of that as an option, so I manually created IPS files using an online tool and added them to the repository. If I decide to extend the patch further, maybe I’ll have the Python script generate IPS files along with the patched ROMs.

hey Tom! What EPROM chip are you using for your patched ROM files? The 2332 ICs for PROM1 and 2 aren’t available as an E/EEPROM.

I used an AT28C16-15PC for the 2KB ROM and an AT28C64-15PC for the 8KB.

A quick note to anyone using the v1.01 code:

I’ve been making further annotations to the disassembled source, and I found another scoring issue to address. I fixed the issue of all players resetting to Checkpoint 1 after any player completes a race. And for those players getting credit for finishing the Qualifying Heat, which got them one race closer to lit outlane specials when outlanes are set to conservative.

But there was also code to re-enable the checkpoint hurry-up at the start of the other players’ next ball. Which means that a player could start their ball 2 or 3 on a new Checkpoint 1 with an 800K hurry-up if one of their opponents completed a race.

I’ll be releasing an updated patch after performing some more testing. I’ve also been working on improving the Race Bonus scored at the end of ball, or when hitting one of the two shots that have a RACE BONUS lamp lit.

The original code awarded a multiplied 10K * the current checkpoint number. I’m testing code that will award a base 50K plus 50K for every completed checkpoint. So if you’ve finished a race, your end-of-ball bonus is a multiplied 450K.

My goal is to make hitting checkpoints more lucrative, encouraging players to shoot the entire game instead of just pounding away at the drop targets on the upper playfield.

2 Likes

I’ve released v1.04 of the patch to my Github gottlieb-victory-patch repository.

  • Removes the code that re-enabled the other players’ checkpoint hurryup at the start of their next ball.
  • Increases the bonus awarded at end of ball and for lit RACE BONUS shots to 50K/completed checkpoint (multiplied).
  • Awards 500K (multiplied) when completing a race (shooting the final shot at the left orbit).

This was the version of code running on Victory at INDISC 2025. Thanks to Jim for the feedback and encouragement to make more improvements! I still have some other ideas brewing, so keep an eye out for future releases.

5 Likes

New code ran very smoothly at INDISC!
The game is getting better and better!
Awesome Easter Egg as well. :slight_smile:
Thanks a million Tom!

4 Likes

I’ve released v1.1 of the patch, which maintains FINISH lamp status between balls. Those shots build the multiplier, but are risky to shoot intentionally. Most players ignore them because progress resets between balls. In the playoff match at INDISC, the top score was 25M but none of the players reached a 2X multiplier.

On a 3-ball game, there’s only two times that progress will carry over (ball 1->2 and 2->3), so there’s a limited impact on scoring.

I’m thinking about implementing Free Play next, and opened an issue on the GitHub project to track that request. Here’s what I wrote:

The challenge here is identifying a dip switch to repurpose for enabling this feature. I think that switch 30 is a good candidate – it adds 9 credits on the 3rd coin chute when turned on, otherwise has no effect.

I could patch the ROM so that switch enables Free Play instead. The ROM supports a maximum of 20 credits, and the existing coin chute configurations allow up to 10 credits for a coin. Would there be an actual location accepting payment that would need a way to offer more credits on a single coin drop?

With Free Play enabled, I’d disable the credit display or replace the number with an asterisk (*), hopefully making it clear that the game isn’t configured for credits.

1 Like

the free play mods that have been done all ready.

I’m aware of those mods, and I guess I could integrate them into my patch with updated scoring. Their patch adds 21 bytes of code to PROM1, and I have room for that.

I’m surprised that their option of enabling free play when all pricing DIP switches are set to OFF has worked well. Those settings would be for “1 coin/credit” on all three slots, which seems like it’d be a common setting.

I still want to adjust the credit display to show a “*” instead of the credits, so there’s an outside indication of the game being set to Free Play.