Split off from the 9 ball troubleshooting thread, starting a separate thread to keep track.

What's been done so far:

Complete disassembly of the binary code into an editable, re-compileable format.

Code crunching to make space in the 9 ball rom to improve the ball handling. This is under test right now by a couple beta testers to make sure something isn't woefully broken before moving forward.

This will also free up space to add a playfield multiplier of 2x/3x similar to the Oliver Kaegi mod from several years ago, but without having to use some kind of larger rom and a board mod.... and anything else we can think of. I know people will want the spinner counter as it's been popular in the other games it's been added to so far (meteor and big game).

Documentation of how the game handles the balls right now is starting, this will be the longest phase, and once all variables and routines have been identified, an analysis of what will have to change will take place. Implementation of the changes and testing will commence at that point to ensure the fix is solid before releasing it into the wild, although anyone can grab the beta and try it out.

A conversation with one of the beta testers gave me a radical idea - what if 9 ball was no longer a multiball game and it was just single ball play? I think from preliminary analysis of the code that the game might have been designed initially as a single ball game and they whacked the multiball in there later on - this is COMPLETE wild-ass speculation on my part though, as I do not have any insider info regarding this at all. It might explain why the switch handling is so mangled though.

Because this idea tickles my fancy, in conjunction with whatever fixes for the multiball are come up with, I'll also be producing a version of the game that's just a single ball game. No hardware changes needed to do this - just remove 2 balls (Although I guess I could just write it to also recognize there's 3 balls and react accordingly.) Just a bit of fun, really. People might end up liking it! I've written multiball add-ons for other games in the past so why not do it the other way?

I actually did this with flight 2000 in 2018 in prep for a new operating system I was writing at the time for the weebly board, and it was kind of fun but that exercise was VERY preliminary and never stepped out of the alpha stage - no sound or speech driver existed. I did find out how fast you can move the ball walker though to speed a ball through it.

Anyway, this thread will keep people updated with the progress of the 9 ball fix-up as it occurs as well as any other mods like the single ball play. Any suggestions for updates to gameplay welcomed as well, although I can't promise that any of them will make it into the rom. One I think would be good would be instead of rolling the 173k over back to the beginning, is to leave it there for a little bit and decay it relatively quickly, to 40k, 30k, etc. with each step being lit for 50% longer. Kind of like Stern Star Wars PF multiplier.

https://www.ipdb.org/files/783/Bally_1981_Embryon_Home_ROM_v92.zip

That was done ages ago.

Original 9 ball discussion thread:

https://pinside.com/pinball/forum/topic/stern-nine-ball-left-ball-lock-schematic-needed

Update, error in new code concerning the way continuous solenoids are handled (in 9 ball, some of the momentary solenoids are actually connected to continuous solenoids). Sent the new code to new beta tester - other beta testers if you're still in email me.

Still working on this, slow going as there's really 2 projects operating in tandem on this (it was 3 until I said meteor is "almost done") - as all the crunching techniques to save space in the rom are being added into all 3 codebases. Flight 2000's is the most along in this, but also one of the most broken (meteor is the most stable, and I'm no longer adding in crunch changes as there's still a lot of space available).

Update, a buddy has a 9 ball about 45 minutes away, I was thinking could borrow the whole game which would be a PITA.... so, instead, I'm going to borrow the playfield and drop it into one of my many stern cabs.... probably whichever one's most accessible (probably seawitch, good access from the right side to swap roms continuously.)

I'm at the point where I'm going to pull out all the multiball code, make it a single ball game, and then add back in the multiball handling using ideas I'm cribbing from flight 2000, catacomb, firepower, pinbot, and f-14. This will go much faster once I have the playfield here, and as a bonus any beta code I send out won't completely crash the game like happened in the past.

As a bonus the playfield I'll be borrowing has issues with the 8 bank drops so I can look into fixing that as well. Probably a timing loop that if it doesn't drop the target within a certain amount of time, it will virtually drop it so the game doesn't hang up (like @barakawins1's game did in the original 9 ball troubleshooting thread that spawned this software project)

Playfield installed in cab, testing.

Managed to accidentally duplicate the original issue Barakawins1 had with the 8 bank trying to drop a target - in this case, the target was already down (the 8 bank on the pf I borrowed has issues with resetting drops, perfect for this testing). The game hung up just try to 'drop' the 6 target even though it was already down. So, I'll have a way to tackle that (the game itself tries to reset the drop switches, but it's clearly failing here.)

