#YGREC-РЭС15-bis has 16 bits wide registers that make it suitable for quite a few things, including running Tetris and Game of Life. However, the #YGREC8 is only 8 bits wide and this limits the range of programs even more. I'll focus only on "toy games" because they are the most attractive applications, while I also consider other uses such as PLC or monitoring.

Tetris is still somewhat possible but it would be an impractical stretch because the 10 columns exceed the 8 bits of the registers, and the processor is too slow to animate that smoothly : the display would be sheared.

Tic-tac-toe is a contender.

Battleship is another good candidate : it's not a hard real-time game and animations are not critical. However I would have to build 2 units and make them communicate somehow... So it would be good to develop communication protocols, later.

Another good challenge is the SNAKE game. It doesn't require too much computing power and could run fast enough to be enjoyable. The problem is to memorise a linked list of coordinates, which could exceed the DRAM capacity... But there is a not-too-hard solution :-)

It requires 4 bitplanes :

• one bitplane is a boolean that says "food"
• one bitplane is a boolean that says "snake" (can be mapped to the flip dots display)
• one bitplane says "up/down"
• one bitplane says "left/right"

so overall, there are 4 bits per pixel. With a 16×16 pixels array, that's 128 byte of DRAM, or half the addressing space of one address register.

• Food is pretty simple : it's set by a random generator from time to time in places where there is no "snake" bit set.
• Snake is used as a collision condition, it's set by the "head" code and cleared by the "tail" code.
• The "head code" has a coordinate and a direction : the direction is changed by the button inputs.
  - At each game step, the buttons are scanned, the direction updated, the direction increments/decrements the coordinate and the "snake" bit is set at the new coordinate.
  - If a "food" bit is also present, the food is swallowed (cleared) and a new food is created pseudo-randomly. The tail code is skipped for one cycle, so the snake gets longer.
  - if a wall is touched or the snake bit is already set, game over.
• The trick is with the tail code :-) Each "head" leaves a sort of "trail" on the "left/right" and "up/down" bitplanes so the tail can follow it, without requiring the storage of a long list of coordinates. It uses quite a lot of room but much less than fully-decoded coordinates. So the "tail code" remembers the coordinates of the tail but instead of reading the buttons, it reads the "trail" left by the head to follow the body.

It shouldn't be too hard, right ?...

I have a 16×24 flip dots array that leaves 16×8 pixels to display the stats of the game.