The first game I made in color using SX-chips was Tetris. Tetris is an old Russian computer game where you should try to fit in block into a play-field, quite simple but really fun. All blocks are built from four bricks (the name Tetris is derived from the ancient greek word for four: ātetraā), there are seven combinations of the four bricks as seen here to the left. This version is using my SX Video Game System as platform, generating a video signal in software. The video generating hardware is a 5-bit DA converter built with a few resistors. Usually the video signal is generated in video games is created with a dedicated video chips, reading the image data from a graphics memory. In this project the video signal is calculated in real-time by the microprocessor as the electron beam sweeps over the screen. This page only describes the software, you can find schematics and description of the hardware here and for your service I also sell the parts for building the system here if you want to make sure you get the correct stuff, donāt have an oscillator, donāt have a programmer or canāt make PCBs yourself.
How to play the game.
When the power is turned on the game starts! (was no memory left for a fancy intro screen or similar). The score is shown left of the gamefield, and the next block to come is shown in the upper left corner of the screen. As the blocks fall down, they can be moved sideways by using the joystick (left gameport on hardware), the fall speed can temporary be increased by moving joystick down. The fire-button is used to rotate the blocks. When one horizontal line is full, then it is removed. You get points for full lines and placed blocks. As you get more points the difficult level is increased by increased block falling speed. The musics speed is increased as the game speed increases. You get game over when the playfield level has reached to the top and there is not room for more blocks (See picture here to the right).
The software
One of the problems for Tetris is the memory required. The size of the playfield is 16Ć8 bricks, to be able to keep track of thee 7 different block kinds (different color for each kind) and also be able to represent empty area, 3 bits are required for each brick. As one byte is 8 bits I chose to represent each brick as one nibble (4 bits), making the playfield 64 bytes. I chose to organize the memory making to the top 4 banks of the memory and letting each memory bank represent two columns. The main game variables are placed in the first bank, some less used data such as score and a buffer of the next block and some other misc. stuff are placed in the second bank. The two remaining banks (except for the top four bytes of the fourth bank) are used as graphics buffers when outputting data to the DA. The sound frequency and sample position are stored in the top four bytes of the fourth bank.
The tune Karboschka is stored in program memory as 52 notes and 52 note lengths, where the note refers to a frequency table with frequencies according to the temperated note scale (half notes differs one twelfth root of two in frequency). There is a 32-sample 4-bit sinus wave in program memory that is outputted to the audio DA at the pace of the current note translated through the frequency table. The code outputting the frequency is performed during the horizontal sync pulse, and the tune is updated at the bottom of the screen before the vertical sync. As the number of bits used for music is not very high, it sounds a little bit distorted and not very good, but better than nothing.
Most of the game data of the game is stored as one big chunk to be able to use the program ROM more efficient. This is done by using all the 12 bits and the iread instruction, which makes it possible to store 50% more data than by using retlw, but at the cost of speed. It is hard to use 12bit data efficiently, but to make it easier I chose to separate the gamedata into one fastmem- and one slowmem- part, where the 8 lower bits of each 12-bit word is the fastmem and the upper 4 bits are the slowmem. Getting one byte from the slowmem requires two iread but the fastmem only requires one. Graphics objects are stored as 4-bit palette values, so is the music, but the font and text strings are all 8-bit values, so it is quite natural to store the 4-bit data in the upper part and the 8-bit data in the lower part.
The software is written to run for both PAL and NTSC with almost the same code, done by making all timing with constants. The constant system selects what TV system to use. In the code I have also prepared timing for PAL-M and PAL-N but they are not tested. It is not possible to generate SECAM color video signals in software with this design, so there is nothing in the code to support it. Note that the frequency which the chip should be clocked depends on your TV-system. (This is described more in the system information page)
For more detail: SX-Tetris
About The Author
Ibrar Ayyub
I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.
Follow Us:LinkedinTwitter