It's been about 3 months since the release and there was several weeks of testing before that so minutiae about how the walker walks is not top of my mind all the time, but luckily it's one of the things that I documented really well in the code.

First off, when I say detected vs. not detected, there's a backend routine that handles looking at closed switches and adding them to a queue. This is the same in stern stock code as well as the modified code for the way that *any* switch is detected. There is NO code on a bally/stern game that waits for a switch to open before reacting - it's just not the way the backend is coded on these games. The switch gets added to a list of closed switches (by column) for eventual processing on the front end (which I call a main loop).

Now, a permanently closed switch being held down should activate ONCE (when it initially closes and stays closed) - but if it stays closed, it will not activate again until it is open again. The detection pattern is open, closed, closed, closed, add to switch queue for that column. The columns are processed in order 0-4 - the spinners are on column 0 and the walker is in column 4. The timed switches which are tripped virtually are columns 5-7, so they run AFTER all the other switches process. The startup code in the game (original and modified) has code to artificially set all switches to closed, that way they will NOT be processed at all until they are clear - which they will all do if they are in fact, not closed.

The above is just background material as to how the switches are detected. The below would refer specifically to what happens to those detected switches in the foreground of the program.

I just doubled checked how the reaction to closed switches is operating, and it truly is one switch at a time per run through the main loop. Spinners almost always seem to be on column 0 probably for the reason that they need to be serviced quickly. None of this should change a valid switch hit in other columns, unless the background routines that reset certain switches have reset one of the switches in question. The stock software as well as the new software resets the ball kickbigs, all drop targets, the walker, the outhole, and the trough switches (I thought I'd removed the walker from this, but I didn't).

I think that Stern used the half switch wireform on the walker entry for a reason, I think it's mainly there so that the ball passes over it, it pops back up, and helps to prevent a ball from going backwards in the walker, which it can do (if it pulses too short). It can be argued, perhaps successfully, that anything modified code does that original code does not would indeed be a bug in the modified code, since obviously it worked one way with the original code and another way with modified code.

