NEWS, EDITORIALS, REFERENCE
A few updates first, I'll try to keep these brief.
Update on IP Thief (BASIC RPG/Maze Game)
I've finished: the introduction screen, the game mechanics for movement between the rooms, collecting items in inventory, points, combat against monsters, and changing levels. I've got a "level menu" screen, that you can access with the back arrow key, to let you toggle music on/off, quit the game, restart the level, or restart the game from level 1. I've done the screen that appears at the end of a level to tell you how many points you got out of the possible total for the map. And I've got 4 maps of increasing complexity, with music for each map. I have sent out a .D64 with the game, and a simple text–file "manual," to one person to do some beta testing. I still have to do more maps, not sure how many I'll do, probably 10 at a minimum, but maybe a few more. I have to design these, with the help of my son (the point of all this, after all.) And then I need to do an end sequence. A bit of an end story, or end screen, when you survive through and solve all the maps.
By the way, I'm sad to say that my wife doesn't know what a hypospray from the Original Star Trek series looked like. In case you are too cool to know what one looks like, it looks like this: And so now you have the general gist of what I was trying to go for with my hypospray PETSCII art in the upper right screenshot above! 😄
Update on C64 OS
After giving my demo of the state of C64 OS for Commodore Users Europe (the video on YouTube has now had 11 thousand views! Thank you everyone, that feels pretty good.) I decided to shore up some of the tools that I use. I updated the relocator, so that it shows a nice animation while scanning the file, gives you some statistics about the file, and then instead of just spitting out unused bytes, it figures out what ranges of unused bytes could fit the size of the binary and tells you explicity where you can assemble it to. (More on how the relocation works in the earlier blog post, Drivers and Relocatable 6502 Code.) I updated the backup script to version 3, which now supports full and incremental backups from a storage device with an RTC, (such as CMD HD, FD, RamLink, IDE64 and some SD2IEC devices.) And I also wrote a tool for creating PRG Aliases for the C64 OS "PRG Runner" utility. (More about that in the post, Load and Run from 6502 ASM.)
Dear reader and Commodore 64 enthusiast,
You've come here to read one of my high–quality, long–form, weblog posts. Thank you for your interest, time and input. It would be a lonely world without loyal and friendly readers like you.
I'm creating C64 OS and documenting my progress along the way, to give something to you and contribute to the Commodore community. Please consider purchasing one of the items I am currently offering or making a small donation, to help me continue to bring you updates, in–depth technical discussions and programming reference. Your generous support is greatly appreciated.
Greg Naçu — C64OS.com
Let's begin with a fun update on something I've been working on.
It's summertime, and I wanted my son to have a project. I've tried introducing him to programming, on the C64 in BASIC, but he's a bit young still to really grasp the important concepts. He loves games though; he likes card games like Munchkin and the Star Trek CCG, and he likes board games. We also play some dice games. There is a simplified version of a game called Mexico. You just need four ordinary 6–sided dice. One die each is used as your life counter, and starts at 6. You then roll one die each and compare their results. If they're the same no one takes damage this round, and you go on to the next round by rolling again. Whoever's die has the lower number takes one point of damage, which you track by rotating your life counter die. Whoever gets reduced to zero first loses. It's simple, but it's fun.
One day we decided to use a whiteboard and some markers to flesh out this Mexico–like game with more rules. We just started making the rules ad hoc, and if they weren't power balanced, we tweaked them. The game had weapons, and the ability to defend against attacks, and the ability to regenerate health. And hit points started at 100 (instead of 6). That was really fun! But it only lasted until someone erased the whiteboard, and now I can't remember the details of the rules we came up with.
Based on this, I came up with an idea for a simple game that can be designed on paper, that I would program in BASIC for the C64. My son is involved in making the maps, the level design. And I want to use the project to teach him about the parts that go into a program like this, with a fun and engaging end product. Essentially, there is a grid of rooms. Each room may have a door on any of its four sides that leads to an adjacent room. Like the dungeons in the original Legend of Zelda, only a much simpler implementation. Each room may optionally have one object.
Welcome back Commodore 64 fans and users.
As discussed in the previous weblog post Updates on C64 OS, Beta 0.5, I have been working on a new a piece called, An Afterlife User's Guide to the C64. That guide is finished and online, along with several other updates to the C64os section of the site. I'll link to it and the other recent updates below.
I personally divide the eras of the Commodore 64 into several phases that I refer to by its life cycle. These are only rough divisions, it's not perfect, but it makes things easier to talk about. The early life of the C64 is from its first release in 1982 up to around the time when the C128 and the C64c were released, say, 1986. In this early stage the software is still pretty rough, as the developers hadn't figured out how to make the most of the VIC–II and SID.
The midlife of the C64 runs from around 1986 to maybe 1991. By the end of the midlife of the C64 developers had really mastered the sound and video capabilities of the machine; many games existed that were amazingly fast and smooth with brilliant visual effects. But the C64 was really showing its age relative to other platforms.
The late life of the C64 goes, I would argue, from around 1991 up through the collapse of Commodore themselves in 1994, and into the late 1990s when the SuperCPU was released by Creative Micro Designs. Interestingly, 100% of my time spent with the C64, when I was young, was in its late life and beyond. I missed the entire decade of the 80s because I was too busy being born, and then playing with a VIC–20 when I was quite young. I only acquired my first Commodore 64 in 1991, 30 years ago.
Brief timeline of the eras of the C64
Well, time is ticking along at an extraordinary pace. Ontario, Canada, where I am from is in full lockdown again, now into the start of the second year of COVID-19. Both my kids and my wife are all home, and I have been working from home since around this time, 13 months ago.
But it's not a bad time at all to spend with your C64. The nerd lifestyle of programming your Commodore 64 into the wee hours of the night, holed up under the stairwell in your basement with a cup of coffee and the Programmers' Reference Guide has never been so unaffected by a worldwide pandemic.
This post is basically an update on where I'm at on multiple fronts. By my usual standards, this post is going to be short. But I have an excuse, which we'll talk about first.
Before we get started on the topic of shared libraries, I wanted to draw attention to a recent update to the Commodore 8–Bit Buyer's Guide. For the last couple of months, I've been scouring the web and reaching out to creators and vendors, collecting links, prices and photos of new products that are commercially available for the Commodore 64 and other Commodore 8–bit machines.
I maintain the catalog in a spreadsheet, with product name, supplier, creator, category, price, notes and a URL to where the product can be ordered. I try to find the highest resolution images that I can, and then carefully remove any background so that each image has a consistent matted–on–white appearence. Often the images will have their light and dark, brightness, contrast, and sharpness adjusted to try to give them a consistent look. This is not always possible because the images come from such different sources. When necessary, I do color adjustments around the edges and through transparent areas to make the images look as though they were meant to be on white.
I'm particularly pleased with the results of this image:
It is rather unintuitive just how much that pink background influences the internal contents of this image. The transparent case, the brass screws, the shiny chrome metal, they all show hints of pink that stick out like a sore thumb when you lasso the image, mask it, and matte it on white. The cable itself had to be desaturated, but in context you hardly notice, because your eyes are drawn to the main object, which still shows the colors on the RCA jacks, the blue adjuster, the wires and cable tie.
File Management is considered to be one of the most central parts of an operating system.
In Command Line Interfaces, such as a Unix/Linux or the AmigaDOS Shell, you are in a current working directory. Commands interact with the file system relative to where you are.
In macOS, the Finder is where you find applications, documents, and other files by navigating the file system.
Windows 95, and up to the present day, follows the Macintosh model. The desktop is a folder where you can put other files and folders. And Windows Explorer is the analog of the Macintosh Finder.
Earlier versions of Windows, though, had a Program Manager with icon shortcuts to applications. In addition to this it had a File Manager application for working with files.
For reasons that relate mostly to limited RAM—but also because of the low screen resolution—C64 OS is a bit more like this early Windows model.
Welcome to 2021, let's hope it turns out better than 2020.
In August of last year—which feels literally like yesterday—I published a weblog post about Playing Back PCM Audio on our beloved brown friend, the Commodore 64. I wrote that in response to an email exchange. I thought a blog post made more sense than just replying in an email.
I walked through how to play digital audio on the C64, in theory, and tried to come up with suggestions for how to work with an REU. I recommended supporting GeoRAM as an option because it's still commercially available in a few forms: (GGLabs, Shareware Plus, Garrett's Workshop)
Until recently I didn't know anything about GeoRAM. When I looked into it, I realized that it might be better suited to digital audio playback than a traditional 17xx REU. While working on a forthcoming update to the Commodore 8–Bit Buyer's Guide I was looking for new gear that's appeared on EBay since the last update, and I stumbled upon a new 2MB GeoRAM Clone from a maker called Garrett's Workshop.
It comes in a translucent, injection-mold stubby cart produced by The Future Was 8–Bit, and has a nice professional feel. It was only $45 so I decided to spring for it. It arrived remarkably quickly and I was stoked. Here it is:
What else could I do besides spend a few days implementing what had just been some theorizing from 5 months ago? That turned into GeoRAM Digi. I'm releasing it on GitHub with the MIT License. Use the code, fix it, change it, incorporate it, share it, even sell it, just give me credit for the work I've put into it by keeping the MIT License and copyright information attach to it if you do make use of it.
Okay! Let's dig into this shall we?
A quick update, I am working on Beta 0.5 of C64 OS. Everyone is waiting for the File Manager to be ready. Or, if not ready, at least to have something to see and try.
C64 OS at its heart is a set of reusable resources that are designed to work together. The ideal is that an application is not written from the ground up, but by pulling together resources of the OS. I have designs for the File Manager's UI. I have the main application framework created. You can launch into File Manager. Its menus are created, navigable and some of them already function. But beyond that, there isn't much to see yet.
There are two high–level technologies important to implementing the File Manager:
- The Directory Library and
- The UI Toolkit
The Directory Library is done, tested, working well and in use already in a few places. I will be talking more about the Directory Library in this post, as I explain putting it to use in building a C64 OS Utility.
The UI Toolkit is one of the 10 C64 OS KERNAL modules. It consists of the KERNAL module itself, plus 12 object–oriented user interface classes. It has been a challenge for me to design this system. I had a couple of false starts because I didn't know what I was doing or how to create an extensible object–oriented framework in 6502. But once I worked out how to actually do it, it has been a long slog to get the classes implemented, testing them, working out the bugs, and the math, and figuring out how all the parts fit together. It's been fun and educational, but slower going than I'd hoped.1
I have been doing a lot of dog–fooding. This is an old programmer saying—I think it originated at Microsoft of all places—from "You should eat your own dog food." In other words, if you make something that others are going to use, you should use it too so that you find all of its shortcomings, and find out for yourself just how gross and unpalatable it is.
The Toolkit has taken a lot of dog–fooding to get it to the point where I am happy to program against it. It is supposed to make programming easier and faster, and provide more benefits than headaches. I think I've finally reached that point where the benefits are about to start pouring in. I am pleased to say that most of the Toolkit classes (the ones that will be permanently resident, more on this later in this post) are done and working. And there are just two classes left that I still need to finish before I can say that the entire core OS is complete. That's not bad, considering how much I've put into it so far!
The File Manager is coming. But it is being built by combining together many components and technologies that are part of C64 OS as a whole, and each of those parts is being tested and put to use in a simpler context first. And that's what we're going to look at today.
So let's talk about building a C64 OS Utility, from stem to stern.
- By the way, in case you don't know, I'm doing 100% of the development on a Commodore 128 with a 2MB REU. So, let us just say, when something goes wrong, figuring out how to debug the problem has been a very creative process.
I am writing about a drive technology that was released in 1982, but whose essential origins stretch back into the decade before that, let's call it 40 years old. And I'm writing this just a few nights after watching Apple's 2020 iPhone 12 media event. This year, as every year, this new iPhone is the bestest at everything. The juxtaposition of the modern and the retro has never been more extreme. But, here's the thing, it doesn't matter whether it's 11 billion or 5 billion or 1 billon whatevers, one thing remains the same: you can't get into an iPhone and see how it works.
I used to be the kid who loved this new–fangled thing called home computers, and looked down my nose at my father's friend who drove a restored antique buggy down the back roads. He took me for a ride once. It was slow and deafeningly loud, like hundreds of explosions going off inside a metal box right beneath your head. It was bumpy and rough, and frankly, it stank of gasoline. But now I'm almost 40, and you know what? I get it! I understand now. Sure, he's 70 now, and that's why he was into antique cars not computers. But when a youth of today looks at a Commodore 1541 drive, surely they will not understand why anyone would waste their time.
A 1541 drive weighs several pounds, it heats up like mad as it sucks back electric power, it's loud and is prone to a variety of failures, and yet it only has a maximum throughput of between ~4 to ~25 kilobytes per second. And its storage media are fragile, with sensitive parts open and exposed, 5.25" square, with a maximum capacity of only 170 kilobytes (per side.) The analogy to the antique car is nearly perfect. Why would anyone want to waste their time frigging around with one of these ancient lumbering monstrosities? But it has all become clear to me. You can open a 1541 drive up, you can see its components with your naked eyeballs. You can clean and tune its parts by hand. But best yet, you can study it and learn about it, and actually come to a satisfying level of comprehension about how it works. And that feels fantastic.
Originally I thought I'd pack this into one post. I decided to split it into two so we could get into some details about the power up process both in hardware and software, and then have room in this post to get into the details about how to deal with the variations and complexities—that have crept in over the years—for what was once a simple task, loading and running a program on a C64.
If you've just stumbled upon this post, I encourage you to read part 1, Load and Run from 6502 ASM (1/3), first. Here's a very brief summary of what was covered in part 1:
It used to be very straightforward to load and run a program on a C64. Most users had only one disk drive, on device 8, which was the drive's default. The load instruction was one command that would frequently appear on the disk label itself or in the first page of the software package's manual. Early software, i.e. most software, came to rely on being booted from device 8, even as users purchased and hooked up additional and more sophisticated storage devices.
C64 programs assume they own the whole machine, and often depend on the machine being configured as it would be following a fresh power on. When the machine is powered up it goes through an initial reset cycle, which runs 4 standard KERNAL routines before passing control over to BASIC. From BASIC there are several ways that a program can be started, depending on how it was written and whether the machine has a stock or third party KERNAL ROM like JiffyDOS. The sad fact is that there is no one single reliable command that will guarantee the program will be started correctly.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.