How I grew up without Kodabra

Twenty years ago I wrote the first line of code: 10 CLS . Exactly, without greeting the world and without imagining what was waiting for me, I entered RUN after it and the electronic machine also unceremoniously threw me the first challenge, having erased everything on the TV screen with a mock "OK". I was surprised, but not that I can order the car to do something, but that it can answer me. I was 7, and this is a story about a child’s uneasy relationship with a computer, through the lens of years through the eyes of a programmer.

By the time I wrote the first program, I was already an “advanced user” of consumer electronics in the house. As any child knows, if something has buttons or knobs, then these buttons should be pressed without fail, and the knobs should be screwed all the way. Fortunately, no one forbade me to do this for my own sake, and, as expected, one day the handles became insufficient and bolts and screws went in motion, revealing to my gaze the wonderful world of printed circuit boards and microcircuits. My father clearly approved of my inclinations to sort everything out and tried to teach me more and collect these things back by teaching the basics of radio engineering in practice. I liked to solder and assemble simple devices, but I did not achieve much success here. The physical world looked too boring compared to the Dendy game console that appeared at that time. And here I have achieved truly outstanding success.

An important contribution of games to the development of computer skills in a child, in my opinion, is the need for constant interaction with different user interfaces, which, unlike computer programs, are different in all games, but perform standard functions. This quickly develops "computer savvy", subconsciously highlighting certain common patterns (for example, game settings), allowing you to quickly orient yourself even on an unfamiliar screen with time. And, of course, buttons. Having mastered the gamepad, the child can easily master any keyboard.

I spent on the console almost all the free time that my parents gave me on TV. It is not difficult to understand that it is not an easy task to captivate a child with something else when he has games. But once the parents managed to turn a truly grand trick by buying for me the “Teaching Computer Syub”. A feature of this device was that it possessed a full-size IBM keyboard, being in fact the same Dendy complete with a “training cartridge”, on which several programs were written that support input from this keyboard. A nostalgic reader can follow the link to the site " Iron Ghosts of the Past " to recall this legendary console. The programs on the “learning cartridge”, although they were not of very good quality, included as many as two interpreters of the Basic programming language. One was called "G-BASIC", and the second one was "F-BASIC". Now I know that these were heavily trimmed clones of Famicom BASIC and Applesoft Basic, respectively. The documentation on "F-BASIC" was almost completely absent, so I did not manage to master it in any way. "G-BASIC" turned out to be quite an interesting thing, because it contained a graphics editor based on patterns, as if cut from some version of "Mario" and a set of embedded sprites from the same "Mario" that could be moved and animated with using code. In other words, it was possible to write the whole game on it!

photo 20 century