I think what's happening in the modified code with a held down walker entry switch is that it's getting cleared, but the first thing the walker routine does is set up a re-entrant pause, which also includes goosing the timer for the spinner (which is why it doesn't come off the display). Since the switch is still closed, but has been reset, it just resets the timer again. This seems like it will repeat if the switch is held down.

Someone previous did have this issue as well, but it went away once he adjusted the entry switch to come up after activation. I had put up a changed version at https://sites.google.com/site/allentownpinball/galaxy-asm/F2K-test.zip?attredirects=0&d=1 so you can try that to see if it makes the issue better, I have not tested this version in my machine at all, it merely changes the walker behavior to only react ONCE to the spinner vs. waiting for sure that it's over, by skipping the test for it the second time through. (It's technically a differing entry point).

There has to be a quick reaction time to the walker routine initial run because otherwise 2 balls shot up into the walker during multiball in quick succession will not be detected as 2 separate balls and one would get stuck in the walker because the game just wouldn't realize it was there.

Try out the test version and see if you get different results. I think only U1 is changed because the change was an ifclearbranch vs. branch (same length instruction) - but you can double check the files u2, u5, and u6 against your existing eproms to verify that.

I don't think I can modify the software successfully and keep the changes with the spinner not timing out nor the multiball situation to be able to handle all situations that can occur with the ball walker held down, and that was the main crux of why I even started doing this project in the first place. The entry switch has to come up for the fast reaction to catch the possible added balls in multiball. Were there more switches up there or in the walker none of this software tracking of the virtual balls would be needed.

The stock code works because it doesn't care about 2 switches in a row during multiball for instance, because it's only walking each down once (and ending the multiball). The modified code has to have a counter to walk the balls down the correct # of times. Ditto during the regular game play, if you're in single ball it just walks it down one (causing the loss of spinner points....)

It's unfortunately that the loss of points can also be solved a different way, which I did with the option to change the walker to a continuous solenoid path instead of the momentary. Still doesn't help the switch entry being down, though.

I suppose another way to fix it that can be tried would be to NOT re-trigger the switch entry, but that might break multiball multiple balls.

LMK how the test version fares.

After having slept on this, further information would be that the activated switches aren't really a queue, it's more of a set of registers with set bits for pending switch events, that get processed columns 0-7, rows 7-0, in that order. If you had a switch in column 0 row 7 continuously activating, it would get processed at the expense of all other switches. They would still be flagged to be processed, however, if another switches activates AGAIN before the first one processed, it would only activate once instead of the twice that it probably should have.

In practice a switch could not be physically activated quickly enough to dominate the switch processing, at least not in any real world scenario.

In the unfortunate trade off between rom space and additional coding able to be added in, the reasonable compromise arrived at is to have the switch on the walker entry close then open. Could it be fixed in software to react properly based on the closed switch remaining closed? Of course. There's no room to fit the (much more involved) code in the stock rom footprint though. This is likely why the original flight 2000 code involving the walker weighs in at 566 bytes.

No, it doesn't pop up between the balls. In multiball the walker routine follows a different path since it's not locking the balls, it's just doing the 2x/3x pf multiplier and walking the ball out. It still waits for the spinner to stop, then it starts the 2x/3x routine and walks the ball out (itself a separate process).

Unless your walker switch is completely closed and having the ball sit on it opens it, so that when the switch leaves it it goes closed, I'm not really sure why the switch has to be open again. I'm not checking the switch in the routines (there would be no point in doing that, since the routine starts when the switch is activated).

Is this consistent because it doesn't do it here. That's one of the routines that didn't really change between stock and here, just a couple of flags checked. It will skip it if you save progress between multiballs (set to really easy).

The routine actually waits until the speech flag is clear to speak for specifically this reason you noted, if you complete blast off later when the locks are already qualified.

Yes

6/30/2020 3347M is the most recent version. I see I left the date incorrectly in the readme though as 6/3, but the datestamps are correct at 6/30.

https://sites.google.com/site/allentownpinball/galaxy-asm/f2k-release-3347M.zip?attredirects=0&d=1

DIP 14 needs to be on if you leave the walker where it is, stock. The coin lockout does not operate as a coil lockout any longer, it's the knocker signal. Nothing untoward happens in this situation if you do not actually install a knocker.... the coin lockout coil will just pulse instead. Walker response suffers in this situation, especially during multiball.

If you swap the coin lockout and walkers, you will get the benefit of the quicker response walker, but dip 14 has to be off, without a knocker installed, it will just pulse the coin lockout coil instead. The risk comes if you have dip 14 set incorrectly for the walker it might burn out the driver transistor, although the pulse to the walker is the same length pulse completely bone dead stock vs. mods. The risk is if you install a knocker, which is usually a stronger coil, and it locks on, that much more current is going through it. The walker coil is 15.6 ohms, and a 23-800 style knocker coil is 5 ohms.

If no knocker, and dip 14 incorrect, the most that should happen is that the game won't pulse the walker at startup, and if there are balls in it, it won't start up correctly (it will just say "standby, ball" until it sees all 3 balls in the outhole trough when you press the credit button)

I added fuses to both the walker and the knocker just so I didn't blow any transistors during testing. I think I did pretty good as I only blew one, and that was not because of the software but me shorting something instead.

https://www.amazon.com/Ictouch-AT28C16-20PC-16KBIT-Corporation-PDIP-24/dp/B07PBDV9XF

although this is not the link I got them from but that is the part # to replace a 2716 with an eeprom version. I probably got them from either ebay or digikey though and misremembered getting it from amazon.... I got the eeprom 512 replacements there though.

You can also just burn it onto a single 2532 and put it in u9. Strange design the vsu100, to take either 2x2716 OR 1x2532 I'd have expected them to do 1x2732 since the 2716/2732 are more similar.

Wonder if they're counterfeit? Post a pic of a chip?

Chip looks like mine, different numbers under the 2816. (different lot/date codes) If they all failed I'd suspect that they are counterfeit.

I've been relatively lucky ordering chips online I've only had one bum set of chips (256's from a chinese seller - they hemmed and hawed and refused to give money back, so I kept up emailing ebay about it until they just gave the $$ back.... I hadn't had to move up to paypal dispute but I was ready to, always backed with credit card instead of bank account so you can move up to credit card if needed.)

2716's are eproms.
2816's are eeproms and are a replacement for UV erasable eproms (they are erased by the burner itself electrically)

Barring any glaring bugs it's done, no other changes planned.

Since it's pretty much final, here's a link to the source code for the posted version for educational purposes.
https://sites.google.com/site/allentownpinball/galaxy-asm/FLIGHT2000-3347M-SOURCE.zip?attredirects=0&d=1

It's more likely to depend on what happened right before it's supposed to say it - in the case in the video snippet it's likely because the game was saying "OFF" and the timer for the speech has to be a certain length (probably even longer than it takes to say the word "OFF") - some of the areas like locking a ball will pause to say stage 2 go, all systems go commence countdown because the walker inherently has delays built in (that also specifically wait for the other speech to finish). The BLAST and OFF completed do not, so anything that would normally talk on completion may or may not depending on how quickly other things are hit. Once the speech call starts though, nothing can interrupt it - so if another speech call comes in while that's going, the speech board ignores it.

It would be nice if there were a long speech queue to work with but the game is rather Ram-starved in this aspect - Stern themselves (well, Bill Pfutzenfeuter anyway) used the bottom of the stack in all of his games IIRC, to store sound queues, and in F2k, also to store a virtual switch setup for the locks.

If you miss out on speech on the walker locks etc. that would be a bug to look into, but otherwise, the speech delays will have to stay the way they are - no room in ram or rom to add any other kind of setup for this. The original game sometimes misses this all systems go commence countdown speech call as well, in a similar situation.

You have to burn both the 2716's the index for the words is in U9, so it's different - additionally it's been reformatted from stock.

Or you can put the u9 combo rom into it, it's a 2532 so it's twice the size, the vsu100 is nice in that it supports this config without jumper changes.

Normally you can't swap 2716 and 2532 but the speech board does it in some kind of clever way.

moved to http://tsqmadness.com/slochar/ thanks to google sites' "feature upgrade" to not allow directly linked files (easily.... it's pretty clear that I ain't no HTML wiz....)

Your roms are not booting they are either burned wrong or your board isn't jumpered correctly for the type of ROM you are using.

The screech from the speech board is normal until the game starts to boot then it turns it off. The stock games with speech cards do this as well.

That sounds way short but if it's eeproms might be accurate. Download the test ROM on pinwiki and put that on one of them see if that works. It's only u6.

Yes pull u1 2 and 5 it shouldn't really matter if they're in but trying to remove extraneous factors.

Just burned a test image onto a 2816 eeprom you can see that verifying it took 50 ms. Writing took 20,000+ ms, so if you got 32 ms, something's wrong.

pasted_image (resized).png

Do you get displays, are all three balls in the trough, did you update the voice roms as well?

You sure you have the roms in the proper spots? Stern games' checksum is just a rolling sum and can't detect if a rom is out of order and that's assuming I assigned a checksum I don't recall if i did.

You can ignore the spurious sounds and lights that's randomness because it's not running correctly. I'm not in a position right now to double check the file but will do so tomorrow. It sounds like it's corrupt. Did you get it from the old Google site or the tsqmadness one?