Shenzhen I/O – Drinking Game Scorekeeper

Joe have been out drinking again. This time with Baron Von Schnapps. I don’t say this was a serious game. However, it resulted in yet another deal for us. So good job Joe on landing electronics, bad job for your liver. However, they want to promote their drink with a small game. And we are to make a drinking Game Scorekeeper to help them with that.

He might not remember the exact rules, but we are given two inputs called point and foul. As well as a display with a non-blocking xbus input. And if they trigger point, we should increment the display with one. If we get a foul we should subtract 2. However, we should never show less than zero on the display.

The verification tests specifically for the latter part in the start of the test as shown here.

Shenzhen I/O - Drinking Game Scorekeeper - Verification

The design of the drinking game scorekeeper

From an input/output point of view we should be able to do this with a single MC4000 wired up like this

The only question is whether we can fit the code in there. But let us try.

The code should flow something like this

  1. If point high increment acc
  2. if foul high decrement acc by 2
  3. if acc less than 0 reset it
  4. move acc to x1

That we can code into

  tgt p1 0
+ add 1
  tgt p0 0
+ sub 2
+ tlt acc 0
+ mov 0 acc
  mov acc x1
  slp 1

This fits nicely into the MC4000 unit. The clever thing I have done here is that I only test if acc is negative if I have subtracted something. That saves a little bit of energy.

This solutions finishes with

Cost: 3
Energy: 268
Lines of code: 8

A little on conditionals

I might also just add a few notes to the use of conditionals in this assembly language.

If I had written the code

  tgt p0 0
+ sub 2
  tlt acc 0
+ mov 0 acc

It would test whether acc is negative in all instances. And that resets the conditional. It would also be valid, but it would use additional energy to execute the unnecessary code.

If I had written

  tgt p0 0
+ sub 2
+ tgt acc 0
- mov 0 acc

As I would have a tendency to, it would not work. Because the acc reset in the last line would be triggered whenever the first conditional was false. So it is not like a nested loop. It just checks if one of the conditional statements are false, and then triggers the negative case.

Posted by Kristian

1 comment


With a bit more optimisation

tcp p0 p1
– add 1
+ sub 2
+ tlt acc 0
+ not
+ mov acc x1
– mov acc x1
slp 1

Leave a Reply