Chalkey - I revised my diagram. You only have to ground J5:pins 10, 13, and 24. Don't worry about 11 & 12. If you use a switch for that, you can turn it on/off to boot with 6800 or Arduino.

Wiring rev3a (resized).png

Aw, come on, how hard is hitting a few dozen drop targets?

I just looked up the port mapping for the Mega and it's substantially different than the Nano. To get the speeds required, I wasn't able to use digitalRead and digitalWrite in the code (which would have guaranteed compatibility on different boards). So, instead, I read and write directly from PORTB, PORTC, and PORTD. On the Nano, the ports look like this:
nano port mapping (resized).jpg

So, as you see, Pin 2 = PD4 (PortD4).

I'm looking at a similar diagram for the Mega, and I don't even see a PD4:

Mega pin out (resized).png

So, all the port stuff in BallySternOS.cpp would need to be remapped in to available pins on the Mega.

pavel_one I really hope to see a stream. I love watching pinball and I would enjoy seeing someone play the new rules of these games.
By the way, I've finished the writeup on Black Jack 2020 and posted it here:
https://pinside.com/pinball/forum/topic/black-jack-2020-new-code-for-bally-black-jack-1977

If you have the capability to plug the Arduino into a computer while it's on the MPU, try running MachineDiagnostics.ino
It will report back via the serial port and tell you what it's trying to do and what it sees from the MPU.
Here's an example of the output you should get back to the terminal:

Start of program
Monitoring VMA signal, looking for presence of M6800 processor
Saw no sign of M6800 -- program will continue
Attempting to read & write from U10
Testing U10A Control Register
The U10A control register passed
Testing U10B Control Register
The U10B control register passed
Testing U11A Control Register
The U11A control register passed
Testing U11B Control Register
The U11B control register passed
Testing the clock cycle (if this hangs here, the conncection to clock is faulty)
It took 20984 microseconds for 10000 clock cycles
Clock frequency (very) approximately = 476 kHz
DIP Bank 0 = 0xE8
DIP Bank 1 = 0xC0
DIP Bank 2 = 0x9B
DIP Bank 3 = 0xA7
Starting interrupt tests - this is going to take 5 seconds to test
In 5 seconds, saw 600 U10B interrupts and 1634 U11A interrupts
Zero-crossing approx. 120.00 times a second
Display interrupt approx. 326.80 times a second
Interrupt tests done - if frequencies aren't approx 120 & 320, there's a problem with the interrupt line.
END OF TESTS
(waiting for reset)
(waiting for reset)

Aha - good to know. The SLOW_STROBE define only inserts one clock cycle in between the data writes. You might be able to go back to the 50% duty cycle by inserting more clock cycles between the data writes of that strobe. Let me know if you want to muck around more to really tune it in. Maybe we can come up with an alternate setup that works for more people.

Also, I really hope to see a stream sometime soon

That's an interesting idea. It would give access to all the address lines.
As for the speed issue, the Arduino has to talk as fast as possible to the lines I'm currently using (D0-D7, A0, A1, A3, A4, A7, R/W, PHI2, IRQ, VMA), so if I used this port extender then I would keep those the same with the exception of A7. For all the 8250 stuff I'm doing, A7 is high, so it could be moved off-chip. That would mean I had two free pins to talk i2c with a MCP20317.
For a couple of dollars, this could be a substantial upgrade to the circuit.
I'm not sure I would want to wire it all up by hand.

Chalkey - I added the switch so I can dual-boot my machines. For the Arduino to run, you have to ground J5:pin10 & J5:pin13. (way, way back I said ground 10-13, but that was just a convenience because I bridged them all, but really only 10 & 13 HAD to be grounded).

In order to halt the M6800 and leave it plugged in, you have to ground J5:pin24.

So on my latest boards, I'm putting in a switch to ground J5:pin24, 10, and 13. Turn the switch on (grounding the pins) and the Arduino runs. Turn it off, and the M6800 runs (with the latest code, the Arduino waits to see if the M6800 is running, and stays out of the way if it is).

If you already made the boards with 10-13 grounded, they will still run just fine. If you want to plug your M6800 back in, you can ground 24 on your board as well and the new code will run. But the only way to dual-boot is to have those grounds be on a switch so you can turn them off. If you go this route, be sure to use a 3pole switch so the grounds stay isolated when the switch isn't engaged.
https://www.amazon.com/gp/product/B07XMH174C/ref=ppx_yo_dt_b_asin_title_o08_s00

Yes, the dual boot code is on GitHub! it adds a few seconds to the Arduino boot time (where the Arduino waits to see if the M6800 in on the bus). Any other changes/additions/subtracts - you're welcome to have at it. All the code is open source and non-copyright so feel free to take it wherever you want it to go.

This video at 1:45, you'll see (hear) the original chime timing for a star hit:

Here's my fastest ring (which I give for the skill shot):

Yes, I'm driving the chime faster for the skillshot than the original did for a star hit (and the inlane--same series of 5 chimes). But the original code drove the chimes far faster than a "ring" tone as well.
But, regardless, if you want your machine to have more time between chimes, please be my guest. Every single line of this code is at your disposal!

Cheers - happy configuring - do what you will.

