manual page 17 has the wire colors and connectors for the switches

If you need the mpu200 schematics the seawitch ones on ipdb have good scans

What information isn't there in the manual?

switch 34=lock lane kickout, strobe is yellow-red, diode---|>---, switch, return is grey
switch 38=lock lane middle switch, strobe is yellow-red, diode----|>----, switch, return is white-brown
switch 39=lock lane top switch, strobe is yellow-red, diode-----|>-----, switch, return is brown-yellow

While the online manual is missing the playfield schematic, as slochar said the wire color info for the switches is actually there. See the first diagram.
The second diagram is the playfield switch schematic that frunch posted here at some point or another.
Last diagram is the lamp driver board schematic if you need it posted by @gabegabegabe.

[Edit] Actually the playfield switch schematic and lamp driver board schematic came from this thread - there's also the playfield lamp info there too:
https://pinside.com/pinball/forum/topic/wanted-schematics-for-cosmic-princess-nine-ball

NineBall_Switches.jpg
NineBall_SwitchMatrix.jpg
NineBall_Lamps.jpg

Sorry I've never seen or played the game so have no data here.
Why don't you post pictures of those switches in the left ball lock area clearly showing how they're wired in case we notice something obvious?

Sounds like the ball isn't being registered at the hole it's stuck in. The second ball isn't being shot into the shooter lane because the saucer isn't registering. I don't have the game but the last strobe line ST4 E has the outhole switches in them. Put the game in switch test and make sure that switch works at that saucer. It might just need adjustment so it makes contact correctly. Might be a loose or unsoldered wire at switch or the 1N4004 diode on the switch.

Also, just in case, make sure you have the latest rev of software in the game (Rev 60) - it still has bugs with the ball locks, but not as many as earlier versions. (When I got my Nine Ball at an operator auction, they had electrical-taped thin cardboard over the entire left ball lock lane, so balls going in would just pass right out again...about the only way to keep on running on location without Rev 60 software!)

Also if your big drop target bank has problems, balls will get stuck in that lock - it MUST see the "current ball" (blinking light) target go down (go from open switch to closed switch) before it will kick the ball out.

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.

In addition to making sure the switches are adjusted properly and contacts are clean, you need to make sure the diodes are good. Some theorize that adding a capacitor to certain switches can help, but I'm not so sure about that. There also exist updated, privately produced "fix" ROMs for this game, and those are worth a try too. Good luck! Nineball is super-fun when it works (which it did not in the arcades when released, which resulted in operators dumping them in droves).

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.

I Dont think the sling switches have caps do they?

Quench your lamp driver schematic while saying nine ball is actually for flight 2000...

here is the corrected one someone sent me a while ago

NineBall Lamp matrix (resized).jpg

Even if this fixes your issue I'm going to move forward with the rom deep-dive and make a run at the core issues with the switch handling. I know Oliver did this years ago, but that fix needs some kind of rom expander to work. I'll see if I can shoehorn it into the normal rom footprint and take a different pass at it.

Really nice! I had the oliver rom in my game and it’s a big improvement, like it. I will really appraciated if you redo it Scott. Thank you

This is the pics i found in my playfeild swap file

1F19A1DA-38B3-4731-99C1-58AA54559623 (resized).jpeg

29C505FF-BF0E-4A15-9247-6185B236ADD3 (resized).jpeg

9FA3EF9E-C537-497E-8231-20ED6E04F158 (resized).jpeg

A07B1392-C0E0-4661-9CCE-1A1838877446 (resized).jpeg

E9F462A8-B6DA-4EB4-8C34-5F7ABFDBD76B (resized).jpeg

Some of the left side of your diagram is missing.

Here is the left hand side of the drawing showing the right hand sling shot solenoid. Unfortunately, while I can see the right hand sling solenoid coil I can't find the left sling solenoid coil in the drawing.

Both sling switches are in column D of the switch matrix.

I am going to life my play field and look at the left sling shot wiring. I can't believe the left sling solenoid has been left out of the print but I am not seeing it at all.

Screen Shot 2019-11-14 at 9.57.12 PM (resized).png

Nine Ball playfield 1:4 (resized).jpg

Screen Shot 2019-11-14 at 9.46.21 PM (resized).png

EDIT: I see the left sling shot coil way down in the lower right of the diagram.

the brown wire will attach to one of the switches with the orange wires. A Brown/white wire will attach to the other set of switches.

I can get you some pics tomorrow. I have to shuffle a couple of pins and remove the glass.

