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

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.

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.

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.

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?

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.

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)

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.

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

I'm moving even farther into understanding the codebase. The guy that wrote it was incorrect on how some of the operating system works (he's trying to catch momentary switch closures instead of looking in the history register, for instance, to keep track of balls). As soon as I figure out what flags should be set for which modes I'm going to revamp the entire way it's set up. Right now it's just a kludge. You can tell it didn't work right in testing and they just shipped it when it was "good enough".

I do have to wonder if another programmer was helping out as there as 2 different coding styles evident in the code.

Here's the code snippets in question:

L5B3E:
enable_solenoid_06 $14 ;outhole
enable_solenoid_0f $3c ;time waster
enable_solenoid_0f $00 ;time waster
loadb $ff ;wind timer for this routine
storebmem $0063 ;save in timer for virtual col6 row0

So, when the ball is launched out of the outhole, it wastes a little time enabling a non-existant solenoid (why stern never seemed to use their own "delay" function I'll never know), then it sets a timer to start this routine again.

Here's the shooter lane switch routine, in its entirety:

;shooter lane
L5B83:
loadb $00
storebmem $0063 ;clear the outhole virtual switch timer
return

All it does is negate the re-entry of the outhole switch. Incredibly stupid to rely on the one switch for this stuff.... I mean, there's 3 switches right in the trough that you can test instead to see where the balls are! Meanwhile, there's code to use continuous solenoids as if they were momentaries.... but depending on the same technique of delayed reaction. It is actually possible for timed switch events to get missed, and if this happens, the solenoid would lock on. There needs to be some monitor program that can watch over all this stuff and restart it if something goes awry.

Shooter lane switch misadjusted or stuck closed in any way, messes up the outhole (and by extension, the ball count... although I don't think the ball count actually counts the shooter lane....)

The challenge will be identifying all the flags and what their purposes are, and fitting any kind of fix into the romspace available. There already several places where they jump to the next instruction (waste of 3 bytes), or there's duplication in code blocks that can be streamlined if needed.

The slowest thing is the erasing but I can do 40 at a clip so that's not too bad. Eprom emulators are too damn expensive!!

Now, if you have some kind of debugging setup that I can attach to an actual machine, that would be helpful. Although a moot point since I don't have access to a 9 ball machine.

Lots of people don't want to get into burning eproms I run into it all the time... or the other saw that people play is "it's not from the manufacturer of the game so it's not good so I'm not going to install it". As we're proving from this 9 ball exercise (and you probably noticed as well if you went 100% into the code way back when) is that just because you worked at a pinball company, doesn't mean you knew what you were doing.

Eproms burners are ridiculously cheap today and in the case of the minipro I'm currently using, fast enough. 2732's burn in 20 seconds or less so the eprom emulator wouldn't do much - unless you have a wireless setup that I can leave installed in the machine and squirt code via wifi down to it! THAT would be a game changer. Although since I'm working on 5-6 games at a clip maybe less so.

I do automatically install a ZIF socket in every MPU board I have though.

Thanks for describing it farther so I know what to add.

Have you replaced those caps? They sound too sensitive.

The extra ball coming out in the shooter lane is a symptom of the software issues I'm still looking into.

Added these to the list of things to do. The game should be able to deal with multiple switch closures without going crazy. They test the switch for debouncing and then forget that they did so, and randomly will do it again.

Since I just wrote a 'test_switch_closed' routine for my new meteor code, I'll be able to add that to 9 ball as well - the really large issue is that semi-large swaths of code might have to be written unless all of the switch testing 9 ball currently does in assembly can be converted to my new function I should end up with some space then. After 5-6 switch tests I'll be ahead of the curve since the new function will be 'test_switch_closed switch#' and then a 2 or 3 byte function to react to it, instead of lda $34 ora $39 anda #$03 cmpa #$03 bne somewhere which is what most of the switch tests currently are. (10 bytes). I tagged into the checklamp function to be able to do this but I'll need a free ram byte somewhere.... which I can probably pick up after I rewrite the lamp blinking routines which hog 5 bytes they don't even use (they're as if flags need a blink matrix.... they don't.....)