APC in F-14

[Snux]

Posts will be in a mixture of English and German (tut mir leid), but as there are lots of other APC threads here seems like a good place.

I have APC in my Tomcat, with Lisy, just the displays, switches and speakers connected.  Seems to run fine so far, displays are showing the attract displays.

I've pulled most of the sound files from the ROMS and am working through those.  Mostly OK although there are some sounds that Lisy is calling to be played that don't actually exist in the ROM so they might be "commands" of some kind rather than actual sounds/music. I'll do some more debugging to determine what happens there and will start to put together a pinmame exceptions file for F14.

[Snux]

From looking at the Pinbot pinmame exceptions I can already see what most of this is, and can copy quite a lot of it......

[Black Knight]

vor 7 Stunden schrieb Snux:

Posts will be in a mixture of English and German

Pure English is even better as I still hope that threads like this can help people to get an impression of what they're dealing with when using the APC. So depending on how this thread grows I might want to reference it on the APC homepage at some point in time (only if it's OK for you of course).

Apart from that I'm determined to revive my own F-14 this year (Playfield inserts are so worn out that you can't really play it). 
I already have a spare APC 3 board here to install it, but I'm still lacking some inspiration what to do with it. Therefore I'd be very interested to learn more about your project.

[Snux]

43 minutes ago, Black Knight said:

Pure English is even better

Sounds like a plan

I connected the coils and lamps and crossed my fingers.  No smoke!  I have the sounds extracted for F14 and started on the pinmameexceptions for it - you can see the audio debug is showing in the displays at the moment.  I need to work through the music and split the intro/loop parts and some other specific things I've noticed so far.

 

 

Bearbeitet 18. Januar 2022 von Snux

[Snux]

44 minutes ago, Black Knight said:

I'm still lacking some inspiration what to do with it

I came up with some ideas in the several years that my Pinside thread has been running, although I'm still basically at the start...

https://pinside.com/pinball/forum/topic/f14-tomcat-second-sortie-information-and-on-going-development

I made an additional hardware change of adding an autolauncher, that gives so many more possibilities for multiballs.

Last I was using MPF, but struggling to persuade it to handle the locks properly - when you launch a ball it always has to travel through a lock and take care of ejecting an existing ball if there is one in there.  I'm partly tempted to try programming in C on the Arduino - the BK and Pinbot examples are quite inspiring.   Let's see.

As for your playfield, there are new ones being made I think.

[Black Knight]

I totally forgot that you already have a thread for your F-14 on Pinside. Not sure whether it makes sense for you to have both in parallel. For me it would also be OK to have our discussions on Pinside and just have the link here.

[Black Knight]

vor 22 Stunden schrieb Snux:

I'm partly tempted to try programming in C on the Arduino

Most of it is quite straightforward. If you decide to go this way I'll support you of course. But it's still going to take a while until I'm able to run code on my own F-14.  

vor 22 Stunden schrieb Snux:

As for your playfield, there are new ones being made I think.

A friend of mine has recently aqcuired a bunch of F-14 playfields in reasonable condition. I think I'm gonna grab one of those...

 

Bearbeitet 19. Januar 2022 von Black Knight

[Snux]

I think I'll put pure technical stuff about APC/Lisy here, and link back from my Pinside thread, and keep the Pinside thread for game development.

Still working on the sounds at the moment, like Pinbot there is some slightly weird things happening with a couple of sounds, but I'll get them into the exceptions code.  I'm also going to make some extension cables because it's a real mess in my backbox!

One thought for an improvement but not urgent...  with pinmame running, if I long-press the door button I get into APC settings (for Game/System).  It would be great at that point if we could ignore what's coming in over USB (at least for the displays). The displays for APC settings constantly get overwritten by what Pinmame is sending.

Also - pressing the high score reset button inside the door invokes blanking and you have to power cycle to bring things back.  I guess that was intentional as an "emergency stop"?  

@bontango- there is another piece of code I developed for pinmame/P-ROC/Sys11 that I think you should also use for Lisy/Sys11.  Not urgent though.

https://github.com/vpinball/pinmame/blob/master/src/wpc/s11.c#L244

Basically in a physical machine the PIA states are unknown on power-up, so the WMS code resets all the coils to a known state by driving them on and off.  This doesn't normally fire them physically as the blanking signal is still active.  Once things are in a known state, blanking goes off and the game plays.  For the P-ROC blanking came off a lot earlier and I blew lots of fuses during testing because all the coils fired at the same time.  So my code fix simply looks for the "all coils driven" state and ignores it.  With Lisy I'm seeing in the debug log right after it loads the ROMs the solenoid handler fires all solenoids from 9 to 16 (but not *all* solenoids) in less than 1ms.  Doesn't blow a fuse but makes a loud noise!  This is from the log, you'll see the coils firing at the end.  So if we can avoid sending that, it would be good.

