Great to see someone finally integrate this feature on their 7-digit LED displays for the simple cost of an extra $1 logic chip

The description says they are 20mm wide digit packages. When using 7 digits, how do the edges fit in the backglass display window?

Ghosting can be an artifact due to a problem on the display blanking signal. Check if these users maybe have an open circuit on that signal from MPU board to the displays.

If the problem is happening when 5 displays are connected, it is possibly a loading issue on the blanking signal.
If you disconnect the blanking signal at the MPU board with only 4 displays, do you get a similar ghosting effect?

It's been a few years since I've played with this problem. Looking at the Bally Display Interrupt Service, I would expect the ghosting to be on the digit to the right, not left. It could be you have some other issue.

What exactly is going wrong with the current implementation?

I haven't looked at the game code, but I presume (guesstimate):
6821 is programmed for normal falling edge trigger which happens on the rising phase A.
Phase A crosses zero upwards and rises causing an interrupt to trigger.
Interrupt is serviced then 6821 is changed to sense a rising edge trigger (falling phase A).
Phase A falls and generates an interrupt trigger about 0.3ms *before* it has crossed zero.
Interrupt is taken but flagged to service phase B about 0.6ms later when phase B has become active.
0.6ms later phase B lamps are refreshed and 6821 is reprogrammed back to normal falling edge trigger for next rising phase A.

Or am I totally off base?

My presumption in this regard was based on the Zero Crossing being AC, but I forgot it was only 10 volts. It means the trigger times I mentioned (0.3ms and 0.6ms) are too short and in reality need to be longer because of the slower rise/fall in 10 volts wave.

See below wave snapshot showing the traditional relationship of the Zero Crossing detector output going into the 6821 against the 43VDC solenoid voltage. You can see the Z.C detector only changes state while the ripple is positive - actually it never "crosses zero" volts on traditional systems using DC.
When the Zero Crossing detector input is AC, it cannot detect and change state while the input is negative voltage. So this is the reason I presume you need to alternate the edge direction detection on the 6821 CB1 input and then wait some time after phase A falls and triggers near zero and then goes negative voltage (where phase B is now positive).
The Zero Crossing pulse length in the oscilloscope snapshot below is approximately 0.6ms (but again it's based on the steep rise/fall of 43 volts, not 10 volts).
The diagram below it hopefully explains my theory. Does it sound reasonable?

IMG_0052c.jpg
DC_Ripple1.png

Great to hear!

BTW, the display interrupt generator runs at:
Around 430Hz on Bally 7 digit display games
Around 320Hz on Bally 6 digit display games and Stern MPU-100 games
Around 400Hz on Stern MPU-200 games

I think you are running the display interrupt generator at 400Hz based on your diagrams? Because your approach will be more precise there is the opportunity that its interrupt could happen at the same time in sync with a 100Hz zero crossing. I think it would be safer to run the display interrupt generator a little higher speed say 410Hz to minimise this occurrence.

I had a look at the code:
- Zero Crossing interrupt occurs
- Alternate a RAM phase flag (actually it's just bit zero of a free running counter)
- Perform a delay around 1.10ms
- If RAM phase flag is set, service the phase ØA lamps, else service phase ØB lamps
- Perform all other Zero Crossing system services
- Alternate the edge detection on the 6821 Zero Crossing CB1 input
- Exit the Zero Crossing interrupt service routine

Looks around 1.3ms to me. Doesn't this seem too short to you considering the AC wave is 50% duty? With 20ms cycle (50Hz) I would expect the Zero Crossing Detector pulse to be around 12ms.
It doesn't look like you are getting Zero Crossing interrupts occurring every transition, only every second transition which doesn't seem right like Zero Crossing is serviced at 50Hz, not 100Hz and the phases are serviced at 25Hz. This is likely happening because that Zero Crossing Detector pulse is too short considering the 1.10ms delay in the zero crossing service routine causing the edge detection not being reprogrammed in time for the next transition - see below.

BallyFA_ZeroCrossing.png

Can you explain how you're generating the zero crossing detector signal?
Is it controlled by the power signal coming from the rectifier board to the MPU board at J4 pin 15?
Or is it a timer implemented in your hardware?

An AC signal going into MPU J4 pin 15 will produce a zero crossing detector signal with a cycle time of 20ms (50Hz), but your snapshot shows the cycle time is 10ms.

This occurs on factory MPU boards too that the interrupts will occur at the same time every now and then.

And that's exactly what I've been expected too! Well done.

You mean full rectified DC signal? (not AC). If yes, then the cycle time is 10ms.

Yes, games with the dual phase lamp setup will be refreshed at half speed on each phase. The AC voltage is higher to compensate for this and in terms of incandescent lamps that have long persistence, the higher voltage makes them stay on longer so the slower rate of refresh will not be noticeable or cause flicker.

LEDs complicate matters since they have no persistence. 50Hz refresh will be enough to not produce flicker, the problem as we know is that with traditional single phase DC games the lamp refresh occurs early in the DC phase when there is not enough current draw from LEDs for the lamp driver boards SCRs to latch. The solution has been to add resistors across the LED circuits to increase the current draw that helps the SCRs latch. This still isn't perfect and I suspect flicker can still sometimes occur in part because of nested interrupts (display interrupts can interrupt the zero crossing service routine).

Why is this? The 6800 /IRQ input is level sensitive (not edge). The 6821 IRQ outputs are open drain and all tied together in an OR fashion meaning they could all request an interrupt at the same time. It is up to the game software (operating system) to prioritise IRQs and determine which IRQ source(s) is active.
In other words, interrupts are prioritised and dealt with in software and nesting should only occur to one level based on their frequencies.

Anyway, great work! and to get back to the original request, hopefully a Bally 6803 control board replacement will one day make it on your list

Post a picture of the regulator so we can see if it has the telltale counterfeit markings.

Your solenoid driver board looks familiar
https://pinside.com/pinball/forum/topic/bally-as-2518-22-solenoid-driver-negaive-dc-voltage#post-5834765

That regulator looks suspiciously like this fake:
https://pinside.com/pinball/forum/topic/6821-pias-from-china#post-4279650

You don't need any extra wiring for Bally games. The Lisy 7 digit display has the 7th digit decoder built onboard to decode the 7th digit using the existing 5th and 6th digit signals. You just need to use Olivers modified 7 digit software and jumper the display board accordingly. The fact you lose digits 5 and 6 in 6 digit mode says the decoder isn't working on your boards for whatever reason.

6 digit Stern games likely need the extra wire since you effectively use a spare MPU signal to drive the 7th digit.

It's not needed for Bally 6 digit games, only Stern 6 digit games need it.
Olivers decoder is built onto the Lisy display board.
When the decoder sees the digit 5 signal active from the MPU board, it activates digit 5.
When the decoder sees the digit 6 signal active from the MPU board, it activates digit 6.
When the decoder sees both digit 5 *and* digit 6 signals active from the MPU board at the same time, it activates digit 7. That's how Olivers concept works.

You will notice above when koji enables 6->7 digit support he loses digits 5 and 6 which points to the decoder circuit not working.

The typical 7th digit signal at the MPU board for later Ballys and Sterns is used on 6 digit Bally games for the sound board. That's why the decoder mechanism is needed for 6 digit Bally games.

The decoder chips are probably $0.20
To me, it's a no brainer to put one on each display and save messing around with the harness and addon decoder boards
Years ago I tried unsuccessfully to convince one of the other early LED display makers here on pinside to do the same.

The "info.txt" in Olivers patch file says the resultant CRC for U6 after the patch becomes: C0FC5342 which matches the U6 in "kissb.zip" so it has the right Oliver file.

You need to convert the original U1/U2 and U6 into 2732 files before you can apply Olivers patch. The first half of U6 2732 should be FF filled as the source.

Are you sure the sound problem you experienced isn't something else?

Welp, I just tried it in emulation and after a monster first ball I lost sound on ball 2 and 3. So you're right, there's an issue with the "kissb" ROMset.
I'll have a look into it.

There is indeed a bug, now here's the kicker. The bug is actually in Ballys code - it's just that circumstances never arise for it to be an issue with the factory 6 digit code. I can go into details but essentially the players scores are backed up in NVRAM and erroneously overwrite a sound status flag. The data written there due to the millions scoring causes the game to think the sound board is busy and stops issuing sound commands. It just so happens the factory 6 digit scoring always writes a score value that makes the sound status flag free to accept sound commands.

So open the modified Kiss U2 ROM in a hex editor and make the changes at the following addresses:
$0000: 8F ---> 8E
$03DB: 54 ---> 55
$04B6: 1E ---> 1F
$04C8: 1E ---> 1F
$061D: 94 ---> 92
$0DFA: 1E ---> 1F
$0E23: 1E ---> 1F
$0FD6: 2C ---> 2A

These mods essentially shifts the backup player scores up one position in NVRAM so the sound status flag is no longer trashed.

If you want it to show a different version on power up, modifying the U6 ROM as below will change it from version 20 to 30 (sorry making it 21 is complicated).
$0800: CE ---> BE
$0807: 2F ---> 3F

I haven't checked but the 7-digit scoring code is potentially also an issue with Paragon and Six Million Dollar Man.

Yes, by modified I meant the U2 file in the kissb set.

That version mod is for U6, not U2. if you make those changes to U2 it won't boot.

Cool.

kissd already exists as the divide by 10 scoring version.
First thing is to get Olivers blessing for a release. I will get in touch with those who know him.

Good point. Anyway waiting to hear back.

Below look familiar? It's supported in PinMAME. It actually has the same sound problem.. When the lowest digit of player one is '8' or higher at the start of a ball, sounds don't play.

Kissd.png

There was discussion/work done on it over a year ago so it *should* work:
https://pinside.com/pinball/forum/topic/diy-lisy-a-replacement-mpu-for-gottlieb-bally-amp-stern/page/14#post-6451816

The discussion started in post #658 with the dual interrupt issue in both LISY and BallyFA.
I would have presumed the fix was also applied to LISY35 after it was corrected in BallyFA, but we have to wait for bontango to comment.

MAME/PinMAME catalogs the original images. That is one of the primary purposes of these emulation projects. What you have is likely what you're looking for.