Unfortunately, this was not entirely true. I learned how to move sprites around the screen fairly quickly, the image editor also did not make any problems. Having played enough with examples from the attached book, I wanted to create my own interpretation of the Green Beret game (known also as Rush'n Attack), which was my favorite game at that time, and then the first disappointment came - you couldn't draw your own sprite, the SPRITE operator worked with embedded sprites only. Mario and his friends, for obvious reasons, did not fit the role in the game of armed confrontation between the USSR and the USA. Having shown ingenuity, I tried to draw a “commando” using ASCII characters, but this idea was deliberately a failure. At that moment, "syubor" almost died for me. From the hopelessness and the temporary lack of new games on Dendy, I had to deal with the cycles, keyboard input and write programs to solve school math examples. By the end of the first grade of school, only two mysterious BASIC operators, E and , were left for me, which were intended to write and read data from memory. Subconsciously, I felt some huge potential in them, as I still did not abandon the idea of ​​drawing my own sprite and believed in a miracle. But the almost complete lack of documentation and authoritative assistance played a role, and I could not find a real use for these operators, although I learned to read the memory at an arbitrary address and could even force the console to reboot by writing something to an insecure area of ​​memory.

Arguing now about the role of "sybora" in my development, as a programmer, I do not attach much importance to it. It was difficult to perceive it as something more than just another game, while not too well done. It was the first experience of meeting with bad software, but it gave impetus to the study of the issue, because I already knew about the "adult" computers and what they can do compared with my "sybor". I read the father's magazine "Radio", scrolling through all the articles about electronics and stuck on printouts of 16-dong dumps of programs for microcontrollers. It was impossible to understand anything, but at that time I would give a lot to the computer in which these dumps could at least be entered.

My dream came true exactly for the new year, but in a very strange way. Instead of an IBM PC / XT with a large monitor and floppy drive, I got a non-ordinary box with another “keyboard” inside called “Home Computer Companion-2 ”.

The Companion was a Russian clone of the previously popular ZX Spectrum, it had 48 kb of RAM, interfaces for connecting joysticks and a tape recorder for storing and loading data from a magnetic tape. Like a game console, it had to be connected to a TV set, or to a special monitor, which I, of course, did not have. I had to tinker with the connection to the TV (the TV-out on my computer model was broken), make a cable for the RGB interface and find a suitable tape recorder. And after some time, the screen blinked with the Sinclair BASIC welcome cursor. I got a wonderful book “ How to write a game for ZX Spectrum ” and a couple of cassettes with games as a bonus to the computer, so by the time the computer was successfully turned on, I already knew what to do. Of course, run the game.

Photo Retro Tresaures

After a few days of desperate rewinding of cassettes and endless waiting for large games to download to the sound of zeros and units recorded on tape, speeding at 1535 baud straight into the RAM of my computer, I realized that all games on the Spectrum are absolutely worthless compared to Dendy. This situation again left me alone with a BASIC.

In contrast to the “plot” with its toy programming, here the language was full-fledged, not tied to the stupid graphics from “Mario” and twice a large number of operators. In proportion to the possibilities, the complexity has grown, and with it the interest. I perfectly understood that now I am limited only by my own knowledge and skills, and not by the machine itself, so I had to get down to business seriously. My goal was still to write my own game.

First of all, I needed sprites and, since I didn’t have the drawing program described in the book “Art Studio” for drawing graphics, I had to arm myself with a notebook in a cell. I drew the necessary sprites pokletnochno, and then transferred them to the screen through the code. It was an amazingly monotonous and difficult job, in which it was very easy to make a mistake. But the result was visible immediately and it was very encouraging. At this stage, I didn’t even need to save my programs, because they were "drawn" in my notebook, and each time I typed the code again to get used to the new keyboard. On the Spectrum, almost all the BASIC commands were written directly on the keys and, as a rule, only one press was required to dial a single command.

After a couple of weeks and notebooks, I had sprites "special forces", "enemies", and some of the scenery. I even came up with a name for the game while I was painting - “Soldier of Fortune”. The essence was standard - kill all enemies. The player could control the hero and shoot with a joystick, while the enemies moved in a chaotic manner, trying to hit the hero hand to hand. Additional complexity was made by the scenery in the form of a "jungle" through which it was impossible to pass and no bullets flew.

Teaching a “commando” to walk turned out to be a simple task, the code for this was not very different from the “Syborovsky” one that I already knew. But with the enemies there was the first difficult task in my programming practice. It was easy to move sprites in completely random directions, but this made the game too unpredictable, not to mention the fact that the enemies didn’t give a damn about the hero. I had to invent some kind of "artificial intelligence" for the enemies in order to play was interesting. I spent many months doing this exercise, constantly experimenting and changing the logic of the program. The more my program became, the more inconvenience the BAS with its endless GO TO and PAUSE began to deliver. Once I managed to get a second book from the series “How to write a game for ZX Spectrum”, which was called “ How to write a game in assembly language for ZX Spectrum ”. It was a real hardcore for children's brains, but I read out, marveling at the possibilities provided by the ZX80 assembly language.

There was one problem. I did not have an assembler translator program and I could not immediately practice reading the book. But I had a BASIC and the very POKE and PEEK , whose full potential I was able to realize only now. I plunged into the world of memory, addresses and unpredictable consequences. Cautions in the book that it is not necessary to write down what came to the addresses whose purpose you do not know, I was not too stopped. The first thing I did was experimenting with a so-called. "system variables" - addresses in memory, which stored data for the "operating system", relating to all aspects of computer life, from the keyboard to the monitor. From BASIC, it was just, for example, you enter 23659,0 - and the entire screen is already at your disposal, without a system window! Needless to say, how much has my game improved after adding to it the capabilities that the “system variables” gave? But remembering addresses and numeric values ​​that can be written there is completely inconvenient, not to mention that I could not imagine how examples of assembly code from the book will work. Then I had a crazy idea to write a translator myself. More precisely, I realized that I was engaged in writing an assembly language compiler, much later than I began to do this. I just had a table of assembler mnemonics and corresponding hexadecimal codes, and I thought, why not write a program to translate from one to another, because with hexadecimal numbers in BASIC I already knew how to handle.

Screenshot Viva Games

The more I plunged into the world of the assembler, the more I understood how my computer actually works and why it works this way and not otherwise. Years passed after this occupation, after which I had a "real" computer on x86, opening up new horizons of knowledge. Now, thanks to the "specs", I already knew exactly what to do with it.

Looking back now at my first programming experience and Basic as the first language, I’m not quite sure about its positive assessment. Starting to study the "big" programming languages, I ran into certain problems caused by the habit of thinking in terms of strings and unconditional jumps, it was a bit painful to relearn. With the assembler, the situation is clearer. Although the x86 and Z80 architectures have quite a bit in common, the underlying principles do not change and this knowledge still helps me even when programming in high-level languages, so I definitely didn’t lose it.

As you understand, my path to programming can hardly be called standard, even for the 90s, mainly because of the specific equipment on which one had to learn. Indeed, at that time, x86-based computers were already common in Russia, and many of my familiar programmers started their way on them without feeling the need to literally “pick up the hardware” in search of the necessary function and write code editors to themselves. Reflecting on this, I wonder about modern children and how they study programming now, after almost 50 years of the unrestrained development of computer technology and the penetration of computers in virtually all spheres of human life. By happy coincidence, on the path of life, I met good guys from Kodabra, who discovered some secrets from the life of modern schoolchildren.

To begin with about school. In my time, the lessons of "computer science" at school looked very sad, mainly due to the lack of really competent teachers and equipment. I was bored there, and my classmates were just fooling around because they didn't understand anything. What is worth only programming in notebooks. Who could have thought of such nonsense? Programming and computers are inextricably linked. You can execute code in your mind and you can write it with a marker on the window, but only when you already know exactly how it works in a computer, and for this, of course, you need a computer itself. Fortunately, now there are no such problems even, probably, in the most remote parts of our country. Children begin to study the computer practically from primary school and even if they do not have their own home, by the 7th grade they will still become the very “PC Operators”. And then real computer science begins, the quality of which, as in my times, is highly dependent on the teacher and the school.

Kodabra, of course, does not have such problems, since all of its teachers are professional programmers themselves and build their lessons into practice. I was not surprised to learn that even now the most effective teaching of programming for children is built on games. With the advent of Unity, this occupation has become even more friendly and interesting, and most importantly, without BASIC - here C # is used for classes. Although now I don’t often have to use C # in my work, but it’s impossible not to admit that at the moment it is one of the very well-designed modern programming languages. It is not very suitable for learning the basics, but it is not required. For younger children, visual programming languages ​​such as Scratch are practiced. Visual programming is an excellent idea for getting to know basic concepts in programming, such as a variable, condition, or cycle, and you can draw colored sprites there!

It is a pity that in recent years low-level things have been falling more often when teaching programming or are considered tops, because moving from a high level to a low is much more difficult than vice versa. But rapidly gaining popularity, including in school circles, Arduino, Raspberry Pi and the growing “Internet of Things” every day, promise to change the situation for the better soon. With the right approach, the Arduino can become a “second Spectrum” for the child, present invaluable knowledge in the future and take a lot of exciting hours.

I wish Kodabra to create courses on low-level programming and hardware for children as soon as possible, and invite the habravchan to attend the Digitalfest Festival of Digital Creativity for Children and Teens on December 4, which will also include a section on the Internet of Things and Robotics. You can acquaint the child with not quite standard computers.