LISY basic DEBUG activ
[126.537295][0.000016] LISY DEBUG timer set
[126.537547][0.000252] Info: udp switch reader server for debug mode succesfully started
[126.537575][0.000028] LISY APC Hardware init start
LISY_Mini: HW Client is: APC 
Info: serial com successfull initiated
[127.539176][1.001601] check if connected hardware is"APC"
[127.540055][0.000879] connected HW is: APC
Info: check ID for 'APC' returns 0
[127.541087][0.001032] LISY_Mini: Client has SW version: 00.22
[127.542013][0.000926] LISY_Mini: Client uses API Version: 0.10
[127.542588][0.000575] LISY_Mini: Client supports 65 lamps
[127.543146][0.000558] LISY_Mini: Client supports 25 solenoids
[127.543697][0.000551] LISY_Mini: Client supports 5 displays
[127.544434][0.000737] Display no:0 has type:0 (Display index is invalid or does not exist in machine.) with 0 segments
[127.545174][0.000740] Display no:1 has type:4 (SEG14,Fully addressable 14 Segment Display (with comma)) with 7 segments
[127.545911][0.000737] Display no:2 has type:4 (SEG14,Fully addressable 14 Segment Display (with comma)) with 7 segments
[127.546645][0.000734] Display no:3 has type:3 (SEG7, Fully addressable 7 Segment Display (with comma)) with 7 segments
[127.547413][0.000768] Display no:4 has type:3 (SEG7, Fully addressable 7 Segment Display (with comma)) with 7 segments
[127.547965][0.000552] LISY_Mini: Client supports 73 switches
Switch Status 1..8;9..16;17..24; ...:
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 
advance: 0
UP/Down: 0
[127.589854][0.041889] LISY DEBUG activ for coils
[127.594089][0.004235] Info: LISYAPC Throttle value is 120 for this game
LISY_APC: we are emulating Game No:44 f14_l1
info: trying to parse: /usr/local/share/xpinmame/xpinmamerc
info: trying to parse: /root/.xpinmame/xpinmamerc
info: trying to parse: /usr/local/share/xpinmame/xpinmame-vid_lisyrc
info: trying to parse: /root/.xpinmame/xpinmame-vid_lisyrc
info: trying to parse: /usr/local/share/xpinmame/rc/f14_l1rc
info: trying to parse: /root/.xpinmame/rc/f14_l1rc
Info: internal Hardware revision is 122
LISY80_SIG_HANDLER: SIGUSR1 catched
This is LISY (Lisy W) by bontango, Version 527 67
[127.890058][0.295969] Info: LISYMINI this game has AC Relais on solenoid 14
[127.890209][0.000151] Info_boot: System_ID: SYS11A_
[127.890250][0.000041] Info_boot: gamename: F-14 TOMCAT 
[127.890289][0.000039] Info_boot: S2 Setting: 44
[127.890325][0.000036] Info_boot: SW Version: 527 67
[133.893444][6.003119] LISY_Mini: no special hw rules found for game 44, setting defaults
[133.893516][0.000072] LISY_Mini: HW Rule set for solenoid:17 and switch:65
[133.893563][0.000047] LISY_Mini: HW Rule set for solenoid:18 and switch:66
[133.893602][0.000039] LISY_Mini: HW Rule set for solenoid:19 and switch:67
[133.893639][0.000037] LISY_Mini: HW Rule set for solenoid:20 and switch:68
[133.893676][0.000037] LISY_Mini: HW Rule set for solenoid:21 and switch:69
[133.893711][0.000035] LISY_Mini: HW Rule set for solenoid:22 and switch:70
loading rom 0: f14_u26.l1  
loading rom 1: f14_u27.l1  
done
[134.366845][0.473134] LISY_W_SOLENOID_HANDLER: Solenoid:9, changed to 1 ( AC is 0)
[134.366928][0.000083] LISY_W_SOLENOID_HANDLER: Solenoid:10, changed to 1 ( AC is 0)
[134.366969][0.000041] LISY_W_SOLENOID_HANDLER: Solenoid:11, changed to 1 ( AC is 0)
[134.367007][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:12, changed to 1 ( AC is 0)
[134.367045][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:13, changed to 1 ( AC is 0)
[134.367094][0.000049] LISY_W_SOLENOID_HANDLER: AC-Relais changed to 1
[134.367132][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:15, changed to 1 ( AC is 1)
[134.367170][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:16, changed to 1 ( AC is 1)
[134.413571][0.046401] LISY_W_SOLENOID_HANDLER: Solenoid:9, changed to 0 ( AC is 1)
[134.413623][0.000052] LISY_W_SOLENOID_HANDLER: Solenoid:10, changed to 0 ( AC is 1)
[134.413662][0.000039] LISY_W_SOLENOID_HANDLER: Solenoid:11, changed to 0 ( AC is 1)
[134.413835][0.000173] LISY_W_SOLENOID_HANDLER: Solenoid:12, changed to 0 ( AC is 1)
[134.413876][0.000041] LISY_W_SOLENOID_HANDLER: Solenoid:13, changed to 0 ( AC is 1)
[134.413914][0.000038] LISY_W_SOLENOID_HANDLER: AC-Relais changed to 0
[134.413951][0.000037] LISY_W_SOLENOID_HANDLER: Solenoid:15, changed to 0 ( AC is 0)
[134.413988][0.000037] LISY_W_SOLENOID_HANDLER: Solenoid:16, changed to 0 ( AC is 0)
LISY80_SIG_HANDLER: received SIGUSR1
LISY80_SIG_HANDLER: initiated shutdown of xpinmame
LISY Mini graceful shutdown initiated

 

Bearbeitet 22. Januar 2022 von Snux

[Black Knight]

vor 1 Stunde schrieb Snux:

I think I'll put pure technical stuff about APC/Lisy here, and link back from my Pinside thread, and keep the Pinside thread for game development.

Makes sense.

vor 1 Stunde schrieb Snux:

It would be great at that point if we could ignore what's coming in over USB (at least for the displays).

Does also make sense. I'm going to take a look at this.

vor 1 Stunde schrieb Snux:

I guess that was intentional as an "emergency stop"?

Yes and it's also a good idea to press it before programming new SW into your Arduino. This is because after the programmer has stopped the Arduino it still takes a few ms before the blanking is invoked. During these ms the current display and lamp columns can light up much more than usual. This is not a big deal, but I think it's better to avoid it by pressing High Score Reset first, which invokes the blanking manually.

vor 1 Stunde schrieb Snux:

you have to power cycle to bring things back.

A power cycle is not necessary, you can also use the serial monitor of the Arduino IDE to trigger a reset.

BTW, as you're working with the Lisy debug mode at the moment - there's a more convenient way to use it then fiddling with the SD card. I've already put a preliminary documentation here. Please take a look at it and tell me whether it makes sense.

[Snux]

2 hours ago, Black Knight said:

Please take a look at it and tell me whether it makes sense

Now that is *nice*.  I hadn't bothered connecting Lisy to my WiFi as I didn't think it needed it, but this is very useful and indeed much better than fiddling with the SD card.  Might be worth putting in how to connect Lisy to WiFi to save finding the Lisy Manual and reading through to page 42 :).  It's only a few lines.... (I also had to change the country from DE to GB)

2 hours ago, Black Knight said:

Yes and it's also a good idea to press it before programming new SW into your Arduino.

Makes sense.

 

2 hours ago, Black Knight said:

you can also use the serial monitor of the Arduino IDE to trigger a reset.

I tend not to leave the Arduino connected to my laptop unless I'm actually going to program it.  If the pinball machine is switched off, all the 5v stuff remains powered (Arduino, Pi, my F14 LED displays etc), which all source their power from the USB output on my laptop and I'm not sure if that is healthy.  Works, but might be a bit more load than it should take.  But a power cycle for the few times when I hit the button by mistake is fine

Bearbeitet 22. Januar 2022 von Snux

[Snux]

I also found that the 'F6' approach to dumping the sounds from pinmame misses some of them.  I've seen Pinmame requesting music tracks which I don't have from F6.  I just assumed that these are some "odd" ones like I've seen mentioned in the Pinbot exceptions code, but actually those sounds will dump properly by F5.  Looks like I need to record some more

Bearbeitet 22. Januar 2022 von Snux

[Snux]

I worked around the coils firing on Lisy startup with a few extra lines in the exception code.  Lisy is always firing the same coils (9 to 16), so I just stop all coil activation until I've seen 16 for the first time..

byte EX_F14Tomcat(byte Type, byte Command){           // Exceptions code for Tomcat

  static byte waiting_for_reset = 1;                  // At the moment Lisy is activating coils 9 to 16 immediately on startup
                                                      // related to PIA initialisation in a real SYS11 MPU.  We want to ignore
                                                      // those so we'll wait until Lisy is reset properly
 switch(Type){
  case SolenoidActCommand:                            // activate solenoids
    if (!waiting_for_reset) {                         // if we have already seen the reset, just permit the coil activation
      return(0);                                      // by returning 0
    }
    if (Command == 16){                               // Coil 16 being activated for the first time is enough to know
      waiting_for_reset = 0;                          // that we can permit future coils, so unset the flag
    }
    return(1);                                        // return 1 to prevent that coil activation

 

[Black Knight]

Am 22.1.2022 um 12:53 schrieb Snux:

I tend not to leave the Arduino connected to my laptop unless I'm actually going to program it.

That's why I have removed the power switches on some of my Arduino boards. That means I can power my laptop and my pinball independently without any interference.

I just got the info from Kobza that he sometimes sees an 'Unknown command' message in his pinball display when the game runs in PinMame and he's working with sounds. That would mean that the communication between Lisy and the APC is out of sync whic usually happens due to an overflow in the serial receive buffer.

Do you also see something like this?

 

[Black Knight]

vor 4 Stunden schrieb Snux:

worked around the coils firing on Lisy startup with a few extra lines in the exception code.

Good point. I also see something like this with my Pinbot, but as only flashers are affected in my case I never paid much attention to it.

@bontangoDo you think that Lisy can prevent these first solenoid activation commands from being sent? Otherwise we would have to come up with individual Exceptions for each machine.

[Snux]

1 hour ago, Black Knight said:

Do you also see something like this?

The only time I see that is occasionally when I press the button to gracefully shutdown Lisy.  I guess that could be expected though because it might only send a partial and/or corrupted command when closing down.  I've not seen that at any other time.

[Snux]

So, I'm also almost done with the sounds for F14 for pinmame.  Manually edited each file to trim out some random noise at the start of each one and the exceptions file is 90% done to handle the few looping music tracks and suchlike. 

I also smoothed out a little the volume commands that are coming in as all values from 96 to 111 seem to be used when fading on F14.....

else if (Command > 95 && Command < 112) {  // music volume commands 0x6x
  MusicVolume = (Command - 96) / 4;}                                      

Finally played a couple of games without some odd sounds happening.

@Black Knight do you want to PM me an email address?  I have a zip file for you   When I have the sounds exceptions finalised I can also email you that code too for pasting into your Github.

[Black Knight]

vor einer Stunde schrieb Snux:

I've not seen that at any other time.

OK, that's good. 
The problem for me is that the required buffer size depends on how fast the SD card can open a file. The standard buffer size for the DUE is 128 byte which is enough for my SD cards, but if Kobza got a slower one then he might have to increase the buffer size manually. Means I have to add a description how to to it.

vor 36 Minuten schrieb Snux:

do you want to PM me an email address?  I have a zip file for you   When I have the sounds exceptions finalised I can also email you that code too for pasting into your Github.

Of course I want to have the files and I'd be glad to add your exceptions to the next SW release. How large is the ZIP file, can we transfer it by mail?

And what's your overall impression? Are you satisfied with the result? Anything mssing in the DOCs?

[bontango]

ups, might miss a lot of traffic here, sorry for not responding ...

 

Am 23.1.2022 um 13:48 schrieb Black Knight:

Do you think that Lisy can prevent these first solenoid activation commands from being sent? Otherwise we would have to come up with individual Exceptions for each machine.

 

Am 22.1.2022 um 08:51 schrieb Snux:

there is another piece of code I developed for pinmame/P-ROC/Sys11 that I think you should also use for Lisy/Sys11.  Not urgent though.

 

We should do it with LISY, will have a look tomorrow ...

 

 

[bontango]

Am 22.1.2022 um 12:53 schrieb Snux:

I hadn't bothered connecting Lisy to my WiFi as I didn't think it needed it, but this is very useful

I do also recommend doing updates via Internet and 'LISY_control', MUCH faster then writing a full image to

the SD and it keep your settings.

[Snux]

35 minutes ago, bontango said:

We should do it with LISY, will have a look tomorrow ...

No hurry at all, my workaround is doing just fine for now, but would be good to get a general fix.

 

On 1/23/2022 at 3:49 PM, Black Knight said:

How large is the ZIP file, can we transfer it by mail?

Hmm, too big to email, about 44Mb.  When I've done a last few checks I'll put it on Amazon S3 and send you the link.

On 1/23/2022 at 3:49 PM, Black Knight said:

And what's your overall impression? Are you satisfied with the result? Anything mssing in the DOCs?

Last time I used the APC was some time back, and I didn't really look much into the code base you've written.  Over the last few days I've been looking more deeply into the code you have running on the Due and the work that has been done with Lisy / USB and I have to say it's seriously impressive.  I've done some coding before for Arduino but only basic stuff, I learned lots from reading your code.  I'm still not decided whether to use MPF or just code in C for the Arduino direct.  I really hate Python .  Didn't spot anything missing in the docs so far, I found it quite straightforward to put it all together.  Less technical people might find things harder, but to be honest this is a technical subject, so I think it's fine.

[Snux]

I've been looking at the LED code and a quick way to get both matrix and LED strings working in my case.  I know you're thinking to develop things in this area, so for the moment this is only for me to hack on my machine.....

I think if I adjust the APC main code to drive both the matrix and the LED string at the same time (all 64 lamps in both cases) then the APC.ino does not need to change very much at all.  Then instead of adding code into pinmameexceptions I can change the code on the Arduino controlling the RGBs to just pick out the lamps in the input that it cares about and map them to the values in the chain.   So F14 lamp 32 might be RGB number 1, 45 might be 2 and so on.  This should be pretty easy to adjust back (and put in the exceptions code) if/when this area develops.

I don't have an Arduino mini, but I've got a spare Nano (spec should be fine) and some breadboad so I'll try with that first to see how it goes.

[bontango]

vor 17 Stunden schrieb Snux:

No hurry at all, my workaround is doing just fine for now, but would be good to get a general fix.

thanks to your hints it was just adding a few lines, I implemented it same way as you by ignoring 'FF00' calls.

It is in latest version of my 'test' LISY Image ( 5.28-13 ) where I also added latest 'SMOOTH' patch from 5.27-68

You need to do a 'full upgrade' as incremental update from 5.27 to 5.28 is not possible

http://www.flipperkeller.de/lisy_dev_sw/LISY_Image/test/LISY_Version_5_28-13.zip

Log is looking good ( I get two 'ignored' calls), please let me know if it works

Ralf

 

 

[Black Knight]

vor 23 Stunden schrieb Snux:

Didn't spot anything missing in the docs so far, I found it quite straightforward to put it all together. 

Sounds good. And I hope that the results feels like an F-14, which would mean I could add this machine to the 'works with PinMame and sounds are available' list?

vor 23 Stunden schrieb Snux:

APC.ino does not need to change very much at all.

Actually, my fix would be to implement a new command into the APC.ino that runs some LED lamps aditionally to the lamp matrix. The implementation is not much work but tricky, for it may require to touch the TC7_Handler() which is some kind of holy grail of the APC SW. This is very close to the HW and even though I don't doubt your ability to do it, it still would mean a lot of detective work for you to become familiar with it. 
I'd therefore suggest to wait just a bit longer. Kobza is currently busy with tu(r)ning the wheel SW of his Riverboat Gambler and the weather is still expected to be lousy next weekend, which means I might have some time to come up with a first try.

 

Bearbeitet 25. Januar 2022 von Black Knight

[Snux]

41 minutes ago, Black Knight said:

I hope that the results feels like an F-14

Give me a few more days and I'll confirm that but I don't think there is any issue.  I have some switches on my F14 playfield which need adjusting (they've needed adjusting for a long time, nothing to do with APC) then I can do a full test.  I also wondered if I needed to sort out a hardware/switch rule for the Yagov kicker and the left outlane kickback.  With MPF and P-ROC I had to set up a hardware rule otherwise the kickback used to fire just a little too late to save the ball.  With Lisy/APC it's saving the ball without needing any additional help which is nice.

 

6 hours ago, bontango said:

You need to do a 'full upgrade' as incremental update from 5.27 to 5.28 is not possible

Will do in the next few days, then I'll remove my workaround and see what happens.

 

41 minutes ago, Black Knight said:

I'd therefore suggest to wait just a bit longer.

That's fine, I've got plenty of other things to do.  In the meantime I'll put the LED/Nano board together.  I know I'll need to do some work on the pinmameexceptions for this anyway.  My GI has all been replaced with about 20 RGB lamps so I need to intercept the GI relay and have it drive those lamps instead.

 

  

41 minutes ago, Black Knight said:

the TC7_Handler() which is some kind of holy grail of the APC SW

Yeah, I'd already seen that.  I can see all the timings especially for displays and lamps are critical.  I'll leave all your code completely alone, I'll just add to the pinmameexceptions (and my own game code if I go that way).

Bearbeitet 25. Januar 2022 von Snux

[Snux]

21 hours ago, bontango said:

latest version of my 'test' LISY Image ( 5.28-13 )

That seems to have fixed the issue, thanks. I've removed my workaround and there is no unexpected coil activation at startup.

 

21 hours ago, bontango said:

I also added latest 'SMOOTH' patch from 5.27-68

I have to say I do not know what the patch was supposed to do, but my F14 still seems happy