My first programming language
There’s a chain tweet going around in the programmer’s community these days, one of those old things I used to hate so much. It felt nice today because I actually have a story to tell about it.
- First language: Z80 ASM (accidents happen)
- Had difficulties: awk, perl, now R
- Most used: Python, C++17
- Totally hate: Java
- Most loved: C++
- For beginners: Python, Javascript.
A tweet is, of course, too small to actually capture the whole story, and I’m no Hemingway to use under 10 words for it. So here’s how I got to have Z80 Assembly as my first programming language.
My first computer was a Z80 computer called HC91. 16kB ROM with BASIC, 48kB RAM of which about 9kB were the video buffer, this was quite a nice tool, although slightly underpowered and a bit overpriced for the time. I absolutely loved it. It is what got me started in computing.
To go along with the computer I also bought the book „How to write computer games” by Ion Diamandi. I’m a bit torn about this book. I can’t say I learned much from it, but I’d lie – I did learn a lot from it, but it was also my biggest disappointments. For this book, the language of choice was a very basic BASIC language that worked on the local HC series of computers.
I tried to write the programs from the book to see them work. I never tried to modify them, and I can’t tell if this is my failing or the book’s – anyway, either the biggest program that Diamandi included in his book was buggy, or I didn’t manage to type it correctly, but I failed to run it. And I just gave up. I said: you know what? Copying programs and them not working… this isn’t for me.
At the same time, in Romania circulated a lot of tapes with games. Real games this time, games like LodeRunner, Manic Miner, R-Type and Zynaps. And I got very very frustrated because what the author of that computer book understood a game is was quite far from what I understood as being a game.
That bugged me. I kind of knew that it is possible to write games some other way, because the only semi-acceptable game I seen that was written in BASIC was some sort of Monopoly that was kind of boring (but, in the end, all Monopoly games are boring, more so when you’re losing). So there had to be some other way – and that other way was POKE and PEEK, which was presented in Diamandi’s book, and I can’t remember if he also said something about programming in Assembly or not, but that was actually the gateway for me. What is PEEK and POKE? BASIC instructions: PEEK reads from a memory cell, POKE writes to it. „So that’s how it’s done!” I said, and went on to find other resources.
And resources I found. I can’t remember how I managed to borrow a copy of „Almost everything about the Z80 microprocessor” by Miklos Patrubány. Now, Mr. Patrubány was not writing about how to write games, and the book was exactly what it advertised, although I didn’t understand it at the time. I took notes out of that book, understood how the assembly language works, how you fill in registers, how you read memory, how you operate on the memory (because that’s what this is about after all) and he kept discussing about doing I/O, but I didn’t understand much about that part – I was 12, that was my first computer, and I never thought that you could plug in stuff, and what I/O could actually mean. So all was good, I was learning how to write programs (on paper, mind you, because my folks thought the computer was strictly a gaming tool and they seriously restricted my access to it). I then managed to get around an assembly tool, and while loading and reading registers and doing math on them was fun, the fact that I couldn’t draw a pixel wasn’t. So when, in his book, Mr. Patrubány was talking about hidden instructions, I said „surely a procedure to set a pixel is in those hidden instructions!”.
It wasn’t. What Mr. Patrubány was referring to was completely different, but that didn’t stop me. It took quite some time for me to find what that was all about, and to understand that, no, things must be very different. Then I went back to the drawing board. Well, to re-reading the book I had.
Now, you have to understand that the only resources I had were Diamandi’s book, the memory of (and the notes on) the assembly language, and the occasional chance to actually touch the computer. It was a frustrating experience. Eventually I figured it out – I can’t remember how or why – the video memory was actually just that, video memory, and it had a very very strange layout. The whole screen was made of 8×8 squares, each 8 pixels row as coded as a byte, with 1s being „foreground” and 0s being „background” – and after these squares definition area there was a color area in which each cell received a byte that contained the colors (16 colors for foreground, 16 for background, encoded in one byte). The rows of pixels were not even in the order you’d expect. So, starting from offset 16384 in memory (that’s a power of 2) you had the first row of the first cell, the the first row of the second cell – and so on for the first row of cells, then you had the first row of the first cell from the second row of cells. Once you exhausted the first row of all the cells of the screen, you started with the second pixel row.
INSANITY. And it was only when I understood that, by playing with the memory in assembly, by writing small programs placed there with POKE (oh, yeah, I didn’t even bother with writing a small BASIC program to POKE stuff around) I understood that I lacked the proper tools to write proper programs. By the time I actually got proper programming tools it was too late – I was already supposed to write programs in Pascal for school.
But learning Z80 Assembly from Mr. Patrubány’s book was actually the catalyst for my understanding of technology. I knew there was no magic. I knew there was no hidden way to do things. I understood (at one point of time) that all there is to computing is manipulating numbers. I understood later why Mr. Diamandi’s book could never explain how to write the game I wanted.
But I still find it funny that I did not start programming by learning BASIC, which was the main programming language that hit me from the start of my computer. I mean, to load a tape with a game I needed to type LOAD „” on my keyboard, which was a ZXSpectrum BASIC command. To write assembly I needed to use BASIC instructions – but outside of that, for a while I never even thought to change a variable name or a line number from the listings from Mr. Diamandi’s book on how to write a game. This is where that book failed at first – it really didn’t make me want to change something in its program listings. I was basically a typing monkey in that language.
Learning Assembly, however, required me to make a conscious effort in actually programming the computer. I understood then what „programming” actually means: writing machine code and getting to execute it. My programs were 10-200 bytes long and ended with a crash, and there was an immense effort to write them. I spent a lot of time writing those bytes, making sure that they are the right bytes, I wrote tons on paper with what I planned to do. In a sense, that was no different from the early programmers writing programs on punch-cards.
I will not lie to myself to say that I actually understood how my ZXSpectrum HC91 worked. I do understand now, but I didn’t back then, and by the time I learned I was already writing my own stuff on my 400MHz AMD K6-2, and playing with an emulator. My understanding of the tool I worked with was a mess – and this was not the last case where I failed to understand how some things work, but it definitely was the most spectacular. I was, after all, 12 and had close to zero guidance on the topic. One year later I was actually writing BASIC code, and actually coding in BASIC, but understood that all that I do in BASIC is, well… basic, and the language is sugar-coating something that was faster, smarter and more efficient.
Maybe next time I’ll rehash the story of how I made my computer science teacher hate me for learning C instead of Pascal.