Shenzhen I/O – Laser Tag Equipment

I did not know that our company made weapons. But I guess as long as it is laser tag equipment it should be okay. This is in my opinion the hardest problem so far. We are asked to make a computer to control the equipment for a game of laser tag. And there are quite a few rules we need to take into consideration.

The I/O of the computer is the following

Hit – input that goes is high if we are hit

Alive – output that will be high as long as we are alive. It should go to zero when we are hit

Respawn – resets the alive status

Trigger – simple input that goes high if the player pulls the trigger

Reload – Goes high when the player reloads the gun. This is coupled with a counter on the board that shows how many rounds a full magazine can hold

Fire –  An output that goes high if the gun should fire. This should only go high if the player is alive, pulls the trigger and have ammo left.

So as you can see there are quite a few things to take into consideration. All in all this gives us the following list of verification signals

Shenzhen io - Laser tag equipment - signals

Solution 1 for laser tag equipment

I have created two solutions for the laser tag equipment puzzle. The first one is mostly programming, the second one I thought I could use some logic gates. However, that turned out not to be necessary, but I still improve the design significantly.

The first solution looks like this

Shenzhen io - Laser tag equipment - solution 1

The MC6000 to the has two responsibilities.

  1. keep track of our alive status
  2. Filter any triggers to only trigger if we are alive

The code goes

  mov x1 dat
  tgt dat 0
+ mov 0 acc
+ tgt dat 9
+ mov 100 acc

  mov acc p0

  tgt p1 1
+ tgt acc 1
+ mov 100 x2
- mov 0 x2
  slp 1

Line 1-5 checks to see if we are hit or respawning and then keeps track of the alive status in the acc. On line 7 moves the alive status to the output. And lastly, line 9 to 13 checks if the player pulls the trigger, then checks if he is a live. And then sends 100 to x2 if we can shoot, otherwise 0.

The MC4000 is responsible for counting the bullets and pull the trigger.

The code in that goes like

  tgt p1 1
+ mov x1 acc
  tgt x0 0
+ tgt acc 0
+ sub 1
+ mov 100 p0
- mov 0 p0
  slp 1

The first line checks if we should reload, and if we should resets the acc to the ammo counter. Third line checks if the player triggers (and is alive). Then checks if there are bullets left. In that case use a bullet and move 100 to the fire output. Otherwise let it stay at 0.

I found this to be a logical way to implement it, but it is expensive. The solution runs in

Cost: 11
Energy: 672
Lines of code: 19

Based on that I got a feeling that some of this you could do by logic gates. So I gave it a try

Laser Tag Equipment adding and removing some logic gates

To start out with the solution which is a little less tidy

Shenzhen io - Laser tag equipment - solution 2

I started out with the thought that we could mostly decouple the alive and the trigger part of the game, and then check with an and-gate to see if both were high before we fire. But then I realized I didn’t need the logic gate because I needed the alive status to keep track of the bullets in the code. So I ended up with this design which is still a lot more efficient than the first. The first MC4000 keeps track of the alive status and broadcasts it on p0. The code is written as

  tcp x0 1
+ mov 100 p0
+ jmp slp
- jmp slp
  mov 0 p0
slp: slp 1

I use the tcp command in order to respawn the player if x0 is higher than 1 or do nothing if x0 is less than 1.

The real logic here lies in the rightmost MC4000, where the code looks like

  tcp x0 1
+ mov x1 acc
+ jmp slp
- jmp slp
  tgt acc 0
+ tgt p1 0
+ sub 1
+ gen p0 1 0
slp: slp 1

First we check if x1 is 0, 1 or 10. If x1 is 10 then we reset the ammo counter. x1 equals 0 means we should sleep. Otherwise it is 1 then we check if we have bullets left and are alive. If that is the case, spend a bullet and trigger the fire output.

This solves the problem in

Cost: 8
Energy: 422
Lines of code: 15

So we have improved about every parameter by 30%. That is pretty good I think.

Posted by Kristian

Leave a Reply