I may be way off base here (and please correct me if I'm wrong), but I believe that the chimes that cfh is hearing are operating the same as in my video above. In his opinion they occur too fast because of the spacing of the repetitive hits, not because of an error with his board.

I suspect that the issue is actually a little more subtle than that. In the original code, the M6800 was completely occupied triggering the chimes. If one switch was hit during a chime sequence, it would be remembered and handled after the chimes were finished playing. A second switch hit was lost. For example, when a star is hit, you hear the 1k chime ring fives time in just under a second. If the star is hit again during that period, you hear two series of 5 rings in a row, taking nearly 2 seconds. Because of this limitation (a busy processor could only remember one additional switch hit), fast ball play events were sometimes lost. No big deal in a single-ball game. I'm not sure many people even noticed.

In my implementation, I keep a buffer of switch hits that's deep enough to capture everything. Additionally, I push my solenoid hits to a time-release array so playing a series of chimes doesn't preclude any other event. Because of this, multiple switch hits happening in a short period of time will trigger overlapping callouts.

I can implement a configurable multiplier on the gap between hits as you're requesting, cfh . I will add that to my list of things to do for Stars2020 (version number at boot is already on that list). However, having given it some thought, I don't think that's going to change the behavior in the way you expect. A ball going up and down an inlane is still going to trigger two nearly simultaneous events and the melodies will overlap. A change to that behavior will require somewhat of a re-architecture to make sure that melodies don't collide.

Four approaches occur to me (all have their downsides).
1) when playing a sound effect, the program could store a variable indicating the "finish" time fo the melody and that would be used as an offset for subsequent melodies. A burst of action would be trailed by the system catching up to all the callouts, but they would eventually all be played. Sound is important for pinball--players often use sound queues to make split-second decisions, so this doesn't seem ideal.

2) each new sound effect could clear the buffer of pending sounds and take it's place. This would likely require a "priority" variable so things like tilt-warnings would always take precedence over something like a 10-point switch.

3) new chime hits could only be pushed to the queue if there were no pending sound hits already there. Again, this would benefit from a priority.

4) the solenoid queue could be scanned in the loop to look for chime events that are too closely spaced and "declutter" the queue (only for chimes).

Here's what I'm basing my statement on:

Two hits - no problem (second happens right after first).
Four hits (three happening during the first chime sequence) - only registers 2. The third and fourth are ignored.

Then when I hit the 7k on the drop target I'm able to hit the star switch 5 times and only one is registered and played after the 7k sequence.

This doesn't prevent pop-bumpers and slingshots from reacting during a chime sequence -- those firings are done reactively in the switch read -- but a chime sequence does seem to allow only one standup target from being registered.

To clarify (just so we don't talk past each other while we're discussing the deep & dirty of switch reads), my point is that in the old code the chimes were less cluttered because the machine essentially started a chime sequence and limited its responsiveness to new stimuli until that chime sequence finished.

As you see in the video, 4 hits are processed like 2 if they happen too fast, and that means you're not inundated by chimes or listening to them for 20 seconds after a flurry of activity.

The new code queues everything, so overlapping events are captured and chime sequences stacked on top of one another. It's inarguably better to catch the switch hits , but arguably not better to stack the tunes, which is why I'm talking about possible methods of decluttering the callouts.

Ball sweeps by the drop targets:

The first set, I pause a tiny bit so my third hit is after the 5th chime and we get all three 500 rewards. (then I reset both by knocking down the second bank). Next time, I hit all three targets fast and only two register with chimes & score.
When you said, "yes, it is very possible to miss re-hits on switches, but you'd have to accumulate a LOT of hits in other switches as well to do so," I don't think that's correct. Not for Stars. The only thing required to miss a switch hit is if two occur while a chime sequence is already happening (like three drops in a sweep or the pop-bumper railing the ball off of the white star, which it does a lot).

In comparison, check out the response from Black Jack (Bally, a year older):

This is a very different approach. The chimes & score for hitting the Change Player standup are queued up and I can hit it a dozen times in a row without missing a single press. In addition, while it's playing the chimes for Change Player, I can hit Change Dealer and the lights change instantly while the chimes queue up behind the Change Dealer chime. However, if the ball dips in and out of the saucer and it gets into its "Player Wins" routine, nothing is registered at all. That actually happens in the game regularly--the saucer triggers, the ball comes out, and anything you hit in the next couple of seconds isn't scored.

On Black Jack, the case that could never happen (hitting the standup 5 times in one second) is handled perfectly, and the one that regularly occurs (saucer lip-out) is ignored.

All academic, of course--doesn't point me in an actionable direction for the new software. I'll probably try to "declutter" by ignoring chime calls if they come too soon on the heels of an earlier one. That will be my first attempt anyway. I'm going to continue to count every switch hit. They're soft-ware debounced, just like in the original software (and as described in Bally's Theory of Pinball). That part is working fine.

Is your replacement OS the one with the PIGS implementation? How does that handle switch hits?

CoreyStup , for Bally Black Jack, stand-up targets and rollovers, yes the scores are added to counts and played in the loop. For the "Player Wins" sequence, no. For "Player Wins" a custom sequence is played and during this time other switches aren't handled:

When the ball lips-out of the saucer, nothing is registered until the sequence finishes.

For Stern Stars, the chime sequences block all but one additional switch registrations. Sweep all three drop targets before the chime sequence is finished and you will only get credit for two:

These sequences (when stacked) are not played in value order -- see here: