Hello,
now as my LISY1/LISY80 stuff is running fine (www.lisy80.com), I'm working on the next step, meaning providing 'LISY35' where the plan is to emulate all these old bally/stern games which were produced between 1977 and 1985.
See picture of LISY35 prototype attached, which has working displays, switches and solenoids (at least for my Mata Hari pinball) so far.

For the lamps however I have some difficulties, as it looks like that theory and practice do differ.

Ballys 'Theory of Operations' says:
When an SCR is turned on, it will stay on for the reminder of the supply line alternation (1/120 second) and turn off
at the next zero crossing. It will stay off unless the next update again drives the gate high.

For me this means:
Each of the 15 SCR assigned to one Decoder (14514) is energized 1/120 second and will be off while the other 14 lamps are energized ( 14/120 seconds ).
Each 'switch' of lamps will be initiated by an zero crossing interrupt. So in theory I should see 15 zero crossing interrupts for each update interval.
However by looking into pinmame and look 'what happens' by inserting some debug lines, I see only one zero crossing interrupt at the beginning of the whole update interval.

Is my 'theory' wrong or do I just miss some debug outputs from pinmame?
Anyone have a code 'snippet' (‘C’ preferred) which shows how the lamp driver can/should be controlled?
Any help appreciated.

thanks
Ralf

LISY35_Board_beta (resized).jpg

zacaj Quench Many thanks for your feedback,
so looks like the debug messages from pinmame are OK, where my theory is wrong ...

Thinking now how to implement it in my PIC Chips, can you give me some advice on the 'timing'?

Background:
I pasted below the first seven activities in a typical update cycle together with a time stamp in microseconds.
These time stamps may not be accurate as coming from pinmame, but at least I can see the relation to the zero crossing.
Within pinmame I see:
- one zero crossing each 5ms ( I would expect to see it each 10ms, because of the 50Hz here in Europe, so we may have to multiply with two here)
- approximate 500 microseconds for one full update cycle

Each 4-line block is updating four SCR in parallel ( because of four decoder chips ), and I can see the address going up: 0,1,2,3,4,5,6
But looking to the time between the command after the strobe which sets the inhibit lines for the decoders
and the start of the next sequence which sets all inhibits to '1' again (resulting in all lamps going off)
it is only around 7-8 microseconds where one lamp is ON in each update sequence.

Having 100 updates each second one lamp is ON only 0,7-0,8ms out of one second
because of the inaccurate timing out of pinmame lets assume its 2ms.

I still wonder if that's enough to give the user the imagination that the lamp is steady ON, as it is only 0,2% of the time?!

Do you know what is the correct 'on time' for each SCR in one update cycle?

thanks
Ralf

----

24110725 zero cross
24110789 pia A: address:0x00 data(inhibit)0x0f
24110796 strobe(CB2) 1
24110802 strobe(CB2) 0
24110807 pia A: address:0x0f data(inhibit)0x0e

24110815 pia A: address:0x01 data(inhibit)0x0f
24110821 strobe(CB2) 1
24110826 strobe(CB2) 0
24110831 pia A: address:0x0f data(inhibit)0x0f

24110838 pia A: address:0x02 data(inhibit)0x0f
24110844 strobe(CB2) 1
24110849 strobe(CB2) 0
24110854 pia A: address:0x0f data(inhibit)0x0f

24110861 pia A: address:0x03 data(inhibit)0x0f
24110867 strobe(CB2) 1
24110872 strobe(CB2) 0
24110877 pia A: address:0x0f data(inhibit)0x0f

24110884 pia A: address:0x04 data(inhibit)0x0f
24110890 strobe(CB2) 1
24110896 strobe(CB2) 0
24110901 pia A: address:0x0f data(inhibit)0x0f

24110907 pia A: address:0x05 data(inhibit)0x0f
24110913 strobe(CB2) 1
24110918 strobe(CB2) 0
24110924 pia A: address:0x0f data(inhibit)0x0e

24110930 pia A: address:0x06 data(inhibit)0x0f
24110936 strobe(CB2) 1
24110942 strobe(CB2) 0
24110947 pia A: address:0x0f data(inhibit)0x0f

That's it, I was under the imagination hat the code does also switch off the lamp, but yes we have a thyristor here, not a transistor driving the lamp

Yes, soldering the missing components are now the next step. I just wanted to have the lampcode for the PIC ready, until now it was only pinmame debug.
The output of the zero crossing detector will go to an interrupt line of the PIC, which will do the lamp refresh, and I may spend an extra LED indicating that there is a (working) zero crossing detection in the next hardware release of LISY35.

Many thanks for enlighten me , will update this thread as soon as it all works

I guess that should be possible as, in contrary to the original design, with LISY switch strobing and display refresh is done by separate components (PICs).
Do you have an advice/link for me to a type of LED device where flickering is visible best?

UPDATE:
Took a bit more time than expected, but finally it works now
It turned out that the interruptroutine on the PIC was too fast, so that the ignition of the thyristors came in an early state.
Now with a delay of 80 microseconds the lamps looking OK.

I would like to prevent to identify the best delay with 'try and error', so anyone has the right delaytime
for me (time between interrupt condition -zeor cross - and first activation of a thyristor)
and (second question) any idea how to implement the delay in hardware rather than to have a delay in an interrupt routine?

Yes, that's true. In general I look how bally does it and 'rewrite/optimize it as I need to code it in 'C' for the PIC anyway.
So from the original timing you posted, I'm way shorter with my 80us already.
I will go with the 'try and error' method then by shortening that 80us delay and see where the boundaries are,
let you know about the result

PS:
If you are interested in the details:
For LISY35 I'm totally independent of the timing in the bally rom code.
Within pinmame, when running the bally code, I just 'look' what lamps should be activated and send that as
a command via I2C bus to the PIC. ( 'e.g. switch lamp 23 to ON' ). The lamp driver refresh code runs in an interrupt routine on the PIC.

See below excerpt of the interruptcode, where AD0..3 are the adresslines, PD0..3 are lamp data and LAMPSTR1 is strobe 1.
The array inhibit[] is set in the PIC main loop to keep the interruptcode short, and will be modified there according to the received commands.

for ( address.byte = 0; address.byte <= 15; address.byte++ )
{
//set strobe to high
LAMPSTR1 = 1;
//inhibit (data) is all 1, we deactivate all decoders
PD0 = PD1 = PD2 = PD3 = 1;
//set the address
AD0 = address.bitv.b0;
AD1 = address.bitv.b1;
AD2 = address.bitv.b2;
AD3 = address.bitv.b3;
//wait a bit (needed?))
_delay_us(10);
//set strobe to low, this will strobe address into the decoders
LAMPSTR1 = 0;
//wait a bit before ignition (needed? yes, but value to be determined))
_delay_us(80);
//set the rigth inhibit for this address
PD0 = inhibit[address.byte].bitv.b0;
PD1 = inhibit[address.byte].bitv.b1;
PD2 = inhibit[address.byte].bitv.b2;
PD3 = inhibit[address.byte].bitv.b3;
}

You are right, I do convert it within pinmame, send it to the PIC and convert it 'back' there.
I could do send just the PIA outputs which would spare me a bit of converting on the pinmame side.
It's more coding yes, but debugging within pinmame is much simpler ( I do the same for coils, switches, displays )
and the time delay for two times converting are not that much, so it's (kind of ) immediate too.

Another plus is that I can use the same 'lower' LISY routines within pinmame and on the PICs, especially for the I2C communication
for all my LISY systems ( LISY1, LISY80, LISY35) which helped me a lot creating LISY1 and LISY35 after LISY80 ( the first system) was ready.

So, marked this as 'solved' here. I modified then interrupt code in the way that there
is a big delay at the very start ( 800us, thanks to Quench for the calculation ) and deleted the others in the loop.
Works perfect so far See below corrected interrupt routine
Thanks for your help

if (INTCON3bits.INT1IE && INTCON3bits.INT1IF) //external INT/RB1 interupt
{
//this is the refresh cycle for the lampdriver

bitv_t address;

//wait a bit before first ignition
_delay_us(800);

for ( address.byte = 0; address.byte <= 15; address.byte = address.byte +1)
{
//set strobe to high
LAMPSTR1 = 1;
//inhibit (data) is all 1, we deactivate all decoders
PD0 = PD1 = PD2 = PD3 = 1;
//set the address
AD0 = address.bitv.b0;
AD1 = address.bitv.b1;
AD2 = address.bitv.b2;
AD3 = address.bitv.b3;
//set strobe to low, this will strobe address into the decoders
LAMPSTR1 = 0;
//set the rigth inhibit for this address
PD0 = inhibit[address.byte].bitv.b0;
PD1 = inhibit[address.byte].bitv.b1;
PD2 = inhibit[address.byte].bitv.b2;
PD3 = inhibit[address.byte].bitv.b3;

}

INTCON3bits.INT1IF = 0; // clear this interrupt condition
}

At the point in time the picture was taken, the PCB was just incomplete, see attached current situation.
It is the circuit Bally is using, the output then feeds an external interrupt pin on my PIC.

btw: First tests with different Bally games finished, at least Evel Knievel, Eight Ball, Mata Hari and Harlem Globetrotters are reported to work 100%
So Testphase II with Version 1.0 of LISY35 will start soon

LISY35_Board_beta_02 (resized).jpg