Scopetris

This is an unedited republication of the Scopetris project description as it appeared on the first Lars' Electric Endeavors website, including downloads of source code and materials. Enjoy!

Lars, January 2018

This article is about a Tetris game I created with an AtMega32 controlling the beam of an oscilloscope, which I very creatively named Scopetris.

Video of me playing a rather unimpressing game of Scopetris. Music: DRAX - Star Flake

The Telequipment D61 oscilloscope running Scopetris

The hardware story

The project started with some R-2R ladder circuits I created while playing around with inline resistor networks.

With an R-2R ladder, a value expressed in digital bits can be converted to a corresponding analog voltage. The circuit makes the most significant bit affect the voltage with Vcc/2, the next bit with Vcc/4, the next Vcc/8 and so on. For instance, the R-2R ladder configuration for a 4-bit converter is as follows:

Using the inline resistor networks and SMD resistors on stripboards, I created two R-2R ladders for 8-bit D/A conversion, that could snap right into a breadboard and connect to the microcontroller.

The inline resistor networks forms the R resistors of the ladder with the value 5.6 K, which means that the 2R resistors has to be 11.2 K. First attempt was to use 12 K SMD resistors, in the belief that a 7% error might not mean that much. But I was mistaken, the accuracy was very unsatisfactory and the staircase signal generated by cycling through the values from 0 to 255 had very uneven steps with some of them even going downwards.

The solution was to solder 150 K SMD resistors in parallel with the 12 K ones, to get 11.11 K. This fixed the accuracy problem and the staircase signal was perfect.

Vector fun

The two resistor ladders, interfacing ports on the AtMega32, were connected to an oscilloscope in X/Y mode. The position of the beam was thus controllable by simply assigning values to registers in the microcontroller. Now, what to do with that setup... Draw stuff on the screen of course!

Unfortunately the intensity of the beam was not controllable, as it is on true vector screens. But due to the nature of good old green phosphor, the thinkness of the line could be controlled by how fast the beam moves.

The beam movement was not perfect, however. When it had to jump large distances, under and overshoot problems appeared and some lowpass filtering artifacts were also appearent. In an attempt to improve the situation, I put some opamp buffers on the R-2R ladder output. It removed some of the lowpass filtering artifacts, but the over/under shooting problems were still as bad. I suspect that stray capacitances in the R-2R ladder stripboard is the explanation.

My Scopetris hardware so far

Tetris - with chain reactions

Now that I had a system able to draw stuff on the oscilloscope screen, I decided to implement a Tetris game to raise the bar a bit over the usual pong-like games seen on oscilloscopes. I thought long and hard about how to best draw the playfield. Was it feasible to draw a square or a symbol for each occupied cube? I came to the conclusion that the only really nice way to do it, was to draw the individual bricks in the playfield by tracing their outline.

This requirement lead to a Tetris implementation with management of each active brick and how it was moving and being split. While it increased the complexity of the implementation, it was all worth it, because it allowed to implement the true gravity / chain reaction rules quite naturally.

The chain reaction rules are an intuitive extension to the traditional Tetris rules. Whenever it is possible for a brick to fall down, it does so, leading to the possibility of further completed lines to remove. This is in contrast to traditional Tetris where bricks may stay in midair. I got familar with the chain reaction rules by playing the excellent Quadra game some time ago.

The graphics implementation tries to draw all objects in the game with 100 Hz, to ensure a smooth, flicker free appearence. After drawing the objects, the beam rests in the top left corner of the playfield. When the number of bricks in the playground increases, the drawing routine will take longer, and it may happen that the framerate drops a bit below 100 Hz if the playground is completely stuffed with bricks.

Control

To control the game I wired a D-Sub 9 pin connector to the microcontroller, such that I could use a standard Atari/C64/Amiga joystick.

Scoring

The game is just Tetris marathon with a gradually increasing speed, and the score is simply the number of lines removed. The speed, however, is not related to number of lines removed, but to the number of line removing rounds - each time dropping a brick causes lines to be removed. So, to get a high score, one must zap a great number of lines each time, and of course be able to control a high speed.

Highscore challenge

My current rather unimpressive highscore is 134, after 58 line removing rounds:

I challenge everyone to construct the Scopetris hardware and beat the highscore! Do the R-2R ladder or whatever kind of D/A conversion you see fit, just make sure the game loop runs at 100 Hz. The next page has links to download the source. If you email photos of your hardware and oscilloscope running Scopetris, I will post it here with a link if you like.

So, why don't you put your old beloved phosphor oscilloscope to good use and beat the highscore!

Scopetris source version 0.1

The hex:

• scopetris.hex

The source, to compile with AVR-GCC:

• scopetris.c
• drawlib.c
• drawlib.h
• vectorfont.c
• vectorfont.h
• tetrislib.c
• tetrislib.h
• makefile

or get it all in a zip:

• scopetris_v0.1.zip

Hardware requiremens

The hex file is compiled for AtMega32 at 8 Mhz with the following connections:

Inputs:
   PA0  Joy up
   PA1  Joy down
   PA2  Joy left
   PA3  Joy right
   PA4  Joy fire
   PA5  Gravity on/off   <=>  real/naive

Outputs:
   PORTD  Vector X position (8-bit)
   PORTC  Vector Y position (8-bit)

The joystick signals are active low. The gravity switch toggles between traditional Tetris and chain reaction rules.

By Lars Ole Pontoppidan

Aug. 2007