Quoted from Dr_Dude:
The reason Nineball has a ROM revision of 60 (!) is that the programmer for this game (a guy named Robert Quinn) was very inexperienced and did some dumb things in the switch detection loop. Specifically, he looks for switch transitions (going from open to closed), and not switch-states. Thus, if the scanning loop misses a switch transition (because it was busy doing something else, or because the transition was very fast/noisy), then the game-state gets screwed up, and will never "rediscover" that the switch is actually closed. Thus, switch-test is totally fine (the switch is actually registering), but in game-play will get missed.
It wouldn't surprise me if there were 60 internal revisions of 9 ball, but the only released ones ever found are 58, 59, and 60.
That setup would not entirely be his fault, as that's the way all Bally/Stern games perform their switch scanning/debouncing. With few changes (i.e. addition of speech command, addition of 7 digits, and a change in the sound code backend) all stern mpu200 games use the same core OS. If he made heavy use of the delayed switch timing feature Stern games added to be able to deal with delayed events (Bally never bothered to do it this way, and Williams did it another way, thanks to the extra ram available on system 7) even those switch events can be lost.
The part that would be his fault was the whole way the game has to reset the drops, and drop each during every hit. I'm sure on paper the way the ruleset looked was pretty good, but the reset the drops things is really sloppy.
I like how the single drop target if in the state of too many threads running will score and never reset, for the same reason.
At this point I think 9 ball is due for a complete rewrite. Too bad I don't still have mine or it'd probably be in progress right now. It would be a good test of a hybrid OS, Stern backend reading the switches, and a williams-like front end doing the actual processing on them. Requires a new Weebly board with the extra ram and rom capabilities.
The other alternate is resurrection of an old project to recreate the source code for all classic stern games. 9 ball was never gotten around to as you have to start with some and no one volunteered to do it (despite it being one that should be documented, for exactly the reasons you state re: the software getting confused where the balls are).
If this is actually what causes all the woes in 9 ball, it wouldn't be that hard to add a state test for each of the lock and trough switches, periodically compare the states, and when the state changes, execute the switch. (This is how williams' mutliball works.... the trough switches in those games go to a RETURN when noticed by the software, and there's a separate thread that runs watching the trough switches all the time before deciding what to do about it)
Who wants to test any of these ideas on their actual machine? You'd need a rom burner and (possibly) a way to utilize a larger rom footprint, either via the Oliver method, or have a weebly mpu board with the 512 rom capability.