I've doubled checked one of the new functions I wrote to check switches easily which had failed in crunchtests before 5, which should help with this issue. Don't trigger the drop if it's already down. As an offshoot of this, draining on a lit outlane which awards the loop value no longer resets the single drop if it's up. I always thought that was odd.

I've also played around with different switch things for ball end, etc. just trying out ideas. Already gotten rid of the shooter lane nonsense where if it doesn't see the switch it launches another ball (i.e. the trust level of the shooter lane switch is greater than the trough switches)

Oh, and the newly-popular spinner counter is in there It's nice because there's already timeout code in the game to remove the spinner lamps which I repurpose to put the ball in play back on the display.

Free play also implemented, dip 19 turns on/off.

Code has been sent to Coyote to post here:
http://tsqmadness.com/games/roms/index.aspx

Version reports on bootup as "11", should fix the go into the saucer and nothing happens because either the target doesn't drop, or it was down already and didn't reset properly.

Add bug reports on this version to this thread.

There will be 2 versions I never intended to remove the multiball on all the versions.... just one to see how it plays. One of the reasons I got rid of my 9 ball in the first place was that I didn't see any point at all to getting multiball. There's nothing extra to shoot for, there's no points incentive (unless you're using the Oliver variation), and it can be detrimental, in that you might hit the advance 173k loop when you don't want to (or it does it for you, since it's advancing it as you're exiting the lock lane). Or maybe a ball tags the fully lit spinner when it shouldn't.

So I'd like to learn the game instead with a different perspective, removing the carrot of "go get the multiball" to other goals. (I don't know what the tournament set even goes for on 9 ball but I'd suspect it's either the 173k or the spinner.) Maybe it's fun, maybe it isn't. I won't know until I try it. Nothing in most of the code screams it was designed as multiball so maybe Rob Quinn designed it from a single ball perspective and tried to add the multiball back in later because it really appears that way in the code. It's like he kept adding flags to try and fix all the possible scenarios without rolling some things back and starting fresh. Maybe that was the development hell that existed at stern at the time, maybe it was something else. All I know is that balls shouldn't end before they're supposed to, extra balls shouldn't be ejected into the shooter lane, a single drop being down and never resetting should never happen, and a ball in a saucer shouldn't just sit there forever because a drop bank doesn't operate correctly.

It probably was sacrosanct to not change the OS routines at the time since all of the changes I made to it to make space to implement the bug fixes basically came from the OS. No other games seem to monkey with it too much either, again probably for reasons of time.

9 ball multiball would be crazy and clearly a gimmick just like it is on Apollo 13.

The only rules change I'm contemplating is the playfield multiplier during multiball, and that'll be tunable with a dip switch. The original thinking of changing it to one ball was strictly to see if it played better and as a development version, to fix all the bugs with a single ball to worry about, THEN add in whatever the new multiball handling might have been. Not to fix all the bugs by making it a single ball version only - the single ball would be an offshoot for people who wanted to try something different. I didn't plan on putting a lot of effort into it, that's for sure.

Anything anyone doesn't like could be removed later since I plan on releasing all the source code changes.... there's already directives in it to add/remove various things.

Fixed an issue where the drops were up and wouldn't drop (had fix already for them being down and marked stuck in the switch matrix, which is another hang up)
Doesn't reset the single drop if it's not down
Resets the single drop at ball start (surprisingly the stock code doesn't do this, unless it does it somewhere I didn't trace through)
Balls come out of the lock at game over (all, not just one).
No more of the shooter lane foolishness - if all 3 balls remain in the trough, it WILL eject another one after a short period.

Played with some of the ball handling, it's not "correct" yet, so v12 won't get posted until I at least have that going. Trying the first of many experiments to get it correct.

I guess 9 ball has the ball re-lock during multiball behavior - will probably add an option to flow through instead of relock.

I have the 2x/3x scoring implemented in the backend - it will blit 3_ or 2_ to the ball in play display when active. Nothing in the foreground starts it yet though, but it's all set when that's ready.

This is still in progress it only looks comatose - I'm just doing 3 mpu200 things in tandem (f2k, 9b, and galaxy). One idea feeds another so I like to keep busy. Then when I'm burned out I look at Williams Pinbol stuff as a break from the routine.

