APC in F-14

[Black Knight]

I've uploaded a new V00.23 version which avoids interference between Lisy and the settings menu. Basic communication still works in the background, just any consequences on the APC side are blocked.

I also tested the new color commands and wrote a preliminary documentation.  
Apparently I already included most of the stuff in the SW of the LED_exp board previously and I decided to stick to it which means that the commands are slightly different than we specified them.

However, they should be suitable for you also.

Note that you also have to update the SW of your Nano for this.

Bearbeitet 12. Februar 2022 von Black Knight

[Snux]

Thanks for that, I'll try pulling the updates and will let you know how it goes.

I've started with some first steps in the F14 code and will post an update later today.  I'm looking at first slowly implementing the rules from the original game (that way I don't have to make up new rules and learn the framework at the same time), then we'll see what happens after that.

[Black Knight]

If you're about to do more C programming I'd recommend not to do it in the Arduino IDE.  
Personally, I'm using Sloeber which is an Arduino plugin for Eclipse. You might have to read a short Eclipse how-to to become familiar with it, but it offers a lot of advantages. For example, it has an integrated Git client, a debugger and a lot of advanced navigation functions the Arduino IDE is just lacking.

Using the debugger is a bit tricky though as it doesn't support the DUE which means all DUE specific parts have to be removed from your code. I keep a special debugging version of the APC.ino for this purpose and I'll put it on GitHub and write some documentation about how to use it, if you decide to get more serious with C.

BTW I took a look to your Pinside thread and I think you forgot to include a link to this thread. You've mentioned that all technical stuff will be posted in the Flippertreff forum, but there's no direct link.

[Snux]

2 hours ago, Black Knight said:

I'd recommend not to do it in the Arduino IDE

Yeah, I'd already worked that out (I tried the beta Arduino IDE 2.0 but it's still quite basic).  I gave Sloeber a try for a couple of days and didn't really like it.  So I'm using Visual Studio Code with the Arduino extension and that seems to be working well (except the serial monitor).  For debugging I think for the moment a bunch of serial.print will probably be enough - I'm unlikely to be debugging deep inside the APC code.

I've got my F14 doing some simple handling of the Tomcat targets - they start off blinking, then switch on when you hit them.  Getting a target in the lower playfield also scores it in the top part (as F14 normally does).  Once you get all of them lit, they reset and start flashing again.

No scoring or anything else yet, but this was a good way to start learning.  I've also played for a very short time with the LED commands (I downloaded the new Sketch for the LED board) and I'm having mixed results.  It's probably something I'm doing a bit strange but I'll take a look some more in the next few days.

Here is a very bad video of today...

 

[Snux]

6 hours ago, Black Knight said:

but there's no direct link

Fixed 😁

[Black Knight]

vor 4 Stunden schrieb Snux:

I gave Sloeber a try for a couple of days and didn't really like it.

Yeah, Eclipse can be a bit clunky at times and if you're satisfied with your current ADE then there's no need to change.

vor 4 Stunden schrieb Snux:

I'm unlikely to be debugging deep inside the APC code.

Well I guess I used it more for Black Knight and Pinbot mainly because the critical parts of APC.ino were already done when I discovered it.

vor 4 Stunden schrieb Snux:

No scoring or anything else yet, but this was a good way to start learning. 

Looks like you made good progress and you got me to work also. Look what you've done:

I've actually started disassembling my F-14. Reading how much fun you have with yours reminded me that mine is rotting in a corner for 15 years 😲

[Snux]

15 hours ago, Black Knight said:

I've actually started disassembling my F-14.

Cool.  What I like about F14 compared to other pins is the adrenalin rush - it's very fast and brutal.  On some pins you can play a game for 10,15,20 minutes or more if you play well.  On F14 you've done well if you manage more than 5.

I'm going to continue implementing the ruleset from the original game (saving multiball for last although making some allowance for it) and once I have that 95% done I'll start to think about what I'm going to add. I have some notes somewhere about different modes I was going to add, one for each of the KILL lights at the bottom.  And getting the autolauncher to make multiball last a little longer

[Black Knight]

vor 8 Stunden schrieb Snux:

What I like about F14 compared to other pins is the adrenalin rush

And I like these 3 rotating beacon lights - Pinbot is also nice with it's lightbar, but no machine makes such a fuss as an F-14.

vor 8 Stunden schrieb Snux:

once I have that 95%

Yeah, the last 5% are the worst that's why my Pinbot is still not completely done.

Are there any open topics left on my to-do list? 
As far as I recall you wanted to have a parameter for the LEDs to change their turn on/off speed, but that was more mid term. And I think I'm going to increase the max number of LEDs to 192.
 

[Snux]

42 minutes ago, Black Knight said:

Are there any open topics left on my to-do list? 

I don't think so, but I still need to spend a little time on the LED colour changing, I only spent a few minutes and it didn't do what I expected, probably something goofy in my code.

I've made some good progress today with replicating the original F14 rules.

