The Lost Ways of Programming: Commodore 64 Basic(tomasp.net)
tomasp.net
The Lost Ways of Programming: Commodore 64 Basic
http://tomasp.net/commodore64/
55 comments
Considering the RAM and storage restrictions of those machines, hosting a compiler would have been quite challenging. Where would it store object files or the final executable? On Datasette? And, the 6502's CPU stack is limited to a whopping 256 bytes! With an interpreter burned into ROM, we only needed the BASIC code to reside in RAM. And, of course, the occasional assembly routine to speed things up. I remember how entering a hex dumper (and disassembler, if possible) was always among the first things I did on such a box. I hacked the ROM of the Atari 800 to find out where those BCD floating-point subroutines were located, so I wouldn't have to run the computation loop of my Mandelbrot fractal generator from BASIC. That made a hell of a difference. Today's sports disciplines are a bit more elaborate. It came to the point where I could enter 6502 instruction codes in hex from memory because the instruction set is so small you could actually have it memorized, just as a side effect of daily use.
I still remember the elation I felt when I finally got my hands on a machine that could actually run a C compiler and had “high-resolution” graphics, not to mention an operating system that was documented. It felt like changing from a horse cart to a racing car. Today's computers are science-fiction space ships compared to that.
Another old man, out.
I still remember the elation I felt when I finally got my hands on a machine that could actually run a C compiler and had “high-resolution” graphics, not to mention an operating system that was documented. It felt like changing from a horse cart to a racing car. Today's computers are science-fiction space ships compared to that.
Another old man, out.
I always had contempt for BASIC languages in the 80th. Being a tough demo coder in assembler, I thought that this isn't the real stuff.
Today I agree with you.
After re-entering the world of 8bit and 16bit Commodores again, I finally utilized these. Indeed you could do quite a few tricks with them, and they are quite powerful.
There is beauty in the ease of use of these languages. And to be honest, there is a lot of hardship in languages like assembler.
The whole IDE idea for Java, Kotlin, etc. reminds me more of BASIC than C. Especially that BASIC is somewhat forgiving if you make mistakes, aka bugs, I appreciate. If you make mistakes in assembler on Amiga 500/1200, for example, you most often have to reset the machine. If you forgot to save your work before testing, you would suffer even more. And this is not the coolest of all workflows. Even on emulators like WinUAE, where you need timing to hit the debug key.
Assembler is complicated (word operations accessing an odd memory address is hard to find) and only useful in very constraint areas like elder computers.
BASIC is simple, and therefore fast.
With computers doing the heavy lifting nowadays, I keep the speed part to the computers while focusing on fast iterations. Except for the Amiga, where I think that BASIC and assembler can coexist nowadays for me. Should have utilized BASIC back then for simple things.
Today I agree with you.
After re-entering the world of 8bit and 16bit Commodores again, I finally utilized these. Indeed you could do quite a few tricks with them, and they are quite powerful.
There is beauty in the ease of use of these languages. And to be honest, there is a lot of hardship in languages like assembler.
The whole IDE idea for Java, Kotlin, etc. reminds me more of BASIC than C. Especially that BASIC is somewhat forgiving if you make mistakes, aka bugs, I appreciate. If you make mistakes in assembler on Amiga 500/1200, for example, you most often have to reset the machine. If you forgot to save your work before testing, you would suffer even more. And this is not the coolest of all workflows. Even on emulators like WinUAE, where you need timing to hit the debug key.
Assembler is complicated (word operations accessing an odd memory address is hard to find) and only useful in very constraint areas like elder computers.
BASIC is simple, and therefore fast.
With computers doing the heavy lifting nowadays, I keep the speed part to the computers while focusing on fast iterations. Except for the Amiga, where I think that BASIC and assembler can coexist nowadays for me. Should have utilized BASIC back then for simple things.
80’s Basic “REPL” and lack of local context (except for BBC Basic) made observing and debugging programs much easier than any modern system, despite the amazing debuggers we now have.
Break/modify/continue was the norm. It somehow worked much better than e.g. the JavaScript console on a modern browser even though reading a description of it wouldn’t give any indication of that.
Break/modify/continue was the norm. It somehow worked much better than e.g. the JavaScript console on a modern browser even though reading a description of it wouldn’t give any indication of that.
The nice thing is that such beauties of interfaces are rediscovered by the younger generations. The rise of the REPL interface for python is a great example which makes this language feel a lot like BASIC on stereoids. And the notebook interface was kind of a game changer for open source scientific computing. Despite volunteered by some software from the 80s and 90s (thinking of the young Mathematica and Matlab GUIs), it is something which really got widespread nowadays, from my feeling. The distributed nature of these tools over the web is probably boosting this experience.
Furtheremore, the small joy for programming can always be around the corner. Take for instasnce https://tixy.land/ , its a small creative code environment. Or take https://d3js.org/ as a bigger ecosystem which made animations and svg really fun and easy with javascript.
Furtheremore, the small joy for programming can always be around the corner. Take for instasnce https://tixy.land/ , its a small creative code environment. Or take https://d3js.org/ as a bigger ecosystem which made animations and svg really fun and easy with javascript.
This use case is part of why I'm so disappointed in some python 3 changes. 2 was definitely more suitable for a newcomer experimenting in a REPL by virtue of its greater simplicity and intuitiveness.
It’s really surprising how converting print from a statement to a function made repl debugging much less convenient.
I don't see "print(x)" being in any way worse then "print x". If you want to save some characters, you can always just write the symbol in the REPL line:
>>> x=42
>>> x
42
>>> print("the answer to life is %d" % x, "not 0")
the answer to life is 42 not 0
>>> "the answer to life is %d" % x, "not 0"
('the answer to life is 42', 'not 0')> C, Pascal, FORTRAN, and friends all had a compile step which meant that you had to operate a text editor and command-line... BASIC was so much more immediate and straightforward to learn on.
A "text editor and command line" workflow requires a notion of files which just wasn't a thing in those early machines (except as part of custom disk-mamagement commands). What they had was a sort of line editor as part of the UI itself - if you typed a line number at the prompt, that line would be replaced in memory. Of course this worked really well with early BASIC where control flow is expressed entirely via those line numbers. Some primitive visual editing was also allowed - you could LIST some lines of code, then change a line on the screen and press the enter key - the ROM would then read the complete line of code from the screen and update it in the actual listing. It could get confusing at times, but mostly it worked quite well.
A "text editor and command line" workflow requires a notion of files which just wasn't a thing in those early machines (except as part of custom disk-mamagement commands). What they had was a sort of line editor as part of the UI itself - if you typed a line number at the prompt, that line would be replaced in memory. Of course this worked really well with early BASIC where control flow is expressed entirely via those line numbers. Some primitive visual editing was also allowed - you could LIST some lines of code, then change a line on the screen and press the enter key - the ROM would then read the complete line of code from the screen and update it in the actual listing. It could get confusing at times, but mostly it worked quite well.
A notion of files was certainly there for the Commodore 64, and many programming language environments for the C64 included code editors that supported saving/loading files on disk directly, including macro-assemblers, for that matter.
> The early web was a lot like the early micros -- you had to make your own entertainment as you quickly ran out of things to do, and the things you were able to make were comparable to the things built by well-founded teams.
I'd never made this connection before but it seems both obvious and profound in retrospect. Thanks.
I'd never made this connection before but it seems both obvious and profound in retrospect. Thanks.
> Random number guessing games are lame, Dad.
Drawing a circle on the screen is still pretty cool for kids. Not like super cool, but qbasic is a lot more accessible than anything more modern (other than maybe scratch, but that's weird)
Drawing a circle on the screen is still pretty cool for kids. Not like super cool, but qbasic is a lot more accessible than anything more modern (other than maybe scratch, but that's weird)
I have a 12-year-old. The killer app for learning programming for him has been Minecraft bots. He's on Discord with a group of friends from all over the world, and they're learning to program by writing bots in Javascript. Those bots watch what happens on the server and react. His current project is writing a bot that can play connect-4 with the user. He's slowly reinventing the minimax algorithm and having a lot of fun doing it.
There was a thread about a month back where some of these points came out - where I shared the exact frustration you feel!
I think these days the interesting building blocks may have to be more "intelligent".
https://news.ycombinator.com/item?id=24706571
I think these days the interesting building blocks may have to be more "intelligent".
https://news.ycombinator.com/item?id=24706571
I started programming on an amiga. After some amigabasic and later amos, a wanted to learn a real language. I got a book about C, but the compiler was a pain. It didn't fit in one floppy and I has no hard drive.
Learning assembly was the natural way out.
Learning assembly was the natural way out.
There was that weird period on the Amiga when using assembler felt easier - especially with a proper macro assembler - than C. I remember having a C library for some user interface component that I compiled to C and then disassembled to optimise (by hand) because the C compiler was "useless" and improve on.
Of course the Amiga got other interesting languages, like AmigaE (whose author is probably better known for FlatBuffers these days, but AmigaE was a usability revelation at the time)
Of course the Amiga got other interesting languages, like AmigaE (whose author is probably better known for FlatBuffers these days, but AmigaE was a usability revelation at the time)
I had a Pascal interpreter for the ZX Spectrum, on a book form that I had to type in, languages and implementations are orthogonal.
Really with Javascript on a web page you can do the same thing, except there’s much more structure and power.
The Node's REPL is not very comfortable for creating and running snippets. The Basic environment has the magic LIST command that shows you the current state.
I think the Smalltalk environments with the object browsers were (and are) the ultimate fiddling environments.
I think the Smalltalk environments with the object browsers were (and are) the ultimate fiddling environments.
You could even pass in the line number or range and the list command would only show that part of it.
I mean in a web browser, not Node.
I cut my teeth on C64 BASIC. I got one (a C64) for christmas 1984, the manual had several pages of sample programs that you could program (one ever had a mistake in it). By New Years day I had tried atleast 4 of them.
I'll be honest, I had more fun making making ASCII art that would endlessly scroll & loop thanks to a "GOTO 10" at the end of my creation.
If I'm even more honest, I find myself wishing for a GOTO command I could use in my bash scripts once in a blue moon. (I know they are a bad/horrible/lame crutch, but my brain seems to blank out any other options and just says to me: a GOTO would work perfect here.)
If it wasn't for a C64 and BASIC, I wouldn't have the career and love of technology that I still do [Checks calendar, HOLY FUCK] 36 years later.
I'll be honest, I had more fun making making ASCII art that would endlessly scroll & loop thanks to a "GOTO 10" at the end of my creation.
If I'm even more honest, I find myself wishing for a GOTO command I could use in my bash scripts once in a blue moon. (I know they are a bad/horrible/lame crutch, but my brain seems to blank out any other options and just says to me: a GOTO would work perfect here.)
If it wasn't for a C64 and BASIC, I wouldn't have the career and love of technology that I still do [Checks calendar, HOLY FUCK] 36 years later.
To paraphrase myself¹:
C64 Basic does not have functions. This makes Basic programs tend to spaghetti and unreadable code, especially considering the constant memory constraints of those platforms. I grew up on these systems, and every time I think back on it I wish something like Forth would have taken its place - i.e. something with a clean and scalable pattern for abstraction. Basic, on the other hand, doesn't do abstractions. It barely has data types and what it calls “functions” are an even more limited form of Python's style of lambdas; every subset of code which can actually do something looks like “GOSUB 11600” when you call it. No naming, no abstractions, nothing.
(This is in some ways even worse than assembler, which usually has labeled goto’s.)
Reportedly, BBC Basic on the BBC Micro has proper named functions! I believe that basing this project on that Basic would have been vastly more productive and taught people the usefulness of abstracting things as you go, building ever higher abstractions, etc. But I suspect that the C64 (and its recognizable blue color scheme, which the whole page uses) brings more nostalgia-fueled clicks and shares.
1. https://news.ycombinator.com/item?id=19245814
C64 Basic does not have functions. This makes Basic programs tend to spaghetti and unreadable code, especially considering the constant memory constraints of those platforms. I grew up on these systems, and every time I think back on it I wish something like Forth would have taken its place - i.e. something with a clean and scalable pattern for abstraction. Basic, on the other hand, doesn't do abstractions. It barely has data types and what it calls “functions” are an even more limited form of Python's style of lambdas; every subset of code which can actually do something looks like “GOSUB 11600” when you call it. No naming, no abstractions, nothing.
(This is in some ways even worse than assembler, which usually has labeled goto’s.)
Reportedly, BBC Basic on the BBC Micro has proper named functions! I believe that basing this project on that Basic would have been vastly more productive and taught people the usefulness of abstracting things as you go, building ever higher abstractions, etc. But I suspect that the C64 (and its recognizable blue color scheme, which the whole page uses) brings more nostalgia-fueled clicks and shares.
1. https://news.ycombinator.com/item?id=19245814
QuickBasic on DOS was quite a comfy procedural language (including functions). It was Microsoft's successor to their old MS BASIC, variations of which were used by most 8 bitters (at least US-made ones).
Exactly. Basic in 80s micros was effectively the operating system, a more apt comparison in terms of today's technology would be sh/bash: its main purpose is to be a quick interface, and while you certainly can program in it, but I doubt it has more educational value compared to something more structured.
I also don't agree with the notion that a more immediate programming environment will cause more people to understand programming/computer science. The notion that there exist machines that you have the power and responsibility to arbitrarily program yourself is the biggest hurdle. I, like many on this board, regard the previous as a profound natural truth. Most people just don't care, it's unrealistic and even a bit paternalistic to assume they will change their preferences if we give them different tools.
I also don't agree with the notion that a more immediate programming environment will cause more people to understand programming/computer science. The notion that there exist machines that you have the power and responsibility to arbitrarily program yourself is the biggest hurdle. I, like many on this board, regard the previous as a profound natural truth. Most people just don't care, it's unrealistic and even a bit paternalistic to assume they will change their preferences if we give them different tools.
I learned to program on a commodore 64 at age 7. There was a game were a gorilla threw an explosive banana on a city skyline. I think it was more a demo for the basic language than a game but it was awesome to 7 year old me when my dad let me use his work computer and play it. I learned that there was a file that controlled the game and it had easy to understand text in it like explosion_radius = 7. A few years later I wrote an "artificial intelligence" program that was just a few hundred if statements and input prompts on my dad's brand new 286. It asked you questions and then responded, carrying on a very basic conversation. Thanks basic (and dad)
Sounds like QBasic. C64 basic identifiers are limited to two characters.
Yeah, that game sounds exactly like GORILLA.BAS, which was distributed with QBasic. It would have actually been somewhat difficult to implement in BASIC on the C64, as much of the graphics functionality of the C64 was only accessible from BASIC using PEEK/POKE.
The manual for the c64 included examples of animating sprites in basic using poke.
It was not hard, though not very user friendly.
It was not hard, though not very user friendly.
Sort of. They can be longer, but C64 basic ignores anything past the first two. So e.g explosive and expensive would be treated as the same identifier.
Yes that's it. The details are hazy and now that you mention it I think they might have been only two characters. I just remember spending hours fooling around see what I could change and then rerunning the game.
The nice thing about early microcomputer BASIC is that it was a "clean" extension of a desk calculator interface. You could input simple computations at the REPL, preceded by a '?' sign (the abbreviated token for the PRINT command) and they would be performed using floating point arithmetic. (Those softfloat routines took up a lot of space in home computer ROM!) The UX was thus perhaps rather inelegant compared to something more principled like FORTH, but it would've been quite appealing to many novice users seeking to make some use of their newly-bought machine - back then, such users would've been expected to learn programming and develop their own programs on the machine itself.
Of course those computers also had worthwhile graphics and sound capabilities, but typically those were machine-specific and programmed by dealing with the memory-mapped hardware directly, even in BASIC. (There were special instructions PEEK(addr) and POKE addr, val for this purpose.) Similarly, other instructions (SYS, USR()) were used for calling custom machine-language routines either from ROM or user-loaded code - which could be plenty useful since BASIC itself, being interpreted, was relatively slow.
Of course those computers also had worthwhile graphics and sound capabilities, but typically those were machine-specific and programmed by dealing with the memory-mapped hardware directly, even in BASIC. (There were special instructions PEEK(addr) and POKE addr, val for this purpose.) Similarly, other instructions (SYS, USR()) were used for calling custom machine-language routines either from ROM or user-loaded code - which could be plenty useful since BASIC itself, being interpreted, was relatively slow.
How many people learned to type by typing in programs from magazines? I did.
By the time I took "typing" freshman year in high school I could type 80wpm. No issues. I received an F in typing and couldn't understand why. When I asked the teacher I was told I was typing wrong and had to use home row. Even though my typing was fast with few mistakes, still received an F. The teacher couldn't understand I taught myself to type using a Commodore 64. He maintained there is only one way to type and I explained he was wrong.
Parents and principal got involved. The negotiated result was a B in the class, I had to apologize to the teacher and had study hall for the rest of the semester.
Everything from Compute or Computes Gazette was awesome. You'd type it all in and sometimes it didn't work ... you could wait until the next month when fixes were printed or you could debug and solve it yourself.
This started to end with the release of SpeedScript, which was the first MLX release from the magazine. Since it was machine language you didn't enter the program lines, but numbers.
https://en.wikipedia.org/wiki/SpeedScript
Amazing times.
By the time I took "typing" freshman year in high school I could type 80wpm. No issues. I received an F in typing and couldn't understand why. When I asked the teacher I was told I was typing wrong and had to use home row. Even though my typing was fast with few mistakes, still received an F. The teacher couldn't understand I taught myself to type using a Commodore 64. He maintained there is only one way to type and I explained he was wrong.
Parents and principal got involved. The negotiated result was a B in the class, I had to apologize to the teacher and had study hall for the rest of the semester.
Everything from Compute or Computes Gazette was awesome. You'd type it all in and sometimes it didn't work ... you could wait until the next month when fixes were printed or you could debug and solve it yourself.
This started to end with the release of SpeedScript, which was the first MLX release from the magazine. Since it was machine language you didn't enter the program lines, but numbers.
https://en.wikipedia.org/wiki/SpeedScript
Amazing times.
Computing was way more fun and much more exciting back then than it is now. It was so easy to get started. My parents kept reminding me to spend less time playing around the computer and more time studying for school...
Now, 40 years later, I'm still living off those skills acquired back then...
Lovely article. The clear superiority of the C64 experience in some respects as well as the popularity of Pico-8 (including amongst longtime games industry veterans) both indicate that something is seriously amiss with current computing; it's not just nostalgia. Both offer a much greater immediacy and responsiveness that makes them more productive in many settings despite their primitiveness.
It's not like the C64 or Basic were earth shattering marvels of design either so the fact that the c64-inspired but ~5 orders of magnitude more powerful raspberry Pi 4 compares very unfavourable in terms of startup time and probably quite a few other latency metrics is pretty depressing.
It's not like the C64 or Basic were earth shattering marvels of design either so the fact that the c64-inspired but ~5 orders of magnitude more powerful raspberry Pi 4 compares very unfavourable in terms of startup time and probably quite a few other latency metrics is pretty depressing.
In 1982 I got a Commodore PET 2001 which my mother rented-to-own when I badly injured a leg and would be immobile for quite awhile. I started playing the games off of the cassettes included with the machine and at some point I typed "List" for the first time. That opened a world that redirected my entire life. I started trying to understand the code and alter the games so I could cheat. Then tried to replicate how the games worked, then made new games, and on and on. The accessibility of that process is rare today.
While countless computers have come and gone in the ~40 years since, I still have that PET in my basement.
While countless computers have come and gone in the ~40 years since, I still have that PET in my basement.
This is really nicely done with the built in emulator. Actually works quite well on my phone but I will come back and finish it later on my computer for the full experience. Great work!
I never had a C64, but did have a ZX Spectrum, and I have no doubt that it is very much responsible for my interest in programming from a young age, particularly the BASIC prompt being something you had to interact with. I remember getting books of programs out of the library and spending hours typing them in, my mum would help out sometimes haha!
I never had a C64, but did have a ZX Spectrum, and I have no doubt that it is very much responsible for my interest in programming from a young age, particularly the BASIC prompt being something you had to interact with. I remember getting books of programs out of the library and spending hours typing them in, my mum would help out sometimes haha!
Author here - thanks for the nice words about the article!
It's not real C64 BASIC though. POKE and GET didn't work exactly like that. You'd need to know some details about the Commodore kernel's memory map to port the game to a real C64.
I noticed that too, made it hard to know what to think. All that work, and framing it as a "re-enactment" of using a C64, but not getting the code at the core of the lesson right? Weird. Hopefully they will patch it.
Author here - there are better emulators (I used this one myself for testing things out: https://www.retrodevops.com/c64.html).
You are absolutely right that my POKE is not like the real one - because for that, you actually need to emulate quite accurately the C64 memory. So, anything related to POKE is not accurate - and this misses the experience you get as a hacker discovering tricks you can do.
However, my point was more about the interaction that combines text editor and REPL into one - and I think for that, it works well enough.
You are absolutely right that my POKE is not like the real one - because for that, you actually need to emulate quite accurately the C64 memory. So, anything related to POKE is not accurate - and this misses the experience you get as a hacker discovering tricks you can do.
However, my point was more about the interaction that combines text editor and REPL into one - and I think for that, it works well enough.
This is an interesting experiment, but it doesn't work for me (Firefox on Linux). The virtual C64 doesn't respond to my entries, and seems to constantly receive random inputs.
This is very odd! I handle the input myself (so that it can look like C64 console), but this is done via pretty simple "window.onkeypress" and "window.onkeydown" - so if it receives random inputs, it's either odd events or some glitch elsewhere (I'm using Firefox myself, but on Windows). I'm not sure how to debug this - but if you have any insights, let me know!
I'm also using Firefox on Linux and the normal scrolling keys (up/down arrows, spacebar) don't work. Page up/down does work but aren't always the best. the article content is great though!
Did the crying doll program in the Commodore 64 manual work for anyone? Think my friends and I tried it on about a half dozen different C64s (it's what most of my friends had) and never got anything other than perhaps a bit of static out of the tv speaker.
Love C64 basic programming in my childhood.
I would write basic programs with pen and paper in long car rides.
I would write basic programs with pen and paper in long car rides.
Nice but Basic emulation is way too imprecise.
Need some improve but I like a lot this idea: Commdore Basic was far easier to grasp then current ecosystem.
Only Smalltak has similar experience (look at Squeak Smalltak).
I think for most of here our first C64 program looked something like:
10 PRINT "TODD RULES"
20 GOTO 10
10 PRINT "TODD RULES"
20 GOTO 10
Nostalgia is important.
But I wouldn't agree with a statement that things are worse today than they used to be.
JS with something like codepen.io is an excellent zero-install, write-whatever environment kids and adults can both enjoy.
But I wouldn't agree with a statement that things are worse today than they used to be.
JS with something like codepen.io is an excellent zero-install, write-whatever environment kids and adults can both enjoy.
The other great reason so many of us 40-somethings got our start on the BASIC-wielding micros was that our universe was pretty small and the simple things we could make our machines do were still fancy. These days it seems that you won't interest kids with anything short of a 40fps multiplayer battle royale game with millions of polygons on screen. Random number guessing games are lame, Dad.
The early web was a lot like the early micros -- you had to make your own entertainment as you quickly ran out of things to do, and the things you were able to make were comparable to the things built by well-founded teams. The opportunity to add something new and useful to the web is largely past, and any window is even smaller if you're not a venture-backed team.
Old man out. <mic drop>