APC in F-14

[Black Knight]

vor 3 Stunden schrieb Snux:

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

Done.

vor 2 Stunden schrieb Snux:

is there a more "clever" way I should do this?

For the lock of the Pinbot I did it with a flag:

  case 25:                                            // left eye
  case 26:                                            // right eye
    if (!PB_IgnoreLock) {
      PB_IgnoreLock = true;
      PB_AddBonus(1);
      ActivateTimer(1000, 0, PB_HandleLock);}         // handle locked balls after 1s
    break;

First the flag PB_IgnoreLock is checked and the switch is only processed if it's not set. After that it is set to ignore subsequent bouncing. Then a timer is called and the folowing routine PB_HandleLock resets the flag and queries the switch to be sure the ball is really there.

Today I'd probably do the state machine approach (like with the PB_ExeFlash) to avoid the global variable.  The routine would be called with Arg = 1 when the switch is triggered.

void Handler(byte State) {                        // Blink both lock flashers
  static byte Timer = 0;
  switch (State) {
    case 1:
      if (!Timer) {
        Timer = ActivateTimer(200, 2, Handler);}
      break;
    case 2:
      Timer = 0;

      Handle the switch

In this case the Timer variable blocks any additional calls as long as the timer is running.

Bearbeitet 17. Februar 2022 von Black Knight

[Snux]

OK, so your approach is to only worry about the switches that matter (so nobody cares if a target should register points 2 times instead of one), where my approach just says that no switch should activate twice in less than 200ms.  Which is true except perhaps for the spinner if that gets hit really hard, so I might have to either put a specific check in for that switch, but most likely I'll just accept an occasional missed "spin".  Both approaches are valid I think, let's see how it works as I move forward.

I've got most of the basic code done now, I managed to get the top orbit working with the bonus multiplier etc.  I need to add the "bonus countdown" with lamp display into the end of ball routine, and then to start thinking about the best way to structure the logic for the lock handling and multiball.

Another couple of questions for you if I may....

Score updating - I think this line https://github.com/AmokSolderer/APC/blob/V00.23/APC.ino#L1626 is the reason that the score for the current player only updates every 2 seconds.  That does look a little strange especially when hitting the spinner because it makes a lot of sound but the score doesn't change for a while.  Could we make it update more quickly?

LEDs.... I haven't touched the KillAllTimers yet because I haven't examined in detail the timers in the various ball handlers in the base code.  I noticed you committed one LED fix to APC.ino, but once you've worked out the basecode change to remove the KillAll let me know and I'll adopt it into my code.

[Black Knight]

vor 5 Stunden schrieb Snux:

so nobody cares if a target should register points 2 times instead of one

Due to the switch matrix every switch is queried every 9ms, so there's some debouncing already done in HW. From my experience this is enough for most cases, just balls bouncing back and forth in a lock or a VUK are causing problems. Hence there're not many switches that really have to have a debouncing. 
However for those who need it you can do it by calculating the millis or letting the timer do the counting. The latter has the advantage that you only have to store a byte for each switch (Timer number) and not a long, but the result is the same.

vor 5 Stunden schrieb Snux:

is the reason that the score for the current player only updates every 2 seconds.

No, this is just doing the blinking of the score of the active player. I guess you're just adding the points without calling ShowPoints(Player).

  Points[Player] += 1000;
  ShowPoints(Player);

This will add the points immediately and the score blinking is also skipped when points are added. 

vor 5 Stunden schrieb Snux:

once you've worked out the basecode change to remove the KillAll let me know and I'll adopt it into my code

Yeah, I'm doing some rework of the attract mode and ShowLampPatterns code. I'll keep you postet when there's an update available.

[Black Knight]

Am 18.2.2022 um 09:37 schrieb Snux:

let me know and I'll adopt it into my code

The new version is online.

To adapt your F-14 code to avoid the KillAllTimers command you can use the updated BaseCode as a reference. The BC_AttractDisplayCycle routine has changed quite a bit, so you should just copy it from the BaseCode and adapt it to your F-14 like you did before. 
Furthermore you need to change the F14_AttractDisplayCycle(0) at the end of F14_AttractMode() to F14_AttractDisplayCycle(1). The KillAllTimers in F14_AttractModeSW needs to be replaced by F14_AttractDisplayCycle(0) and this should be it.

About the lamp animations: you can now select 'none' in the 'Backbox Lamps' settings which means that no lamps are located in the backbox. This requires an additional byte in every line of the lamp patterns. I've already added these byte to BaseCode, Black Knight and Pinbot and you have to do it for your F-14 also. The obvious place for you to add it would be right after the duration since you want it to represent the first lamp column.

I did a bit of testing an I hope everything works fine. Have fun 😃

[Snux]

1 hour ago, Black Knight said:

The new version is online.

Yay, my LEDs are working again!  I suspect the problem with the timer also caused the colour issues I was seeing, I'll try those again soon.

My lock / divertor handling code is almost working.  I can lock 3 balls, I just need to fix an issue when we have more than one player as the handoff of the locks between players is doing something odd.  Once that is fixed I think I'm ready to start the multiball stuff.  I spent some time looking through your pinbot code to better understand a few things, but the way you have things set up with InLock, MultiBalls etc is nice so I think this will be easier that I was expecting.  When I get multiball working I'll take another video.

thanks so far

[Black Knight]

vor 1 Stunde schrieb Snux:

thanks so far

You're welcome and thanks for your valuable feedback - you're actually the first one giving me some on the API.

[Snux]

Lock handling working.  Multiball starts and finishes.  Big smile today . 

Got the lock handler logic working, also the handoff between players.  The F14 locks are really tricky because when you plunge the ball from the shooter lane, it has to go via one of the locks, which might already contain a ball.  Keeping track of the status of different locks was quite hard but it's working now.  Which means I was able to add in the multiball start with about 5 more lines of code.

The multiball starts (kicks out all 4 balls to the playfield) and finishes when only 1 ball left on the playfield.  That was really easy thanks to the BaseGame code.  With the original pyprocgame and also MPF I never got multiball working with these complex locks.  I much prefer having the lower level of control in C, I used it first in University back in 1986 and still feel comfortable with it, even though I didn't program as a job for many years.

Now I "just" need to put in the extra stuff for the multiball objective, then start adding the pretty stuff (display, sounds).  Still aiming to recreate the original F14 code, including most of the settings.  Then we can start to make it into Second Sortie.

[Snux]

As usual, as I'm working through some of this, I think of some other "nice to have" things in the API.  Not sure what you think, here they are the latest few..

- maybe TurnOnLamp and TurnOffLamp should automatically RemoveBlinkLamp if there is one?

- if you call AddBlinkLamp with a period which is the same as another lamp, they will blink together.  Most of the time that's good and what you want, but sometimes it would be nice to have a blink with the same period but not in sync.  For example the TOMCAT target lamps blink with the same period in the original game, but they are not in sync, they kind of strobe.  Maybe add a command to the API 'AddBlinkLampImmediate' or something which does not look for another lamp with the same period?

[Black Knight]

vor einer Stunde schrieb Snux:

I much prefer having the lower level of control in C

Same for me. I learned C 1988 on my Amiga. At the time I liked Assembler more, but if you wanted to use functions of the Amiga operating system you had to do it in C. 
Then no C for 25 years, not in Universtity nor in my job. There I do a bit of Verilog-A every now and then, but that's it. So my humble C knowlegde was in hibernation until the Arduinos came up. 
So in the end this is all done by a SW hobbyist and I think it looks like it. I'd do a lot of things differently today, may be even give C++ a try, but it works and that's what counts. May be some day a SW professional pops up and starts cleaning evertything up and that would be OK for me.

vor einer Stunde schrieb Snux:

maybe TurnOnLamp and TurnOffLamp should automatically RemoveBlinkLamp if there is one?

I didn't do that because when a lot of blinking lamps are used the arrays RemoveBlinkLamp has to browse to look for a specific lamp could become quite long. Hence, I was trying to avoid the additional workload and RemoveBlinkLamp doesn't mind if you call it with a non blinking lamp, so if you're in doubt if a certain lamp is blinking or not just add RemoveBlinkLamp before TurnOffLamp.

vor einer Stunde schrieb Snux:

Maybe add a command to the API 'AddBlinkLampImmediate' or something which does not look for another lamp with the same period?

I wonder if this might become to specific. The idea of the API in APC.ino was just to provide some basic commands and leave everything to the user. I admit that I didn't always followed this principle by myself e.g. with the scrolling routines, but doing direct display manipulation is quite complicated, so I added then to APC.ino and not to my game codes.

However, if you have a comcept which is more flexibel and still easy to use then just shoot.

BTW: I spent some time with my F-14 yesterday, to. Alas, I was not having fun, but only ripping everything apart, but now I can start working on the playfield.

 

[Snux]

I was an assembler fan too, first for Z80 on my 1K Sinclair ZX81, then 6502 on my "Oric Atmos"

Question - I'd like to enhance the values in NumLower in APC.ino to include some other "characters" that I can use for effects.  Like [ ] - and so on.  Can you let me know how to calculate the values that should replace the current 0 in the list?

15 hours ago, Black Knight said:

Alas, I was not having fun, but only ripping everything apart, but now I can start working on the playfield.

I have something you could have to make some more fun on your F14, if you're interested.  Some time ago I had an idea for the divertor ramp and contacted the guy in the US that was making replacements.  He made me a one-off clear ramp.  The metalwork is fitted, but no lamp holes have been drilled.  I was going to light the area under the ramp with LEDs and fix some LEDs on the ramp to do the normal red/blue thing.  But in the end I decided I wasn't going to use it so it's been in my "box of stuff" for ages.  Would you like it for your F14?  Just cover the shipping from UK to Germany....

[Volley]

Is someone of you able to read and interprete the code of the old game eproms and make a change? If so, send me a Note!

Sorry for write this in this thread.

[Snux]

1 hour ago, Volley said:

Is someone of you able to read and interprete the code of the old game eproms and make a change?

I can't do it, not something I ever tried to do.  There was once a website called pinhacks.com where people used to discuss tools and methods for altering ROMs, but the site is no longer available.  You can find it on the archive like here

https://web.archive.org/web/20130720210127/http://pinhacks.com/

No idea who, if anyone, is still doing this stuff.

[Black Knight]

vor 6 Stunden schrieb Snux:

Can you let me know how to calculate the values that should replace the current 0 in the list?

You can use the DisplayNumLower tool for that.

vor 6 Stunden schrieb Snux:

Would you like it for your F14? 

Of course I'd like to have it, but only if you're sure that you don't want to use it by yourself - it's only a small SW update to enable the LED_Exp board to support 192 LEDs.

However, I might also have something for you. A friend of mine and myself did some LED display boards 20 years ago and I still have some unpopulated boards left. 
At the time only bright red LEDs were available on the free market, so we had to use those for our design. For a few games this just doesn't fit, but F-14 is one of the games where these really fit a lot better than the old ones. 
The old picture on the web page is a bit outdated as the actual version doesn't use these big through hole transistors any more, but the IRF7316 ICs I also used on the APC board. The component list seems to be up to date though.

Think about it, of course I'd also just charge the shipping.

vor 3 Stunden schrieb Volley:

Is someone of you able to read and interprete the code of the old game eproms and make a change?

DE: Ich habe da auch keine Ahnung von. Was möchtest du denn machen? Mit PinMameExceptions ist ja schon ziemlich viel möglich ohne die SW neu schreiben zu müssen. 
EN: I also don't have an idea about this. What are you trying to do? With PinMameExceptions you're able to do a lot of things without having to rewrite the SW from scratch.

Bearbeitet 22. Februar 2022 von Black Knight

[Snux]

Pointers, arrays, display text, my head hurts a bit

So I want to define a routine that will take some text and blink it on the top line.  I've written this..

void F14_BlinkMessage(byte Loops) {
  static byte blink_message_timer = 0;
  
  SwitchDisplay(0); // switch to buffer 2

  switch (Loops) {
    case 0:  // when the counter hits zero we are done
      SwitchDisplay(1);  // switch back to first buffer
      blink_message_timer = 0;
      break;
    default:
      if (Loops & 1 == 0) {  // even number, write the message
        WriteUpper2(BlinkUpper);
        blink_message_timer = ActivateTimer(600,Loops-1,F14_BlinkMessage);
      }
      else {  // odd number, blank it
        WriteUpper2("                ");
        blink_message_timer = ActivateTimer(300,Loops-1,F14_BlinkMessage);
      }
      
  }

}

The idea is that you set a global var BlinkUpper to the message you want to flash (BlinkMessage="TOMCAT TOMCAT", then call F14_BlinkMessage with parameter of the number of off/on loops.  My total confusion comes with how to declare BlinkUpper.  I tried char[16] but that's not good, I tried char * but then it doesn't do anything.  It's been a long time since I was manipulating pointers and strings in C......  What do I need to declare as?

[Snux]

Please ignore that.  My test for an odd/even number is rubbish.  It's working now

[Snux]

On 2/22/2022 at 5:04 PM, Black Knight said:

However, I might also have something for you.

So my F14 already has an LED display board in, but just a normal orange one.  Putting in a board with bright red ones might be interesting, so I'd like one of your blank PCBs if possible.  We can exchange addresses via PM, I'll pay to send the ramp and you can pay to send the PCB, keeps it simple I guess.

I'm making more good progress with F14, still working on replicating the original code...

- Launch bonus is working with animation (left inlane to vuk)

- Hot streak is working

- Animations for lock lit, locking ball, locked ball are done.

- Beacons now light when multiball is ready

I'll take another video in the next day or so.  Next things to work on are

- The actual multiball game - relock balls for landing and fighter jackpot.  At the moment it just plays the normal game, but with 4 balls.  Although it switches the beacons off when you've only got one ball left, so it's a start

- Steal your Pinbot code for the end of ball bonus countdown and modify for F14.

- Add missing flasher effects, and start to put the sounds in place.  I found *another* sound in Pinmame that I'd missed.

- Extra ball award

I did make a couple of adjustments to APC.ino.  One was actually a bug fix for the < character in the upper alpha display. 

https://github.com/Snux/APC/commit/933a245423e2eb0d73e3fea85deeca5a19ac9690

The other was to fill a couple of unused positions in the lower numeric with something I needed for an animation, but I might need another one or two also.

Bearbeitet 24. Februar 2022 von Snux

[Black Knight]

vor 17 Stunden schrieb Snux:

One was actually a bug fix for the < character in the upper alpha display. 

I'm going to add those changes.

vor 17 Stunden schrieb Snux:

so I'd like one of your blank PCBs if possible

It's yours, but you might still change your mind because:
One measure to get my F-14 into use was to get it's display cables out of my Black Knight where they were used to control my alphanumeric Sys7 display. I therefore did a respin of the driver board to also feature the egde connectors that are used by System 7 displays. 
That means I don't need the previously used board any more (it's the lower board in the picture at the 4 Alpha + Credit page) and I could also send this to you instead of the normal F-14 one. The advantage for you would be to have alphanumeric displays in the upper and the lower row, as well as to have a credit which you might or might not want to use. And the board is already populated and tested. 
The drawback would be that I can add a board for the credit displays, but I don't have any spares of the alphanumeric ones which means you'd have to order them by yourself. Of course these board won't fit into the original display mounting, but this shouldn't be a big deal.  
As before I'd just charge the shipping for the driver board and the credit.

Independent of which board you choose there's one thing you should know also. The LED displays we used are a bit too wide to fit and need to be grinded a bit (roughly 1mm). I use a bench grinder for that, but a belt grinder works also.

 

Bearbeitet 25. Februar 2022 von Black Knight

[Snux]

On 2/25/2022 at 12:14 PM, Black Knight said:

you might still change your mind

I think I'll stick with the original idea, I don't have any plans to adjust my speaker panel, but thanks for the offer.

I'm probably at around 90% of the original Tomcat logic done now.  One fix for the documentation - for BlinkScore it states you have to issue KillTimer(BlinkScoreTimer) to kill it, but actually all you need to do is issue BlinkScore(0)

There is something I need to look into (and maybe it'll be a fix for Base Game too) and the video I've taken does actually catch it happening (at 2:17).  Sometimes the ball comes so fast at the bottom that it misses the outhole switch completely and runs up into the trough.  If that happens, the game doesn't realise what happened.    You have to poke the outhole switch to make it realise that the ball has ended.

Anyway, the video.  Not very well made, but it shows the following :

• Tomcat targets being made to light a lock
• Lock handling
• Rescue kickback
• Animations for the upkicker when going to lock a ball
• Launch bonus
• Bonus handling / countdown at ball end (I've missed to reset the bonus between balls)
• Multiball, including a safe landing.
• Yagov shot making kills

You can ignore the ball error at the end, the trough kicker actually managed to get the ball out of the machine and on to the floor and I didn't notice :).  Maybe I need to reduce the power on that a little!

I still need to add a few things like

• Handling the extra ball award when you score all 7 Yagov kills
• Adding more flasher effects
• Add more lamp effects.  Including a better attract display (sorry!)
• Adding sounds
• Put the ball number on to the display, in the player 4 spot (unless player 4 is active, in which case in the player 3 spot)
• Restructure some of the logic, I learned better ways to do some things as I was moving forward.

I did once have a nasty bug, but I haven't been able to recreate it.  I had a flasher sequence (using PlayFlashSequence) but for some reason it didn't activate the A/C solenoid so instead of a flasher sequence I had a solenoid sequence which was a little noisy!  If it happens again I'll try and work out

 

Bearbeitet 27. Februar 2022 von Snux

[Snux]

So I added a small routine to sort out the balls landing in the trough without activating the outhole switch.  In the main game switch handler, I have all 4 trough switches calling this routine with a parm of 0.  I've done a little testing and it seems OK so far.

// Called if a trough switch activates during game play.  This can happen if 
// a ball skips the outhole switch and jumps right to the trough.
void F14_BallSkippedOutholeCheck(byte Event) {
  
  static byte trough_settle_timer=0;
  
  switch (Event) {
    case 0:  // If the timer is already running, do nothing, otherwise start the timer.
      if (!trough_settle_timer) {
         trough_settle_timer = ActivateTimer(1000, 1, F14_BallSkippedOutholeCheck);
      }
      break;
    case 1:  // timer has allowed the trough to settle, so work out if we have more balls than expected
      trough_settle_timer = 0;
      if ( ((F14_CountBallsInTrunk() + InLock + Multiballs) > 4) && !BlockOuthole ) {
        BlockOuthole = true;
        F14_BallEnd(0);  // if we do have more than expected, should be safe to end ball
      }
  }

}

 

Bearbeitet 28. Februar 2022 von Snux

[Snux]

Putting the ball number on the display was easy.  I still need to sort this out if there is a 4 player game (it then alternates between the score and the ball number for the current player).  But this is fine for now.

[Black Knight]

Just watched your video. 
I'm deeply impressed how fast you implemented all this stuff. Even the display and light animations look great.

I have to admit that I somehow lost my momentum when it came to to the last 10% of my Pinbot. It's a horrible lot of animations (these damned chest lights drive me crazy) and I'm not the most persistent guy when it comes to details. I'm better in specifying things and let others care about the odds and ends.
That means if you continue with this speed then your F-14 will be ready before my Pinbot is done.

Am 27.2.2022 um 14:47 schrieb Snux:

If it happens again I'll try and work out

Did you accidentally use ActivateSolenoid for the A/C relay or the solenoids 1 - 8 ? ActivateSolenoid doesn't care about the A/C relay, but just drives the solenoid. Hence it can inflict total chaos when interfering with the ActASolenoid sytem.

BTW, I'm trying to find out what the price is for shipping the display board to the UK and then send you a PM.

[Snux]

15 hours ago, Black Knight said:

It's a horrible lot of animations

Yeah, with the exception of the launch bonus animation I haven't done any playfield insert lamp animations yet.  Coding those manually is very time consuming.  MPF has a tool for generating lamp shows, you load in a picture of the playfield and mark the positions of all the lamps, then can move shapes over it to make the shows.  I've used this before but the output it generates is in completely the wrong format for APC.  Here is an example that I did for F14 some time ago.

https://github.com/Snux/F14-MPF/blob/master/modes/attract/shows/done.yaml

Basically at each timestep it has the lamp delta.  I'm thinking that maybe with some fairly ugly Excel work I can take one of those lampshows and generate a function for pasting into my APC code that will basically use a timer to step through each delta.  So this piece from the MPF lampshow

- time: '+1'
  lights:
      l_bonus2X: 'FFFFFF'
      l_kill: 'FFFFFF'
      l_kill2: 'FFFFFF'
      l_kill4: '000000'
      l_light_release: '000000'
      l_release: 'FFFFFF'
- time: '+1'
  lights:
      l_bonus3X: 'FFFFFF'
      l_kill: '000000'
      l_kill1: 'FFFFFF'
      l_kill2: 'FFFFFF'
      l_kill3: '000000'

would generate something like this which you would run by calling with a step of 0.

void F14_LampShow1(byte Step) {
static byte show_timer=0;

switch(Step) {
case 0:
	TurnOnLamp(1); TurnOnLamp(2); TurnOnLamp(3); TurnOffLamp(4);
	break;
case 1:
	TurnOffLamp(1); TurnOffLamp(2);
	break;
...
...
case 50:
...

}
if (Step < 50) {
  show_timer=ActivateTimer(100, Step+1, F14_LampShow1);
}
else {
  show_timer = 0;
}
  
}

I know this wouldn't be as efficient as the lamppattern logic in APC at the moment, where it looks like you're basically loading the pattern straight into the lamp matrix buffer, but I think it should work OK.  Actually, just building show code like this manually without attempting to convert anything from MPF might actually be easier.  It'll also mean that I can include the LEDs.  I'll think about it some more. 

Bearbeitet 1. März 2022 von Snux

[Snux]

Oooh....

The source for the MPF show creator is on Github.  It's written in something called BlitzMax which I never heard of, but I managed to download it and get the creator compiled.  The code that actually outputs the MPF show file is a very small part of the program, maybe 20-30 lines.  It should be really simple to change it to output code that can be pasted into APC as a function.  I'll play with that later and see how it goes..

[Black Knight]

vor 3 Stunden schrieb Snux:

I know this wouldn't be as efficient as the lamppattern logic in APC at the moment

That's true, but the LampPattern logic is only working for all playfield lamps and I think it might be a good idea to have an additional system to handle not all but only certain lamps (like the Pinbot chest). This could then work with on/off lists like MPF is doing it. For normal lamps such a list entry could look like:

(byte Time to next step), (bool TurnOn or TurnOff), (zero terminated list of bytes with the numbers of the affected lamps)

I'm currently implementing something similar for LEDs. I have to explain it better in the DOCs, but the idea of this mode 2 is that you just change certain LEDs to the specified color and leave the rest untouched. 
In this case the usual data pattern with each bit representing an LED is sent. Normally a 1 means the lamp is turned on to the selected color (mode 0) or it keeps it's color (Mode 1), but a zero means it is turned off. This is not true in Mode 2 where a 1 means the LEDs are getting the new color immediately (no fading), but a zero means the LED doesn't change it's state. So in this mode just the delta is send to the LED_Exp board. 
It might make sense to implement another mode for switching off the selected LEDs and leaving the rest untouched.

[Snux]

Adjusting the MPF lamp show creator went much better and quicker than I was expecting.  Fortunately I still have the input file from when I was using MPF before - the show creator takes the "monitor.yaml" file which contains things like the x and y coordinates of each lamp.  So I picked a couple of shows I'd made before and ran them through the modified show creator tool. 

 

 

As an example, for the first show it created the following which you can just paste into the program and then adjust as you need to.  A short video containing both this "rotating wheel" and a "bounce up and down" is here.

Now I just need to look into the best way to block all other lamp calls while the show is running.  Maybe I make my own versions of TurnOn/TurnOff/Blink etc which check some variable that will be set if a show is running and then only call the APC.ino routines if no show running.

void LampShowXX (byte Step) {
static byte step_timer=0;
 
switch (Step) {
case 0:
  TurnOnLamp(3);
  TurnOnLamp(109);
  TurnOnLamp(105);
  TurnOffLamp(2);
  break;
case 1:
  TurnOnLamp(104);
  TurnOffLamp(105);
  TurnOnLamp(5);
  TurnOffLamp(2);
  TurnOffLamp(111);
  TurnOnLamp(54);
  break;
case 2:
  TurnOnLamp(25);
  TurnOffLamp(109);
  TurnOffLamp(103);
  TurnOffLamp(105);
  TurnOffLamp(2);
  TurnOnLamp(111);
  break;
case 3:
  TurnOnLamp(26);
  TurnOffLamp(109);
  TurnOnLamp(102);
  TurnOnLamp(103);
  TurnOffLamp(104);
  break;
case 4:
  TurnOffLamp(25);
  TurnOffLamp(27);
  TurnOffLamp(102);
  TurnOffLamp(103);
  TurnOffLamp(5);
  TurnOnLamp(53);
  break;
case 5:
  TurnOffLamp(26);
  TurnOnLamp(27);
  TurnOffLamp(102);
  TurnOffLamp(5);
  TurnOffLamp(59);
  TurnOffLamp(111);
  TurnOffLamp(114);
  TurnOffLamp(54);
  break;
case 6:
  TurnOnLamp(28);
  TurnOnLamp(59);
  TurnOffLamp(111);
  TurnOnLamp(114);
  TurnOffLamp(54);
  break;
case 7:
  TurnOffLamp(27);
  TurnOffLamp(3);
  TurnOnLamp(62);
  TurnOffLamp(52);
  break;
case 8:
  TurnOffLamp(29);
  TurnOffLamp(3);
  TurnOffLamp(59);
  TurnOffLamp(48);
  TurnOffLamp(115);
  TurnOnLamp(52);
  break;
case 9:
  TurnOffLamp(28);
  TurnOnLamp(29);
  TurnOffLamp(3);
  TurnOnLamp(39);
  TurnOnLamp(8);
  TurnOffLamp(62);
  TurnOffLamp(59);
  TurnOnLamp(48);
  TurnOffLamp(33);
  TurnOnLamp(115);
  TurnOffLamp(53);
  break;
case 10:
  TurnOffLamp(8);
  TurnOffLamp(62);
  TurnOnLamp(33);
  TurnOffLamp(114);
  TurnOffLamp(53);
  break;
case 11:
  TurnOffLamp(29);
  TurnOffLamp(30);
  TurnOffLamp(39);
  TurnOnLamp(34);
  TurnOffLamp(116);
  break;
case 12:
  TurnOffLamp(29);
  TurnOnLamp(30);
  TurnOffLamp(32);
  TurnOnLamp(57);
  TurnOffLamp(48);
  TurnOffLamp(33);
  TurnOnLamp(116);
  TurnOffLamp(112);
  TurnOffLamp(52);
  break;
case 13:
  TurnOffLamp(23);
  TurnOnLamp(32);
  TurnOnLamp(60);
  TurnOffLamp(35);
  TurnOffLamp(115);
  TurnOnLamp(112);
  TurnOffLamp(52);
  break;
case 14:
  TurnOnLamp(23);
  TurnOffLamp(30);
  TurnOffLamp(31);
  TurnOffLamp(57);
  TurnOnLamp(35);
  TurnOffLamp(34);
  TurnOnLamp(56);
  TurnOffLamp(115);
  break;
case 15:
  TurnOffLamp(30);
  TurnOnLamp(31);
  TurnOffLamp(60);
  TurnOffLamp(57);
  break;
case 16:
  TurnOffLamp(32);
  TurnOffLamp(60);
  TurnOnLamp(58);
  TurnOffLamp(35);
  TurnOnLamp(38);
  break;
case 17:
  TurnOffLamp(22);
  TurnOffLamp(23);
  TurnOnLamp(55);
  TurnOnLamp(61);
  TurnOffLamp(56);
  TurnOffLamp(116);
  TurnOffLamp(110);
  TurnOnLamp(49);
  break;
case 18:
  TurnOnLamp(22);
  TurnOffLamp(23);
  TurnOffLamp(31);
  TurnOffLamp(58);
  TurnOffLamp(37);
  TurnOffLamp(56);
  TurnOffLamp(116);
  TurnOnLamp(110);
  break;
case 19:
  TurnOffLamp(31);
  TurnOffLamp(61);
  TurnOnLamp(37);
  TurnOffLamp(38);
  TurnOffLamp(112);
  break;
case 20:
  TurnOffLamp(21);
  TurnOnLamp(64);
  TurnOnLamp(36);
  TurnOffLamp(112);
  break;
case 21:
  TurnOnLamp(21);
  TurnOffLamp(22);
  TurnOffLamp(55);
  TurnOffLamp(1);
  TurnOffLamp(37);
  TurnOffLamp(113);
  TurnOnLamp(50);
  break;
case 22:
  TurnOffLamp(55);
  TurnOnLamp(1);
  TurnOffLamp(36);
  TurnOnLamp(113);
  TurnOffLamp(49);
  break;
case 23:
  TurnOffLamp(20);
  TurnOffLamp(36);
  TurnOffLamp(110);
  TurnOffLamp(49);
  break;
case 24:
  TurnOffLamp(21);
  TurnOnLamp(20);
  TurnOffLamp(64);
  TurnOffLamp(110);
  TurnOnLamp(51);
  break;
case 25:
  TurnOffLamp(19);
  TurnOffLamp(63);
  TurnOffLamp(50);
  break;
case 26:
  TurnOnLamp(19);
  TurnOffLamp(20);
  TurnOnLamp(63);
  TurnOffLamp(113);
  TurnOffLamp(50);
  break;
case 27:
  TurnOffLamp(18);
  TurnOffLamp(108);
  TurnOnLamp(40);
  TurnOnLamp(2);
  TurnOnLamp(7);
  TurnOffLamp(113);
  break;
case 28:
  TurnOnLamp(18);
  TurnOffLamp(19);
  TurnOnLamp(107);
  TurnOnLamp(108);
  TurnOffLamp(1);
  TurnOffLamp(51);
  break;
case 29:
  TurnOnLamp(17);
  TurnOffLamp(18);
  TurnOffLamp(109);
  TurnOffLamp(106);
  TurnOffLamp(108);
  TurnOffLamp(1);
  TurnOffLamp(63);
  TurnOffLamp(51);
  break;
case 30:
  TurnOffLamp(18);
  TurnOnLamp(109);
  TurnOnLamp(106);
  TurnOffLamp(107);
  TurnOffLamp(1);
  TurnOffLamp(63);
  break;
  }
  if (Step > 30) {
    if (step_timer) {
      KillTimer(step_timer);
    }
    step_timer = 0;
  }
  else {
    step_timer = ActivateTimer(<steptime>, Step + 1, LampShowXX);
  }
}