How absolutely fantastic it was to be a owner of a marvellous new piece of technology known as the home computer in 1983, learning fundamentals of programming in BASIC! I had ordered my micro computer by mail and gradually got bored in playing all the game tapes purchased with the machine. So I started studying the programming manual in more detail.
Few days passed and felt like a few hours. It was easy to lose my sense of time while engrossed in learning to program. Soon I had absorbed the basics of BASIC. A dozen or so commands, writing programs one numbered line at the time, storing data as variables in computer memory, conditional and looping structures, saving and loading programs to and from cassettes. Next, I was curious to learn how to make game characters using computer graphics, and how to animate them on screen.
Bits, bytes, pixels, aliens
My first encounter with graphics programming involved redefining Oric-1 fonts. This could be done by setting small integers known as bytes to certain memory locations. Everything seen on the screen was shown using small squares, pixels. When there was a letter on screen, it was in fact a code or ordinal number representing that letter in a memory location corresponding to the row and column on screen. This code indirectly pointed to another memory location, and bytes in that location and certain number of following locations defined the shape or matrix of pixels that looked like the letter.
The code of the letter was known as an ASCII code, and 8 bytes defining the shape of the letter allowed 8 rows of pixels. Each byte was 8 zeros or ones, or bits, zero meaning pixel off and one meaning pixel on. However, one of the peculiarities of Oric-1 was that letter shapes were defined with only 6 bits (or on/off pixels) of each row byte. In other words, the shape of a letter could be defined as 6x8 pixels matrix.
Bitmapped graphics taught me the related digital concepts, such as number systems from binary to decimal to hexadecimal, manipulating bits in bytes using bitwise logical operations, and the memory locations from the tiny 48 kilobyte RAM memory that were used for screen and graphics.
The BASIC Programming manual that had was shipped with Oric-1 contained chapter on graphics programming. Following BASIC program listing can be found in that chapter. It showed to me how one could make programs that resembled arcade video games.
5 REM ** DROPPING ALIENS **
10 GOSUB 1000:CLS
20 FOR M = 1 TO 20
30 PAPER INT(RND(1)*4)+4
40 A = RND (1)*32 + 1
50 ZAP
60 FOR N= 0 TO 1100 STEP 40
70 POKE 48039 + N + A, 1
80 POKE 48040 + N + A, 64
90 POKE 48039 + N + A + 6, 2
100 POKE 48040 + N+ A + 6, 64
110 POKE 48039 + N + A + 3, 3
120 POKE 48040 + N + A + 3, 64
130 SOUND 1, N/2, 0
140 PLAY 1,0,5,5
150 POKE 48040 + N + A, 32
160 POKE 48040 + N + A + 6, 32
170 POKE 48040 + N + A + 3, 32
180 NEXT N
190 EXPLODE
200 WAIT RND(1)*200 + 100
210 NEXT M
1000 REM *** CHARACTER DEFINITION ***
1010 FOR N = 0 TO 7
1020 READ X: POKE 46080 + (64 * 8) + N, X
1030 NEXT N
1040 DATA 18,12,30,45,45,30,18,0
1050 RETURN
This and other programs from this blog post can be tested using a Oric-1 emulator running on PC or Mac. One such emulator is called Oricutron. Emulator is a program that emulates the target computer system down to CPU, memory-mapped I/O, graphics and sound, even mass memory.
Today, looking at the BASIC program listing, it seems at first quite dated and hard to read compared to more modern programming languages and systems. However, by studying a bit the Oric-1 BASIC commands appearing in the program, it becomes rather straightforward to follow how the program works.
On the home computers, user programs written in BASIC were typically interpreted. The BASIC interpreter read and executed the program one program line at the time, following the order defined by the line numbers by default.
Most cryptic part of the program are probably the POKE-statements on many lines. These are used for updating the screen by putting a certain character on certain row and column, or for defining the pixel matrix for the character by putting 8 bytes in the character generator memory area for that particular character.
FOR-NEXT commands are used to execute a set of lines multiple times. In the program above, the inner FOR-NEXT loop continuously writes three redefined characters from first to last line of the screen, however, before moving to the line below the current line, the written characters on current line are erased from screen by replacing the same screen memory locations with white space character code, 32.
This is what the program looks like when it is run:
DROPPING ALIENS, Oric-1, BASIC, 1983
Such a simple program. It only contains 28 program lines, and even that produced an effect that looked like it could be a part of video game displaying aliens descending down to the player, sound effects included!
Well, at least in the eyes of a kid that had played those early video games. These days, the graphics in video games are of course both technically and artistically much more complex and nuanced.
From animation to interaction
After having figured out how to do simple graphics and sound programming, next step was to study how to read keyboard input and make a game character move according to the key presses. Simple enough, this was accomplished by reading values from a certain memory location. Trying out more programming examples from the manual proved to be amazingly effective way of learning more. After numerous exercises, failed attempts and rewrites, I finally made my very first own computer game, SPACEBATTLE.
SPACEBATTLE, Oric-1, BASIC, 1983
SPACEBATTLE was very simple shoot’ em up game, it only featured one alien falling down at a time. On the other hand, I managed to include some pretty advanced features in it. Nothing I had created before awoke such a hilarious feeling than seeing my big brothers playing SPACEBATTLE and their surprise when the falling alien actually dodged the missile shot at it and continued to home in to their spaceship, kamikaze style!
In making SPACEBATTLE, I learned many game design tricks for the first time. These included anticipating player actions and adding primitive form of ’Artificial Intelligence’ to make the game more challenging. I also learned quickly that the challenge in programming games in BASIC was in getting the program run as quickly and smoothly as possible.
I pointed out before that BASIC worked like an interpreter. It interpreted the program line and command at a time, transforming a piece of a program into a sequence of instructions that the central processing unit of the computer understood natively, also known as machine code. BASIC program could therefore be compared to a person who tries to make another person, who does not speak the same language, do a certain procedure, using an intermediate person called the interpreter. Interpreter translates the instructions from the language of the first person to the language of the other person.
When the computer works like this using a single processor, the BASIC program has to wait whenever the processor acts as the interpreter, and after that, actually executes the interpreted machine code. So the processor had to alternate between interpreting the BASIC program and executing the interpreted code. Those days there was only one processing unit or core in the simple microprocessors employed by home computers, and they were about thousand times slower than the processors today. No wonder BASIC programs were slow to run.
After SPACEBATTLE, I made a similar game that I tried to optimise to run faster. I rotated the game layout 90 degrees, made the enemies from multiple characters instead of just one, and included two different types of enemies. I also changed the name to Galactian Attackers, which sounded really cool at the time, though these days the name feels more comical than cool. The game did have the faster pace I was aiming for.
Galactian Attackers, Oric-1, BASIC, 1983
Own clones of classic games
I reapplied the same techniques over and over again in the many of the following games I made for Oric-1. I was always trying to find little tricks to make games more complex without slowing them down too much. I also wanted to make a number of different types of games.
In the beginning, the ideas for the games were taken directly from existing games that I knew or had played. This was fairly common anyway, often even the commercial game creators made games that were clones or imitations of existing, successful games, many times without proper license or attribution to the original. The names and appearances changed a bit, but very often it was obvious that the games were clones. Remember Oricmunch, for example?
I too, made my own versions of existing games, though I never planned to make such games commercially.
The following introduces a few of my not-so-original creations.
Tank vs. Ufo, Oric-1, BASIC, 1983
Tank vs. Ufo was an Oric-1 rewrite of a game that had been originally published for Commodore VIC-20 in some hobbyist magazine. These computer magazines had started to print BASIC source code listings for home computers, so by typing the programs and studying how they were done was another good way to learn about BASIC programming.
Apple Man, Oric-1, BASIC, 1983
Apple Man was my attempt to create a Pacman-like game. I only managed to create one ghost and one bonus fruit, an apple, that constantly appeared in a different spot as soon as the player’s character reached it.
In this game, the interesting part was to trying to figure out how to make the ghost chase the player.
Digdug, Oric-1, BASIC, 1983
I named this program on the tape as Digdug after its paragon, although this is by no means an official port of the classic video game by Namco. It was an attempt to make a game with similar gameplay using Oric-1 graphics. I could not reach the fluidity and detail easily using BASIC alone, so I abandoned the project soon. Before leaving it I did manage to include the weapon featured in the original Digdug, a pump that can be used to blast the monster hopping around in the caverns.
One of the main purposes of the program was to practice making even larger game characters by combining several redefined font characters
Lander, Oric-1, BASIC, 1983
This game, which was inspired by Lunar Lander and Gravitar, used hires graphics mode instead of text mode. In the graphics mode, one could draw simple graphics primitives, such as points, lines, circles, filled areas and text characters at arbitrary pixel position on screen.
Perhaps most notable feature in the Lander game was a physics simulation that used same formula as the artillery game that came bundled with Oric-1. Since then, I’ve implemented a simple rigid object falling simulation in a number of games programs. These days such simulation would not be something to write on one’s own, as it is part of much larger and more versatile physics models featured in various kinematics engines and physics libraries. But in those days, third party programming libraries, especially written with BASIC, simply did not exist. One had to write one’s own libraries.
Invaders, Oric-1, BASIC, 1983
Next, I continued to develop Space Invaders type of games. This one was getting close to its inspiration, as I managed to animate a large number of alien ships at the same time by using string manipulation commands and drawing one whole row of enemies with a single BASIC command.
Aarteen etsintä ('Treasure Hunt'), Oric-1, BASIC, 1983
I also tried making text adventure games. One of the games that I had purchased with my Oric-1 was Zodiac, a text adventure made by Tansoft, the software company of the manufacturer. I had also tried Zork text adventures on friends’ computers. Since home computer graphic and sound capabilities were fairly crude at the time, using only text for input and output could be a fairly successful way of making fun and entertaining games, especially if game developers had a knack for writing humorous and concise text.
Of course, making a text adventure game was completely different from making graphical action games. Core part of the program was a parser and rule engine that applied player’s written commands to the world model maintained by the game. Biggest problem in making a good text adventure was that it was difficult to make the game understand complex natural language. Therefore, the vocabulary and commands I implemented in my text adventure game were very simple.
Also I did not have good enough English skills, I thought, so wrote the adventure in Finnish. Apologies for not localising the game in English, did not have enough time for that.
Even though the game did not include very many rooms, it required the player to move between them several times in order to correctly collect and use various objects in the right places and in right combinations. In fact, when I played the game after over thirty years, it took me couple of hours before I got the treasure chest in my hands. And then I made a mistake with the boa snake featured in the game and died. Since I had not implemented saving the game at all, I would have had to start from the beginning again to complete the game. I decided to retry the game another time.
Text adventures are very rare these days, and I don’t think they are commercially developed or published any more. Some enthusiasts still make the games, either for free or as shareware.
Galactic Guard, Oric-1, BASIC, 1984
Galactic Guard (yet another ’cool’ game name) was last of my Space Invaders clones for Oric-1. It had most advanced game play and polish of them all. It included an intro screen and multiple attack waves with different enemies and enemy patterns.
The year was now 1984 and I had accumulated months of BASIC programming practice.
After this game, I did not make another Invaders shoot’em up until about five years later. At that time, I had started my software engineering studies at Helsinki University of Technology, and created one more invaders variant called Terminal Strikes Back. This time I wrote the game in C language, and it was an assignment for a programming course. To honour my early home computer shmups I used once more simple ASCII graphics and similar string manipulation and plotting techniques that I had developed earlier. Although, Terminal Strikes Back did not have custom graphics fonts, I simply used standard ASCII set characters, a bit like in the Tanks vs. Ufo game. Naturally, my abilities and skills as programmer had developed, and the resulting C code was much more readable and clean than my early BASIC code. Thanks to using C, the game also was quite a bit faster.
By 1984, I had started to bang my head against the limits of Oric BASIC interpreter and BASIC command capabilities. I did program a few more complete games for it, though. The first became my first published game, and the last was my farewell to BASIC game programming. I’ll return to these later BASIC games in a separate blog post.
See also: TAP files
Should you be interested in running the BASIC programs featured in this blog post yourself, you can download them from Oric-1 TAPs -page
--