• Rescue kickback (left drain) now working.  It's made active when you hit the lit rescue lamp.  When a ball drains, it gets kicked back and you then get 2 seconds with it still active (and the outlane lamp blinking fast) as a "grace" period before it deactivates.
• Line of death kicker lights the next kill lamp
• Bonus and bonus multiplier lamps display correctly.

I now need to start putting in the initial scoring.  Somewhere I made some notes on what all the targets etc scored, but I can't find them, so will spend some time with pinmame over the next day or so working that out.  That and lots of other stuff.

[Black Knight]

vor 43 Minuten schrieb Snux:

get 2 seconds with it still active

Might be good to have this as a game setting. 
I'd recommend to remove the old BaseCode settings from your code anyway. They're only necessary because the BaseCode is supposed to work on all machines, but your F-14 code will just work on an F-14 so you can replace all game_settings[Whatever] with the actual value. 
For example

ACselectRelay = game_settings[F14set_ACselectRelay]; // assign the number of the A/C select relay

wil just become

ACselectRelay = 14;                           // assign the number of the A/C select relay

And one thing I learned the hard way: keep track of your timers. 
When I started coding I activated timers and just killed them when I didn't need them any more. But this requires strict discipline or you'll end up with an 'Error 11' which means you have tried to kill a timer which isn't active. This is not immediately harmful and if the 'Debug Mode' is off then your system will continue to work, but it means you've lost track of your active timers and this can lead to really nasty problems if you kill the wrong one by accident. 
I've therefore started to avoid Activate- and KillTimer commands for independent processes which run in the background. Instead I call the subroutines and let them do it by themselves. 
One example:

void PB_EyeFlash(byte State) {                        // Blink both lock flashers
  static byte Timer = 0;
  if ((State > 1) || ((State == 1) && !Timer)) {
    ActivateSolenoid(80, 10);
    ActivateSolenoid(80, 18);
    Timer = ActivateTimer(135, 2, PB_EyeFlash);}
  else {
    if (!State) {
      if (Timer) {
        KillTimer(Timer);
        Timer = 0;}
      ReleaseSolenoid (10);
      ReleaseSolenoid (18);}}}

It's handling the blinking of Pinbot's eyes. If I want it to start I call it PB_EyeFlash(1) and if I want it to stop it's Pb_EyeFlash(0).
The difference is that it keeps track of it's timer by itself which means it just ignores a 1 as an argument if the timer is already running and also doesn't try to kill it when it's not active. It's simple but makes life a lot easier.

[Snux]

11 hours ago, Black Knight said:

I'd recommend to remove the old BaseCode settings from your code

That's on my list of things to do.

11 hours ago, Black Knight said:

And one thing I learned the hard way: keep track of your timers

I hit my first Error 11 yesterday (due to a missing 'break' statement)

I've been referring to your PB code for pointers and ideas and am doing the same kind of thing for timers.  This is my code which handles the 2 rescue lamps/targets in the centre of the playfield.  They flip/flop between left and right being lit, then if you hit one while it's lit, then the kickback is switched on.  The only way for the timer for this flip/flop to be stopped is to pass the event to this routine.

// Event 0 = start the flip/flop between rescue targets
// Event 1 = stop the flip/flop
// Event 2 = left target hit
// Event 3 = right target hit
// Event 4 = light left target
// Event 5 = light right target
void F14_RescueTargetHandler(byte Event){
  static byte lit_target = 0;  // 0 is left target, 1 is right target
  static byte rescue_target_timer = 0;
  switch(Event) {
    case 0:
      F14_RescueTargetHandler(4);  // just call the start for the left lamp
      break;
    case 1:  // kill the timer and switch the lamps off
      if (rescue_target_timer) {
          KillTimer(rescue_target_timer);
          rescue_target_timer = 0;
        }
        TurnOffLamp(5);
        TurnOffLamp(7);
      break;
    case 2:
      if (lit_target==0){
        F14_RescueKickerHandler(0); // left target hit and is lit, call the kicker handler
      }
      break;
    case 3:
      if (lit_target==1){
        F14_RescueKickerHandler(0); // right target hit and is lit, call the kicker handler      
      }
      break;
    case 4:  // Light left target
      lit_target = 0;
      TurnOnLamp(5);
      TurnOffLamp(7);
      rescue_target_timer = ActivateTimer(1000, 5, F14_RescueTargetHandler);  // move to right in 1 sec
      break;
    case 5:  // Light right target
      lit_target = 1;
      TurnOnLamp(7);
      TurnOffLamp(5);
      rescue_target_timer = ActivateTimer(1000, 4, F14_RescueTargetHandler);  // move to left in 1 sec
      break;

  }
}

 

[Snux]

Something odd in the LED handling I think.

If I call TurnOnLamp inside the F14_init for LEDs (I switch on the GI there) then it works.  However in the main "game loop" where switches are handled by F14_GameMain they don't.  Normal lamps work fine, but not LEDs.

I've narrowed this right down.  If I use for example TurnOnLamp(115) from the init routine, the LED lights.  If I do the exact same command in F14_GameMain (as response to a switch) the LED does not light.  But normal matrix lamps (< 65) are fine.

