Everything about the Commodore 64, or C64 or CBM 64. Some even called him the VIC-64. I got mine in the mid eighties, used from a neighbour – complete with monitor and 1541 disk drive (vintage 1982/1983), and even a needle printer. I later got hold of a C16 Datasette (the dark grey one) which connected to my C64 via an adaptor. I used it until 1992/1993.
The Commodore 128 was marketed as being “three computers in one”. I guess technically they were correct when they made that statement. Although I’m very find of the native 128 mode, the system saw its uses mostly as a games machines in C64 mode. I don’t recall anybody ever looking at CP/M mode longer than half an hour (if that).
There are three ways to put the C128 into C64 mode. Two of which I always knew about, ever since my friend Frank Jagow bought himself a whole C128 system from his paper route money in 1986. But the third option’ve only recently learnt about – after over 30 years of being a C128 fanboy. How exciting!
In this screencast I’ll show you how to write your own INPUT routine in Commodore BASIC. This comes in handy when you want to reject certain keys from being used when asking users for keyboard input. In my example I’m going to allow all alpha characters (A-Z), as well as SPACE, RETURN and the DELETE key.
In this episode I’ll show you how to create the iconic flashing borders on Commodore machines. Back in the day, when the system was loading, this was a nice way to indicate that the computer is busy doing something rather than being dead.
I’ll show you the principle both in BASIC and in Machine Language on the C128. The VIC-II chip is the same on the C64 though, so this will also work on the Commodore 64.
The same approach can be used on the Plus/4, however the addresses for the border and background colours are different (decimal 65305, or hex $FF19).
The VIC-20 is another story, as the border and background colour are changed using the same address (decimal 36879, or hex $900F). This link may help though: http://www.sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=5905
In this episode I’ll explain the concept of Flow Control in Commodore BASIC. It’s kind of a video update of a post I did a while ago.
In essence, it means that we can tell the programme to take a different route in the code depending on a condition that’s met. We’ll explore the IF/THEN and ON… GOTO/GOSUB statements (available on all versions of Commodore BASIC), as well as the expanded IF/THEN/ELSE version (available on the C128 and Plus/4 only).
In addition, I’ll also show you how to use the BEGIN and BEND clauses that were introduced with the C128.
Did you know you can run Commodore BASIC v2 on your Mac and Linux systems as a scripting language? It’s true – thanks to the marvellous efforts of Michael Steil and James Abbatiello. They’ve adapted the original BASIC v2 as featured on the VIC-20 and C64 with additional routines so that it works natively on modern machines. It’s ingenious!
For those who don’t quite know what to do with it, here are some instructions that’ll help you get CBM BASIC up and running on macOS.
GitHub provides a convenient way to either clone a repository on your local machine if you have GitHub for Desktop installed, or you can download a ZIP file and unZIP it somewhere on your system. Once done, you should see a directory structure that looks exactly like the repo on GitHub.
You need a few utilities installed your your Mac to be able to compile files. Downloading Xcode will ptovide you with an excellent (and free) IDE as well as the command line tools needed to do that (gcc, make and several other goodies). You might be able to bring those components in using the Homebrew package manager.
Using your Terminal app, navigate to your unZIPped folder. It includes a MAKEFILE so there’s no need to mess with any parameters. Enter “make” at the command prompt, and after a few moments you should have a file called “cbmbasic” without an extension in the same directory. That’s the binary for your Mac.
To make it executable, we’ll have to tweak the file permissions – otherwise our operating system won’t be able to run it. We’ll do it using the chmod command:
You can test if it works by calling the binary without any parameters like this:
If all goes well you should see something like this:
For easy access, copy the binary over to your /usr/bin directory. That’s where common command line utilities are installed on Mac and Linux systems. The added benefit is that the path to that folder is already in your local $PATH variable, and as such you can simply type “cbmbasic” from any location when you’re on the command line.
Here’s how to copy the binary over (this will ask for your administrator password):
Using Direct Mode
When you run the binary it will bring up something like the standard BASIC command prompt we’re used to seeing on the Commodore 64. There are however a few important differences between a C64 emulator and this implementation:
this is NOT an emulator
cursor keys DO NOT work
all commands typed in must be CAPITALISED
Other than that, you can start typing like on a real machine. Be careful with certain POKE commands though as those may call system routines that might not be implemented.
LOAD and SAVE commands have been tweaked to reference the command line structure. They work just fine, but will load and save files in Commodore file format (which is not clear text ASCII – more on that later). For example:
The above displays the directory of the current folder, much like it was an attached floppy drive. How cool is that? You can reference folders using both LOAD and SAVE just as if you were on the command line.
You can also type in programmes and run them – however the cursor keys won’t work, so there’s no screen editing options. Programmes SAVEd from direct mode cannot be loaded from the command line, only from direct mode (i.e. when launching the binary without parameters).
To quit direct mode, hit CTRL+C.
Running Programmes from the Command Line
The real power of this implementation can be seen when we run files from the command line. Those files must not be SAVEd from direct mode, but instead are simple clear text files. The extension doesn’t matter, but for good practice, let’s store them as .BAS files (much like shell scripts are stored with the.SH extension, or PHP files would be stored with the .PHP extension… you get the idea).
You can write standard BASIC programmes use your favourite text editor (like vi from the command line), or try one from the “test” directory that’s provided with the repository.
Imagine we had a file called “hello.bas” that we’ve created with vi, looking like this:
To run our file, we can simply define it behind the binary like this:
This will greet us with the “Hello World” message on the command line.
Running Script Files
Alternatively, we can specify the full path to cbmbasic at the beginning of a file (she-bang notation) and run it just like any other script file. Observe please:
If the file was called “hello”, we’d need to change the permissions again so that the file can be executed:
Now we can run it like this:
Sweet – but I can’t work out how to compile this on macOS…
Fear not – I’ve got a macOS binary that was compiled on 10.12 “Sierra”. You can find it in my fork of the project. Check out the “binaries” folder.
Does it work on Windows? Or on Linux?
I’ve tested compiling and running this puppy on CentOS 6 and 7 with roaring success. The above steps worked fine for it, so I’m assuming it’ll work on other Linux flavours just as well (the beauty of portable C code).
According to the author, it works fine on Windows too – however I have no idea how to compile source code on Windows, so you’ll have to figure that out for yourself. I hear good things about Visual Studio – if I work out how to do it, I’ll add it to the “binaries” folder on my GitHub Fork.
Can I write my own extensions to BASIC?
Apparently so – check our Michael’s site and repo for details:
Right now, if you run SYS 1 from direct mode first, you can use the SYSTEM command (followed by anything you’d like to execute on the command line in “double quotes”) as well as LOCATE (followed by an x and y coordinate to place the text cursor) and WAIT.
Have fun hacking BASIC and letting it run with the blistering speed of modern CPUs 🙂
In this episode I’m adding statistics support to my previous lottery generator on the Commodore 64.
I’ll add an array that is updated if my supplied numbers have been matched, and how many times over how many draws this has happened. I’ll also add an option to pause the programme and display the statistics before random draws can continue.
When this app is run continuously it will collect statistical data on how many lottery draws are necessary to match all supplied numbers.
PS: By the time the video had uploaded, my emulator had drawn over one million sets, and none of them have matched my numbers 🙁
In this episode I’m amending my previous lottery number generator to take six lucky numbers from the user to match against the randomly drawn numbers from the Commodore 64.
This will allow us to compare what the computer has drawn to the user’s input, as well as keep drawing numbers until the user input comes up. It’ll be an interesting experiment to see how many draws that will take…
In Europe, the brand new C64 Mini has just been released. Although I don’t have one myself, I’ve been following the Indiegogo campaign and have watched several “unboxing reviews” on YouTube. I must admit it’s a neat little machine, and I like the idea of somebody making the Commodore days available to a new generation of users.
However, I can’t stop thinking “what’s the point of this exercise?”
Don’t get me wrong, it’s not that I dislike the idea of Commodore BASIC making a re-appearence, or of new Commodore “herdware” being developed. Quite the opposite in fact.
What I can’t understand is why the hardware needs to be built on an emulator rather than real hardware. Because we HAVE that already, and completely FREE at that. We therefore do not need exotic hardware that’ll quite probably be off the shelf in a matter years.
I feel that it was different with the C64DTV project, with which Jeri Ellswoth reverse engineered the whole system using a new and combined chipset, basically building a new C64 wit modern components.
The Mini on the other hand – at least as far as I know – is a down-stripped Linux box which runs a software emulator. It could emulate anything. I might as well run VICE on my modern (and replaceable when broken) laptop, plug in a USB controller and get the same result. For free.
If a company goes through all the trouble to recreate the C64 with modern components, I feel they should recreate the whole thing rather than something we already have access to. If it’s all about “some output on the screen”, then an emulator output or dedicated hardware output are arguably the same. And I guess that’s what the Mini project is all about: plug-and-play screen output.
But what I’d be more interested in is a fully reproduced piece of hardware, something to which I could solder homebrew stuff on the user port, or something I can plug in real floppy drives. I guess a fully recreated system is what I’m asking for, one that looks AND behaves exactly like the old breadbin. A system that lets me POKE a value and set a line on the cartridge port on high. That sort of thing.
With that in mind, I can’t help but wonder who the target audience of the Mini is. Total geek enthusiasts (like me and thousands of others around the globe) won’t be happy with a compromise. So perhaps it’s newcomers who hadn’t been born when the real Commodore devices were around? I wager that they might not care about pixelated slow and way-too-hard-to-enjoy retro games. Who then is the Mini aimed at?
Full-sized and Hand-held versions
A full-sized authentic recreation, as announced in the original crowdfunding campaign, definitely YES. I’m looking forward to that. Likewise, I can see the appeal of a handheld pocket sized version that plays old-school C64 games. Love both of those ideas. Both of these were annouced in the campaign
But the Mini? I just can’t see the point. If I want to play C64 games like back in the days, I might as well just play them on an emulator, or on authentic nostaliga hardware – with a fully working keyboard all.
Another question I have is, how did it go from these two models to the Mini in the first place? Whose idea was it, and what was the reasoning behind it?
I’m not bemoaning the project, not at all. I just don’t quite understand why we have it, that’s all.
I give Retro Games 10 out of 10 for the idea, and for seeing it through to release. But I can’t understand the concept of the Mini, or why it was produced at all (since it wasn’t part of the original idea behind this campaign). So only 5 out of 10 for that.
I’m interested to see the full size version as well as the handheld version. But I can’t see myself buying a Mini at this point.