This article is about a Tetris game I created with an AtMega32 controlling the beam of an oscilloscope, which I very creatively named Scopetris.
The Telequipment D61 oscilloscope running Scopetris. (High resolution)
The hardware story
The project started with some R-2R ladder circuits I created while playing around with inline resistor networks. (Two Resistor Ladder configurations are known, a string resistor ladder and a R-2R ladder. A R-2R Ladder is the most simple and inexpensive way to perform digital-to-analog conversion, using repetitive arrangements of precision resistor networks in a ladder-like configuration. A string resistor ladder implements the non-repetitive reference network.) 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.
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. (High resolution)
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.
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.
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.
You may have to register before you can post comments and get full access to forum.