I'm running your v23 on the APC and the LED arduino, no changes to either.

 

Any ideas?

[Snux]

Should add it's not a hardware issue, since Lisy / USBControl are fine.  The command TurnOnLamp(115) is part of the pinmame exceptions and behaves as expected

[Black Knight]

Sounds like the initialization goes wrong. To be honest I only tested it with USBcontrol, because I can send test commands via USB in this mode.

I'll try to reproduce it tonight with a real game SW.

[Snux]

Thanks.  If I try that TurnOnLamp(115) from within F14_init then it works.  It's strange because looking at APC.ino that gets called before LEDinit.  But it should be the same for USBControl, which is why I don't quite understand what the difference is.

This is where I put a one line for forcing a specific lamp and it doesn't work.  I have other code trying to light LEDs too and they don't respond either.  But lighting them from F14_init will turn them on.

https://github.com/Snux/APC/blob/SnuxPrivate/F14.ino#L534

[Black Knight]

Same here. It works when called from USBcontrol, but not from my Black Knight game.

Init is correct and the turn on command reaches the LEDhandler. At the moment I have no idea why it doesn't work. Apparently that needs some more serious debugging.

[Snux]

Well at least it means I'm not doing something stupid 🙂

[Snux]

In attract mode, when you press the start button, there is a KillAllTimers call. Is it breaking a timer for the LEDs? 

[Black Knight]

Found it. It's the KillAllTimers in the BK_AttractModeSW routine. It actually kills all timers including the one from the LEDhandler.

Using KillAllTimers here is really bad style which needs to be changed anyway. I'm going to do some rework here and stop all timers properly. 

[Black Knight]

That was simultaneously.

Bearbeitet 15. Februar 2022 von Black Knight

[Snux]

Thanks, let me know when you've refactored that code and I'll make the same changes in F14, I have plenty of other things to do at the moment

I do have a couple of other things which maybe you can put on the to-do list "sometime".  Again certainly not urgent.  Both related to lamp patterns.

At the moment it doesn't account for the "backbox lamps".  When you get to F14 you'll find it doesn't have matrix lamps in the backbox, just GI and some flashers.  So all the matrix lamps are on the playfield, but the lamp pattern functionality will only process 7 columns out of 8.

The other piece is probably more complex, maybe handling the LEDs in the lamp pattern somehow.  That structure for holding the patterns is going to end up very wide

[Snux]

One other thing related to lamp patterns.  I was about to start putting one together to run a short strobe of the 1k to 64k bonus lamps.  F14 original code does that when the ball goes through the left inlane, to highlight that a shot to the VUK will award a launch bonus.

However if I'm reading it right, the rest of the playfield matrix lamps will switch off during that which isn't quite what I want it to do.  So I can just write my own handler for it (it's only 7 lamps and some timer work) but had an idea which for the APC code which might work and might not be too tricky.  In addition to specifying PatPointer, FlowRepeat and LampReturn, how about supplying a bitmask for which lamps you actually want to control in the pattern?  Value of 0 means don't control this in the pattern, just take whatever is in the regular LampColumns buffer for it.  Value of 1 means do control it from the lamp pattern (or the other way around if it makes the bit operation easier).  It could default to control all lamps if not specified, that way existing patterns would continue to work the same as now.

[Black Knight]

vor 9 Stunden schrieb Snux:

So all the matrix lamps are on the playfield

OK, that means the 'backbox lamps' setting has to get a third option.

vor 8 Stunden schrieb Snux:

So I can just write my own handler for it

Yeah, I had to do this also for the chest lights of my Pinbot. We can think about about a routine for generic lamp animations, but I wouldn't combine it with the standard lamp animation handler lest it becomes too messy.

Bearbeitet 16. Februar 2022 von Black Knight

[Snux]

A little documentation update ...

PlayFlashSequence - probably worth mentioning that the C side flashers (solenoids) start at number 25......

[Snux]

Lots of dumb questions coming now my code is moving further.  So, switch debounce.  I have some switches that will close/open a few times in a very short space of time before settling (mainly the areas where the ball can stop - locks and the vuk).  But I only want to process that switch activation once.  I put this code at the start of my F14_GameMain....

void F14_GameMain(byte Event) {                        // game switch events  

  static unsigned long prev_switch_hit[71];
  unsigned long time_now;

  time_now=millis();
  if (time_now - prev_switch_hit[Event] > 200) {
    prev_switch_hit[Event] = time_now;
  }
  else {
    return;
  }

 

So basically on every switch event it's making sure that at least 200ms have passed since that event was previously processed.  If it's less than 200ms it ignores the switch.  It seems to be working fine, but is there a more "clever" way I should do this?  I took a quick look at APC.ino to see if there was any debounce allowance in there but after 5 seconds I got a headache

The only issue I can see with the above is that if my F14 is powered on for more than 50 days the timer will wrap back around to zero

Bearbeitet 17. Februar 2022 von Snux