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.
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.
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.
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 source, to compile with AVR-GCC:
or get it all in a zip:
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
Comments powered by Talkyard