Ahh crap, thanks for the reminder. Somewhere I modified another lamp driver board schematic and made one for Nineball - now I gotta find it..

See below:
Nineball_Slingshot_Wiring1.jpg

Yes, diode orientation, capacitor and white-yellow wire locations look correct.

Yup, I know - the guy that sent it to me only sent that part!

The info I actually need on it is the lamp assignments to decode the software (you can tell what the code is doing based on the lamps it's lighting/unlighting) - that was my focus.

Didn't help the OP if he was looking for the solenoid wiring though.

Somewhere I have a 9 ball manual I'll have to dig it out and see what's in it.... at least I think I have a manual.

Hmm...I didn't have a cap there, so I added one and it didn't help anything

What are you trying to fix?

I had this discussion with someone here a few years ago who was certain that Stern fitted capacitors on the slingshot switches. Stern schematics don't list them though. All my Sterns are in storage so I can't check.

I had a lot of weird Switch matrix probleme with my Nineball after my playfeild swap... I had to change a lot of drop target switch...

https://pinside.com/pinball/forum/topic/classic-stern-problem-nine-ball-switch-matrix#post-4859422

Maybe that can help looking somewhere else

Just from a preliminary disassembly and glance at the code I can tell there are definitely some errors in it - there's a couple of branches into locations that have no valid code. Investigation continues....

Early code from every manufacturer has errors and quirks in it - for instance, different compilers were used and some of them compile the code into 3 byte (extended) for a zero page instead of 2 bytes.... sometimes different in the same object code. I have to manually tweak each of these to have them assemble with my "modern" (ie. 2006) cross compiler.

The short-term goal is getting the code base to compile true to the original before any documentation and modification occurs.

I always thought the business with the drop bank going up and dropping a bunch of targets was very clumsy and cumbersome and it's something I'd like to change - but wondering how and still keep the spirit of the rules the same.

I forget if the bank resets and re-drops your progress on EVERY hit, or just on valid hits to the next ball? So if you have 1 and 2 earned, and you hit 5 instead of 3, does it reset? Or does it only reset when you hit 3, with 5 remaining down?

Exact same problem as OP.

Go to switch test mode.
Raise all the drop targets and remove all balls from the playfield first.

The game should report "0" in the ball in play display indicating no closed switches. If not, let us know what switch number the player displays are reporting.

Using the switch identification tables in the manual (paper pages 17 & 18, PDF pages 18 & 19), activate each switch one at a time but do it in REVERSE order listed in the manual - i.e. start at switch 40 and work your way in reverse sequence to switch 1. It's important that you do it in reverse order because the game only reports the lowest switch number that's closed.

Leave a ball lying on any outhole/saucer switch after you activate it, ditto with the drop targets leave them down after you drop them.

Let us know if and which switches indicate the wrong number so we can try and work out if there's a switch matrix issue.

The bank can reset (put up) ALL of the targets, and it can knock down single targets (except the 8).

Each time you hit the "current" ball number (the one with the blinking light in front of it), it resets the bank, advances the current ball to the next highest number, and then knocks down each of the targets lower than that number (one at a time) in order.

Several things on the game spot the current ball, so those will knock down the blinking target, then reset the bank, and then knock down targets as described above.

So it's like the pool game Nine Ball - you have to hit each of the pool balls in numerical order. No penalty for hitting higher numbered balls (drop targets) along the way, but you don't advance the number until you hit the blinking one. The reason the 8 doesn't have a kick-down relay is that when you hit the blinking 8 target (the only target standing in that case), it resets the bank and leaves them all up, and the 9 Ball is now a virtual target - it marches the light down the bank in order, and you have to hit the lit/flashing one to score the 9 Ball. This gets harder as you hit down wrong targets, because then the current 9 Ball can be a target that is no longer up and hittable!

SO, sorry, as weird as it is for that bank to be flailing all during the game, that IS the game - the rules demand it. That's Nine Ball. Steve Kirk was a genius.

So, in answer to my question, it doesn't reset the drop bank when you don't hit the current ball number.

My only interest in the game is fixing the software.

In game mode, does the ball get stuck in the left lane saucer even when ball capture isn't lit? i.e. when it's not supposed to be locking the ball?

What happens in game over mode if you take a ball from the outhole and roll it into the left lane saucer? Does the game kick the ball straight out? it's supposed to, in order to make sure all balls are back in the outhole trough area and ready for new game. Or does the ball just sit in the left lane saucer?

Update on code:

Codebase is disassembled into stern pigs macros and compiles successfully. Now documenting flags for the code and thinking about possible solutions to the ball handling, as well as crunching the code down as much as possible so it continues to fit into the 2x2732 eproms. Might have to sacrifice some things to do, there's not much free space in the stock footprint.

I can see they tried to implement a williams-like approach to the trough switches and keeping track of balls. The thing I remember most about the flaws in the game were that the mutliball would end early, or the game would put 2 balls into the shooter lane at times. Williams solved this kind of issue with careful switch timing/checking coding. (Stern solved this later on in Catacomb, when I had a catacomb, it was very difficult to get the ball logic fooled. Now, if I had catacomb completely disassembled as well, I could just look and see how they did it there. It MIGHT be the different trough design with the vertical switches. Flight 2000 seems to be ok too, but that software was written by Pfutz and he certainly did things in a different manner)

Very interesting. Yes, Catacomb seems to be pretty solid in multiball handling. Would love to try out an improved/stable Nineball code-set.

BTW, I maintain a cheat-sheet on Classic Stern and Bally pinball information, and I include the designer, artist, and (where known) programmer names for each game. I was unaware that Bill Pfutzenreuter programmed F2K (I had him down for Seawitch and Iron Maiden), so I've added that to my list. How did you determine that he programmed F2K?

https://ipdb.org/machine.cgi?id=887

He's listed as such on IPDB.

Also, the way it's coded leans towards him. I didn't realize he coded Seawitch as well I should really take a deeper look at some of these. He definitely has a style that comes through in the code from classic stern all the way up through the system 11 stuff.

I don't see him listed for Iron Maiden, but it's showing he did Quicksilver as well. Of course, IPDB could be wrong (for instance they insist on keeping the information on 9 ball saying it has mpu100 version, impossible, and that there were 60 revisions of code. This was printed in the Pinball: Lure of the Silver Ball book which is full of lore similar to saying George Washington cut down a cherry tree and didn't lie about it. There have only ever been 3 versions of 9 ball found in the wild, 58, 59, and 60. Developmental versions for ALL games are 60+ revisions... they just are. Probably more accurate to say that there are 600 revisions for each game.)

IPDB sources its info from the public so it's a little better than a wiki but still the facts need to be verified. I've not heard or seen any interviews with Pfutz but I'd love to bs with him for hours sometime. I like his elegance in some of the ways he did stuff. As far as sheer audacity goes though I like Eugene Jarvis' style, he has so many moments of obvious impatience and hacks getting his cool stuff going that it ends up being admirable that it actually works as well as it does. AFAIK he generated a lot of the classic williams sounds back in the day by typing random crap into the sound generator and noting the results.

Thanks, I use IPDB.org as the definitive source on most things (except Catacomb production numbers, though they seem to have removed that clearly erroneous 3,943 number), but must have missed F2K somehow. Very cool that you can see the "tell" of individual programmers in their code!

Since you have brought up Catacomb, during Catacomb multi-ball if a ball lands back in the saucer it stays there, which sort of diminishes the effect of multi-ball.

Would there be any way the code could be changed to force the saucer to kick the ball(s) back out onto the play field during multi-ball?

When you're recreating source code, you recognize 'signatures' in it.... and specifically for williams stuff, you can tell who really understood APPL and who didn't. It comes down to who respects the structure of the programming environment and who ignored it. I don't think they had code auditors then (or even later) who looked at the code and said "now, this is poor programming practice to do it this way, you should do it the way the coding bible says to....."

You can really see it in the way they did optimization, shaving bytes here and there.

Of course. Anything can be changed. I wish people would start requesting changes on games I still have so I don't have to depend on others to test! Lightning needs this fix, too.

Ah, I could play "boy, I wish I kept this game...." as I had every single one of the mpu200 series at one point except for Iron Maiden and Ali, all lined up in chronological order. I've even forgotten some of the romhacks I've had my hand in and people have had to remind me. Thankfully gmail keeps email forever or I wouldn't even have copies of some of them.

You get an eprom burner yet so you can beta test this stuff or do you have someone close that can do it? I recommend everyone get Weebly's mpu board so you can use the 27512 eprom socket, they burn quick, they're cheap, and it's a lot easier to do one chip vs. 2 every time you need to change something. I burned 6-7 chips in about an hour yesterday testing ideas out on Meteor. My top spins on Meteor so far are in the 70-80 range

Booo! No way man that's part of the game.