APC in F-14

[Snux]

I think in addition to making the pixelstrip a few longer in the definition all I need to do is add 4 lines to the APC_LED code that handles the sync command.  Then if I update this first pixel on the ring from APC the rest should follow.  I think

case 170:								// sync command
	Sync = 0;							// the next four cycles (8 bytes) represent a lamp pattern
	Ring = pixels.getPixelColor(54);			// Get the color of the first ring pixel
	for (i=55; i<70; i++) {
		pixels.setPixelColor(i,Ring);	// Set the rest of the ring the same
	}
	pixels.show();						// update the LEDs
	break;

 

Edited February 4, 2022 by Snux

[Snux]

That worked really well.  From pinmame exception code I catch solenoid number 8 (which used to be a real flasher there) and switch on/off lamp number 119.  The LED Arduino catches that and lights the whole ring.  I don't need APC to be able to control each LED on the ring individually.  I'll tidy up my wiring and post a video tomorrow.

One thing on the "nice to have" list..... when you press the button in the coin door to enable blanking, the LEDs remain in their last state.  Maybe have APC switch all the LEDs off?

Edited February 4, 2022 by Snux

[Black Knight]

vor 2 Stunden schrieb Snux:

I'm not sure if I'll reimplement that or not

If you're not going to do it, I will 😋. Just because I like your radar sweep and I want it for my F-14, too. And I don't think it'll be overly complicated to implement.  
The main advantage of letting the Nano/Mini do it is that in this case we'd be able to control the afterglow of the LEDs to give them the right 'smear' of the old radar screens.

For this we should add 'Send Command Code' to our LED commands. This would then send an arbitrary command byte to the LED_exp which would then start/stop the radar sweep.

vor 14 Minuten schrieb Snux:

Maybe have APC switch all the LEDs off?

Yeah,  I'm working on it, but it's not completely implemented yet. You can try to add LEDhandling(0, 0); to your USB_SwitchHandler as shown below, but then you're doing my testing.

