It's not just a dip switch other things have to be changed as well because of the differing playfield layout. (Skill shot, possibly quickshot) I have not looked too far into that stuff yet.

Can a gammatron owner go into switch test and test all the 'letter' switches and let me know what switch # they are? I think they did some rewiring when they made the PF vs. Flight's and I want to make sure I change the skill shot and quick shot stuff correctly. Also, since gammatron has that extra entrance to the maze from the pop I'll have to make sure that scores all the time, not just after 2 locks.

For instance, flight's switches are:
B 24
L 23
A 22
S 21
T 20
O 19
F (right) 18
F(left) 17

So gammatron:
G ?
A ?
M ?
A ?
T ?
R ?
O ?
N ?
Once I have that information I can add the gammatron changes and some lucky gamatron owner will get to alpha/beta test it!

I moved the switch and solenoids numbers to the next 2 digits over (easiest to code that way it's just a couple rearrangements and one byte change).

That was a dumb thing they did to reuse the same software like that unmodified - IIRC you shift the wires over on the 6 digit displays to make gamatron work on the 6 digit displays, loosing the 'real' 1's digit.

Sent Andrew the test version so I can adjust the skill shot stuff.

What version is this? Shows in match at boot up.

The ball Walker cycles three times at boot up to clear any balls in the lock.

There shouldn't be anything that scores that high but it depends on what version you burned.

I thought about doing this back when I was putting the skill shot in, but I think it's "too much skill shot" if that makes sense. I've definitely gone "too far" in the past with game mods (Night Rider is CLOSE to being too far, but it's still the essence of the game.... Trident was definitely too far/too many changes. I'm aiming for the spirit of the original game with small tweaks.)

You definitely shouldn't be getting 6 millions for a skill shot - which set of roms are you using, the 716, the 732, or the 512 on a weebly board?

The skill shot is supposed to spot a letter if you need one, spot a 5-4-3-2-1 drop if not, and score 25k if neither makes sense. (i.e. you have all the drops already, and blast off is already spelled)

At bootup, all the displays should show all zeroes and the ball walker should step 3 times - then the maze switches will clear the balls out on their own. You're supposed to wait for the balls to hit the drain - stock code waits for balls to hit the trough switches, but it only runs 7 times - if the balls aren't there after 7 cycles, it lets you start a game there as well. There is rudimentary ball search code built into the stock game - if a ball hits the walker entry or the maze switches, they will clear.

What happens if you miss the skill shot does it play normally?

Do other things work properly? i.e. bonus ladder 19k, quickshot off B/O to right spinner and blast standup, etc.?

I plan on popping an mpu200 in there later today to see what happens with that because all my development takes place in the 512 socket on the weebly board - there "shouldn't" be any difference between the boards, but I will double check it to make sure. (I'm not using the extra capabilities of the weebly board in this instance)

OK, slapped an mpu200 in there (not sure if it was my original f2k board or not) and burned the 2732's from the zip file right off the website - it's version 3333 up there (3335 is in alpha/beta test on my weebly board, no gameplay changes, just changes for the gamatron folks, and multiple switch closure test - also testing the insta-bootup which I'm still not sure if I like it or not (you press the s33 button to get the 'normal' bootup in the first couple seconds, if you want the diagnostics, but otherwise, it's power up-2 seconds-booted. That version of the software doesn't fit currently in the stock footprint, but I might be able to make it)

There's currently 6 bytes in the low rom area, and zero in the upper rom area without the quickboot in there.

I would double check that the eproms burned correctly - the 716 images I just double checked against the 2732's in the file and they are fine as well.

The software both stock and mine don't make any assumptions about nvram data being 'correct' - they specifically reinitialize anything that needs to be on bootup and game start. The clock speed is definitely different between my mpu200 and the weebly, the weebly is slightly quicker, but it worked on both.

I've sent off the test gamatron 35 build to barakandl as well for testing. I'm crossing my fingers that it's not too 'broken' - gamatron manages to rearrange a lot of the switches that I was using for the skill shot as well as the quickshot functions.

That is very bizarre, because both pops run the same exact code for the scoring sequences - the top pop should do the craziness as well. (The actual firing of the pops and slings is in the background routines, not in the scoring routines).

Do you have the ball trough that kicks the balls backwards as it launches (looks like this pic: https://ipdb.org/showpic.pl?id=887&picno=49151)? That is the type I have in mine as well, and the game will launch an extra ball if there is more than one ball in the trough AND it kicks it back far enough to slowly go over the leftmost switch again. It's probably why stern changed the design mid run to a different mechanism. While this can likely be addressed in software, this type of switch slowing response takes a lot of romspace (relatively) - I'm going to be investigating to see if something physical can be done to address the kickback. I get it about once every 50-60 balls or so, regardless of the version of the software in there.

The ball walker shouldn't be faster than stock - I'll double check it later on. Make sure there isn't a divot on the entrance to the ball walker, my old PF had that as well and it didn't matter how long the pulse was, it hung up there. I added a small nail to the PF on that one to hold the ball slightly off the divot. It's an artifact of well-used f2k playfields to get that divot, I'm sure the new CPR one I have in there will develop it as well. (If there was a way to slow the ball down as it rockets up there, that would help.... or maybe a cliffy can go in there but that maze area is so tight I'm not sure. Gamatron actually does that mech much better with the discrete kickout holes).

My ball walker fingers that stick up through the playfield were hammered as well, I ended up using the same mech off a scrap freefall playfield I had.

Can you double check the 2716's against the downloaded file again? Do you normally double or triple burn your eproms? I've found with 2716's that sometimes they need a little extra <something> to get them to reliably burn (ditto with 2732's on my minipros, I always at least double burn them).

Played several games on 3335, which is now posted at the normal link.

Only difference is that in the switch test, it will show all the closed switches, flash the 0, then show them again (not just the lowest numbered switch as normal).

This should help find switch wiring errors or if you have multiple switches out.

One thing that needs to be addressed is that while the ball walker is walking during multiball, no other switches are reacting - I'll have to have a deep think on how to fix that, because solenoid scripts normally can't be interrupted. Since the ball walker is an exceptionally long timer period, I think it will have to be some kind of re-entrant timed routine (luckily, I have at least one timer left.... I'm just short on romspace! 6 bytes right now in low rom and 0 in high rom....)

I didn't think too much of it previously in playtesting (over 600 games now....) because I was holding the balls on the flippers and aiming for the walker to get the 2x/3x. I happened to hit it spontaneously a couple times and it was pop bumper.... thud. (you can't make the pops or slings activate while the walker is walking since the walker is a momentary one - they should have made it a continuous one instead. This is a hardware limitation of the solenoid driver circuitry, not a software limitation.)

The correct thing to do is create a solenoid queuing system, but rom and ramspace is scarce for that kind of thing, or to rewire the ball walker, but hardware mods past the knocker I'm declaring out of the scope of this build.

Updated instruction card for 3 ball game. I'll be working on the manual as well to update the various things like schematics, adjustments, etc. I had a full color cover for this as well way back but the file didn't load correctly so I might have to recreate this (it took a lot of work to get the picture at the 'correct' aspect ratio... this was ten years ago or so though so hopefully easier to duplicate today.)

I'm really thinking about the idea of changing the ball walker to a dedicated solenoid setup activated by a small helper board so it can fire while other solenoids are going. It would still use the same solenoid driver, just connected to a pop bumper driver board (from a gottlieb system 80) modified to have a much longer 'on' pulse. This would let the pulse still happen just with a much shorter period so other solenoids can fire.

This would have to be dip switch settable for people that don't have the extra board.

FLIGHT2000-New-INSTRUCTIONS-FLAT.png

Go into audits adjustment 4 and push S33 or the clear button on the coin door to reset it to 0. Then press credit button to advance it or you'll run into an artifact of crunching the code down for size - any hstd less than 100k will show leading zeroes.

I'll have to do some research on how long I need the PBDB to fire the solenoid. Probably best to put a pot on it instead of just discrete resistors while I'm tuning it; worse than a pop or sling not firing would be a ball that gets its status lost because of the ball walker pulse being too short, although I think you have to adjust the cap as well as the resistor for the timing pulses. I'd really like to put some kind of switches there instead of doing it in software, but that would be a custom job as well.

I'll have to see where I can wrangle out a free dip switch too, to even adjust the software end of the timing.

So after watching dri 's stream last night, I'm inclined towards the 2x/3x just not being worth it - if I make the scoring longer, possibly, but it's almost like the score multiplier on flash gordon - lots of work to get it and you don't really have anything planned to do with it once you do, unless you can nail the 15x collect.

I'll be experimenting with hardware for the ball walker pulse for a while now - roughed the code in using dip 14 (formerly background sound on/off).

I spotted a bug that I'll be reviewing from the stream, and I spotted a bug in the code that I thought was eliminating the background sound but was actually some other function in the sound code. I need 4 bytes back to fix that one.... lowrom is 100% full.

I do also want to add a visual cue for the right spinner quickshot - won't have enough space to make an animation, but I can certainly make the existing lamps blink during that time.

It can, but that's going to go outside the scope of what I want to do with the mod. In my experience, 10% or less of people interested in a rom mod actually try it out. Add some kind of required hardware change to that mix and it's going to drop to 1%.

use a 27256:
http://www.pinball4you.ch/okaegi/pro_softnine.html

and here:
http://web.archive.org/web/20170412040716/http://warpzonearcade.com/?p=402

Lot of messy wiring.

This one is easier:
https://sites.google.com/site/allentownpinball/romblaster

Daughter board to plug into the 6800 socket.

I could just use the extra ram/rom on the weebly board directly (it's kind of why its there) - but that's raising the bar even higher for adoption.

Also, I find that I'm enjoying the challenge of rewriting the original code for space efficiency.

No.... doesn't really need it. I might not drop the 2x/3x but I need to rethink how it works. It's really hard to take advantage of currently (especially the 3x) - maybe I'll change it to get one ball up there, then the second and it recounts down the blast off letters (or whatever you have lit at the time). That kind of smacks of a "mission" though, which I also don't care for.

Any chance for a dip option to drain all balls in the walker before the start of each new game? My thought is that it would drain all balls in the walker after ball 3 of the last player.

There's no need to do that unless you have the dip set to carry over locks. The game handles locks properly and the only difference would be you get to shoot the ball from the shooter lane instead of it launching from the maze. It could be done but then there has to be code to check the outhole before allowing a game to start, which can be confusing on location games where a ball is stuck somewhere.

I happen to be a software dev and have a small technical background in embedded systems as well as assembly language. I would love to know more on how to get started on such a path as writing my own ROMs - any direction you could send would be greatly appreciated!
* What software do you use to write, compile, and debug your code?
* What assembly language is used? (I have experience with MIPS and ARM)
I see the ROMs are available to download. Is your assembly source code available for download as well?

pinmame debug, a relatively old version. AS02 to assemble. Stern pigs is a mix of 6800 assembly and an interpreted language they called PIGS.... look at my other posts for the Galaxy disassembly thread to see it up close and personal. There's a beginning of a guide at:
https://sites.google.com/site/allentownpinball/pigsprogramming but not really complete.

The original flight 2000 commented code I built off of is on that site as well but not the changes - development tree is extremely messy right now because I've taken to adding/removing code now by 'sections' as I add/test, eventually I'll have it there once I'm "done" with the changes.

Of course, anything I decline to add you can add yourself once the code is posted

Working on cutting more space into the roms - was able to combine some like routines, and found a couple of never-used pigs routines that were cut as well. I have a couple of ideas on cutting even more into the code to save some space - it will be hellish for future generations who might decide to reverse engineer it so hopefully the source code will come with it (the 512 images when finalized will start to include a 7zipped copy of the source code in the normally empty space).

Now there's 11 bytes in the low rom area and 84 in the upper to add some kind of quickshot indication for the right spinner - the first test of this was a complete failure as it's pretty dangerous to blink something without knowing its original status first..... random results ensue if you don't save it first.

Testing just the cut down before adding anything back. No other additions were cut yet but I still need to think long about the 2x/3x thing. Maybe it makes more sense to award the 3x and have it decay - then if you want it to stay at 3x, keep shooting it back up.

Maybe it makes more sense to give the 2x/3x scoring JUST for the spinners? They really are the thing I'd shoot for anyway (unless 5-4-3-2-1 is right at the 1). Doing so would streamline the code a lot because then there's no 2x/3x generic code taking up space - and handling queued scoring with the multiplier is sloppy at best.

I have it set to pay an extra ball for the wow. If you had a full left spinner rip for 12k/spin you could easily get 300k.

Also could be possible to change the 2x/3x lighting to completing BLAST (for 2x) and OFF (for 3x) during multiball, and NOT timing it out. Or spelling BLASTOFF for 2x, again for 3x although that just becomes really difficult after a while. The multiplier could either be only multiball (if it were easier to get) or harder (if it stays into the single ball portion).

Or maybe I just need to tweak the 2x/3x timers again - I've had it "too long" and "too short" - it still seems too short at this point. The issue with tying it to the walker is that when the walker is walking, there's really nothing else the machine can react to properly. Gotta get that pop bumper driver board in there, or maybe repurpose the continuous solenoid I'm using for the knocker to the walker instead (continuous as momentary are separate timing circuits).... that's probably better than adding a piece of hardware.

So it sounds like you should stick with the original romset?

No, too much like Black Knight, Fathom, etc. - I still like the idea of the walker triggering it I just need to tweak the timing on it. Have to experiment with the pop bumper driver board - I realized it can be mounted in the head (for easy access to +5v). The walker moving really kills the response on the machine, so something has to happen there. I'm concerned that in the future someone that gets the rom without the instructions will be like WTF is this, wrong solenoids firing, etc. I think I'm going to work on adding something in the audits/adjustments that you have to set to use whatever the walker ends up being, that way someone probably won't set it by mistake (like adding adjustment 18/19, both have to be set to 66 for the alternate walker code to operate).

From the stream as well I'm going to work on the 2 5 bank blinking lights, I've had it happen on my machine as well where 2 blink lamps light in error, so there needs to be a test for that. It's probably something where the interrupt happens to update the blinking lamp while the game is expecting it in a different state so have to block the interrupt first before updating it - usually stern games do this, but maybe this routine doesn't.

I have never seen the error occur on the stock roms so clearly it's from something I've added. I wish the code I decided to crunch first in this latest go-round had worked, because it got me over 130 bytes back.... but it was a complete failure (coining up or starting a game just crashed the entire game..... I single stepped the code in pinmame to try and determine even where it was crashing, but was unsuccessful. I may revisit this if I run out of space again though.)

I'm also going to work on testing where the balls are before you start the game - especially with the new delay walker code at bootup, you can start a game with balls sitting in the wrong places. I still say that kind of thing is on the player, and it's only going to happen once per boot anyway.

I'm going to experiment with some transplanted sound effects also see if I can get any working.... never been able to do that previously though, but I know more about the sound engine(s) now - they're slightly different in every game.

No, that's his machine - notice it only happened when he was shaking it. So something was activating the walker switch that shouldn't have - he was also getting a 25k score off the center standup at the start of each ball.

There's been so much discussion of the ball walker code among the beta testers - it's the stock code! The timing is not different, it walks at the same speed. I tried to make it shorter but it never worked out.

What sounds, specifically, would be a good lift from those games into flight? The sound I always try and poach is the 25k sound from Big Game - I love that mmmmvvoooott sound.

The walking works, it's just that during it hitting pops or slings - thud. No available solenoid driver to handle this. I wish they'd made the walker a continuous one instead of a momentary. I'll be playing around with the swap of the knocker (which is on a continuous one right now) to a momentary, and using that continuous one (for which you can assign a separate timer) to the walker.

You should quote the section you're referring to - issues on that game on the stream when the switch activates when it shouldn't due to a hardware issue, or the issues where the pops/slings don't work while it's walking, which all stern games do when a momentary solenoid fires for a long time. It's one of the deficiencies in 9 Ball as well, if the top 3 banks are resetting, it's very possible to hit the pop bumper and get..... nothing. (you get the score, but no pop). Trident suffers from this as well, because the standups are treated like a drop bank when they are complete, there's an delay when they reset and they use the solenoid timer IIRC so the pop doesn't fire. (Also sometimes with the memory drops)

It's really pronounced on flight 2000 because the walker coil has to pulse for a very long period or the balls don't have enough time to walk down.

I plan on swapping the knocker coil circuit for the walker circuit; however, this is going to "break" the software on people's machines who don't realize this needs to happen. (I.e. they got the rom with no documentation, or they got a machine that had it in and in the course of checking out the machine they switch the wires back without realizing)

Too bad you can't pulse the walker to shoot the ball backwards, this happens sometimes 'naturally' but with no where near enough strength to eject it 'backwards' - that would be fun.