I am trying ideas on the trough stuff, to ensure that the ball/game doesn't end before it should. The switches involved will still all have to work properly, but it should handle the timing better. I need to write a sampling switch function for it to be 100% reliable. I should have plenty of romspace to do this (last time I checked I wrangled 200 bytes or so out of the codebase) but I just need to get down to actually doing it and testing it out. The first several tests were a dismal failure as the ball either never ended, or ended even more prematurely than the stock code did....

I think the 8 bank switch handling is licked, though, as it will survive drops that are down but the game doesn't realize it, drops that didn't drop physically, and the single drop as well shouldn't get stuck down either.

Yes, I already have the code clearing the lock completely out at the end of the game. I don't think they actually intended the lock to be cleared at the end of the game, though, I think they did the single eject so the switches would get triggered again to correct any flags that were incorrect. They actually check for this condition after firing the first one out.

It really lends credence to my theory that the software wasn't written with multiball in mind and they whacked it in later - even if Steve Kirk intended it to be multiball from the beginning, the software I think was written as one ball and the multiball code added in, which is why it's buggy.

https://sites.google.com/site/allentownpinball/galaxy-asm/nineball-beta.zip?attredirects=0&d=1

Latest subversion .18

This is BETA software - try and catalog errors and post here or email address in readme file

versions for mpu 200 and weebly board.

Handling of the 8 bank when the ball goes into the capture lane should be spot on now
Still have to investigate and change behavior of the outhole/shooter lane.

Not yet. It's in the backend but nothing activates it yet.

Just getting the drop bank spotting going regardless of the status of the switches (if it misses a switch on your 8 bank, the game just sits there because it doesn't know what to do.... that's fixed.) is the main thing so far. Testing of several backend support routines and crunch-down routines (even with added stuff in the code, there's about twice as much space free right now as stock) is really what these updates are about so far.

The game/ball ending early things are the next group of concentrations, and then the fun stuff of the added items will go.

Oh, and the spinner counter is in the current .18 - always fun to see how many spins you get.

Lots, but it's all in flight 2000

The experience gained there with the ball coding will transfer over to 9 ball once I'm ready to really rip that out. I think the 1/2 of the biggest complaints is licked though, where the targets that don't drop just stop your game cold.

Need more people to download and try out the beta to make sure it's solid there, although one of the beta testers put slips of paper on the random drops to make sure it handled it and it did so I think that's a pretty solid test.

It should play like the original since nothing gameplay wise is changed.... just a fix for the 8 bank, the single drop, and clearing of the lock at the end of a game. And the spinner counter.

It's probably more accurate to say "nine ball bug fix" instead of "rewrite" since it's really taking what's there and tweaking it.

The 2 regular beta testers haven't reported any issues after the drop handling was added.

http://tsqmadness.com/slochar/ZIP/
updated link

You can use the weebly version if it's truly reading as 512. Iirc the mod was for 256 chips in which case you would just make sure you copy the top eight bytes from the image to the top of your 256 image and it should work.

Not to mention that barakandl will likely just add it into the combo rom, if it's not already there.

Alltek wasn't 100% closed off to the custom software idea originally - he was going to make a 'classic stern' version of the rom (to get freeplay) - his eprom doesn't have enough space to host all different versions of roms that are out there (there are some custom bally games contained in it, for instance). I talked him out of having 2 different versions of the board, that would just sow confusion.

What he needs to do is redesign the board to be able to take either another small eprom or to have a larger one already there. He did refuse to divulge the format the roms were in (it's not too hard to figure out if you dump the rom) but the indication that the warranty is voided will stop a lot of people cold.

He's got a product doing it his way that's fine. I know people still consider it the gold standard of replacement boards, and the pricing reflects this. If people want to indirectly fund the product that actually enabled easier programming, buy Andrew's board - without him adding the 512 socket and the extra ram, both of which I used to develop the fixes (the stock roms in a lot of games are already full, so there's no way to add debugging information without going outside the normal romspace, or cutting something out temporarily and adding it back in later. Kind of a PITA.

Since it's semi-related, I wonder what Alltek's feeling would be about adding on the arduino setup to their boards? It does work as indicated on all the DickHamill threads. It's a tough situation to offer a lifetime warranty and then have people hanging extra hardware off your product. If I sold hardware I wouldn't warranty the crazy stuff people hang off their games. (me included)