void USB_SwitchHandler(byte Switch) {
  byte i = 0;
  if (!PinMameException(SwitchActCommand, Switch)){   // check for machine specific exceptions
    switch (Switch) {
    case 8:                                           // high score reset
      LEDhandling(0, 0);
      digitalWrite(Blanking, LOW);                    // invoke the blanking
      break;

 

[Black Knight]

vor 8 Minuten schrieb Black Knight:

You can try to add LEDhandling(0, 0);

Won't work, because the blanking signal will immediately reset the Exp_board before it can send the off command to the LEDs.

[Black Knight]

void USB_SwitchHandler(byte Switch) {
  byte i = 0;
  if (!PinMameException(SwitchActCommand, Switch)){   // check for machine specific exceptions
    switch (Switch) {
    case 0:
      digitalWrite(Blanking, LOW);                    // invoke the blanking
      break;
    case 8:                                           // high score reset
      LEDhandling(0, 0);
      ActivateTimer(30, 0, USB_SwitchHandler);
      break;

This should do the trick.

[Snux]

16 minutes ago, Black Knight said:

them the right 'smear' of the old radar screens.

I'll hunt around for my old code that handled the "smear" 

[Snux]

16 hours ago, Black Knight said:

For this we should add 'Send Command Code' to our LED commands. This would then send an arbitrary command byte to the LED_exp which would then start/stop the radar sweep.

That would be good.  If there some changes coming to the APC_LED code something else to consider might be making the fade-in/out optional.  It really looks good the way the LEDs are coming in and out like real bulbs, but in my F14 all the other inserts have LEDs in (not everyones choice, but I like them).  So they come on really quick and the ones controlled by APC act like real bulbs.  Not really noticeable except in "All Lamp Test" but it might be an option to make it configurable, maybe in the system settings where you already specify various LED things.

So a couple of videos now this all seems to be working.  One of booting up and some attract mode, including firing of the "flasher" which is the LED ring in the middle.  The other is of a 5 ball game to show that it plays just like an F-14 should.

 

 

[Black Knight]

Looks great, but are the alarm sounds at the beginning of the multiball seem to be a bit odd. 
It's been a while since I've played an F-14 so may be I'm wrong, but for me it sounds as if two different alarm sounds were played at the same time and interfering with each other. You might have to play one of those on the music channel to be able to have both simultaneously.

Edited February 5, 2022 by Black Knight

[Snux]

24 minutes ago, Black Knight said:

it sounds as if two different alarm sounds were played at the same time and interfering with each other

Yes, I noticed that too.  When I left it in attract mode for an hour or so, one of the sound bites in that was also a little odd, so I'll do a little more work on the exceptions code to sort out both of those.

[Black Knight]

If the alarm sequence is always identical then you could also combine both alarm sounds into one sound file. Might be even easier than playing one of them on the music channel.

[Snux]

It is always the same, I think I'll do that.  I did that with one of the sounds that plays when the ball is sitting in the shooter lane on ball 1 too.  I suspect there will be one or two more small adjustments as I play it some more.  But I'm really impressed with how it all works.  

[Black Knight]

vor 51 Minuten schrieb Snux:

But I'm really impressed with how it all works.  

At the end of the day it's all about teamwork. I was lucky to find guys like Ralf and Jan who had already done a lot of work and who were willing to deal with the APC also.  
And don't forget the early adopters like you who give valuable feedback. In summer it's 3 years since you joined the project.😃

vor 51 Minuten schrieb Snux:

I suspect there will be one or two more small adjustments as I play it some more.

Yeah, last week I suddenly got a missing sound file message from my Pinbot, almost 2 years after I thought I'd finished the sound files. But apparently it never got me so angry before, because when I kicked it I realized it has a phrase for the slam tilt.

Edited February 5, 2022 by Black Knight

[Snux]

The alarm sound turns out to be 2 different sounds played at 2 different timings.  I fixed one of them to play on the music channel and also found that I'd missed editing the sound file and removing the odd 1 second of clicking noise that some of them had after exporting from pinmame.  Multiball sounds better now!

[Snux]

Another little thing maybe on the to-do list - when the coin door button sets on the blanking, in addition to switching off the LEDs, it should probably stop any sounds/music which are currently playing.

[Black Knight]

Am 4.2.2022 um 19:13 schrieb Black Knight:

void USB_SwitchHandler(byte Switch) {
  byte i = 0;
  if (!PinMameException(SwitchActCommand, Switch)){   // check for machine specific exceptions
    switch (Switch) {
    case 0:
      digitalWrite(Blanking, LOW);                    // invoke the blanking
      break;
    case 8:                                           // high score reset
      LEDhandling(0, 0);
      ActivateTimer(30, 0, USB_SwitchHandler);
      break;

This should do the trick.

Did this work?

If yes then it might be better to move it to the PinMameExceptions, too. This would make it easier for you to keep track of your changes and it would let less room for trouble when merging updates to your personal repository. 
In the exceptions it'd look like this:

byte EX_F14Tomcat(byte Type, byte Command){           // Exceptions code for Tomcat, thanks to Snux for sending me this code
  switch(Type){
  case SwitchActCommand:                              // Check for switches  
    if (!Command) {
      digitalWrite(Blanking, LOW);                    // invoke the blanking
      return(1);
    else if (Command==8) {                            // high score reset
      LEDhandling(0, 0);
      ActivateTimer(30, 0, USB_SwitchHandler);
      return(1);

I started to rework the special commands for the LED_exp board. 
The first command is

void LEDallColorMode(byte Red, byte Green, byte Blue)

This will set the new standard color for all LEDs being turned on afterwards, so it's the 4th command from our list:

• TurnOnLED(byte LEDnumber)
• TurnOffLED(byte LEDnumber)
• LEDchangeColor(byte LEDnumber, byte Red, byte Green, byte Blue)  -> change the color of a particular LED
• LEDallColorMode(byte Red, byte Green, byte Blue) -> all LEDs being turned on afterwards get this color
• LEDallColorModeOff -> turn off the mode above - LEDs keep their color

This command is probable of little use to you, but it's the only one I could implement without having to change the code of the Exp board. The rest will follow.

[Black Knight]

vor 4 Stunden schrieb Snux:

when the coin door button sets on the blanking, in addition to switching off the LEDs, it should probably stop any sounds/music which are currently playing.

Almost forgot this one, but it's done now. If you do the change I proposed above then you should add the StopMusic/Sound commands to your exceptions also:

byte EX_F14Tomcat(byte Type, byte Command){           // Exceptions code for Tomcat, thanks to Snux for sending me this code
  switch(Type){
  case SwitchActCommand:                              // Check for switches  
    if (!Command) {
      digitalWrite(Blanking, LOW);                    // invoke the blanking
      StopPlayingMusic();
      StopPlayingSound();
      return(1);
    else if (Command==8) {                            // high score reset
      LEDhandling(0, 0);
      ActivateTimer(30, 0, USB_SwitchHandler);
      return(1);

 

Edited February 6, 2022 by Black Knight

[Snux]

On 2/6/2022 at 4:47 PM, Black Knight said:

Did this work?

No, not quite.  The sounds/music stopped (although some play again later as pinmame is still sending commands through).  To get the LEDs to switch off I got the following to work...

- explicitly call TurnOffLamp for each LED

- increase the timer counter to give enough time for those to process

- flag that we're going to blank, and check that in the exception for LampOnCommand

 

  static int going_to_blank = 0;
  switch(Type){
  case SwitchActCommand:                              // Check for switches
    if (!Command) {
      digitalWrite(Blanking, LOW);                    // invoke the blanking
      StopPlayingMusic();
      StopPlayingSound();
      return(1); }
    else if (Command==8) {                            // high score reset
      for (int i=65; i < 119; i++) {TurnOffLamp(i);}
      ActivateTimer(500, 0, USB_SwitchHandler);
      going_to_blank = 1;
      return(1); }
    else if (Command > 64 && Command < 72) {               // If special solenoid switch
      if (QuerySolenoid(24))                          // Check if the flippers are active
        return(0);                                    // If they are active then permit the switch
      else
        return(1);}                                   // otherwise block it, standard Sys11 behaviour
    else
      return (0);
 // Second Sortie has a number of insert lamps (the clear ones) and all the GI replaced with RGB LEDs.
 // So if Pinmame tries to access one of them, we need to catch it and divert to the RGB instead
 // The RGB lamps are those above number 64, starting with 37 GI lamps, followed by 16 inserts
  case LampOnCommand:                                 // turn on lamp
    if (going_to_blank) {return(1);}

 

Using 

LEDhandling(0, 0);

I couldn't get it to do anything useful.  From what I can see on it's own it doesn't actually switch the LEDs off.  If it's after the loop for turning off the LEDs it happens too quickly, so not all the commands get through.

At some point we could probably make one of the LED "commands" to be "switch all the LEDs off" and just send that before blanking.

But...... I'm having *so much* fun just playing F14 (via pinmame) again.  My machine has been down for quite a long time now, and even when it was working last the LEDs were still connected to the Fadecandy so pinmame didn't drive them.  Now it's playing 100% like the original MPU etc.  Really cool.

My next job is to spend some more time studying the Pinbot and Black Knight code you've done, then decide if I want to do F14 in C, or MPF.  

[Black Knight]

Am 7.2.2022 um 19:10 schrieb Snux:

I'm having *so much* fun just playing F14 (via pinmame) again.

I'm glad you're having fun even though my envy is growing.

Basic color commands are also implemented, but I need to do a bit more testing.

[Snux]

So I'm managing to crash my Due somehow.  Tried it with a second one and it's doing the same, so I pretty certain it's software.

I've taken a first pass at F14 code just to get a feel for the framework.

https://github.com/Snux/APC/tree/SnuxPrivate

I can go into System Settings, choose the F14 game and play it.  It's only ejecting a ball, which I plunge and it then end up in the right lock. Game ejects the ball, ball into outhole.  Repeat twice and game over.  But it's a start.

However I'm getting issues in the System Settings reverting back to a different game.  It's not consistent about when, but at some point going through the settings to change the game back to USBControl and trying to get to save the settings, the Due crashes.  Displays either blank, or some random bright garbage.  Only power cycling brings it back.  Occasionally if I'm quick and lucky I can get the menu to the Save Settings and then I'm OK, but mostly it dies before I get there.

I can fix things by deleting the APC Settings file from the SD card, then setting back up USB Control and it seems to be OK (Lisy is running and playing).  I can then select F14 and "play" that.  But trying to go back to USBControl crashes things.

Any ideas?

Edited February 9, 2022 by Snux

[Snux]

I should say I can replicate this by switching to the Base Code game, saving it, restarting and then trying to go back to the USBControl game.  Often hangs up somewhere in the menu with bright garbage on the display.  So maybe it's not something I did?

Edited February 9, 2022 by Snux

[Black Knight]

You just switch from USBControl to BaseCode and back to make it crash? 
That definitely works here and I never had issues with the settings.

Does the problem persist if you use my V00.23 instead of your SnuxPrivate? If no then I have to try your SnuxPrivate tomorrow.

[Snux]

I'll do a clean pull tomorrow of your v23 and will update with what I find. 

[Snux]

OK, so it crashes with your v23 too, on both of my Due's.  So it is either a software issue, or something is strange in my F14.

I've taken a video to show the problem.

The Due has a clean compile of v23 from your Github, and I've deleted the APC_SET.BIN file from the SD card so we can be at a known state.  In the video I then change system settings so Lisy can play and show that working.  Then I switch to the Base Code game just to show it runs.  Then I try to change back to USB control and the system crashes before I get chance to save settings.  The only buttons I am pressing during this are the setting button in the coin door and the start button on the cab.

 

[Black Knight]

I guess this is caused by Lisy interfering with the settings menu.  
Lisy has control as soon as you change the 'active game' setting to 'remote control', even while you're still browsing the settings menu. That means if you're fast enough to exit the settings before the Pi has bootet then everything is fine, but if you're too slow then it might go wrong.

You can check this by connecting Jumper 1 to disable the autostart of Lisy.

However, this is something I wanted to fix anyway, so I'm going to take a look at it.

But I'm a bit disappointed that you don't like the elaborate ruleset of my BaseCode. 😉

[Snux]

27 minutes ago, Black Knight said:

I guess this is caused by Lisy interfering with the settings menu

That seems to be the answer, disabling auto-boot has given no crashes with several tests.

29 minutes ago, Black Knight said:

However, this is something I wanted to fix anyway, so I'm going to take a look at it.

I guess maybe set some flag when in settings and have usbcontrol ignore incoming commands during that time.

28 minutes ago, Black Knight said:

But I'm a bit disappointed that you don't like the elaborate ruleset of my BaseCode. 😉

The gameplay is a bit boring, but the attract mode lamps are awesome