NEWS, EDITORIALS, REFERENCE
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.
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
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.
I'd originally planned this discussion to be a single post. But it turns out there was a lot to talk about, so I've split it into two parts. This is the first part which talks about what technically goes on when the computer is powered up or restarted, and how programs get loaded into memory and run. The second part, discusses exactly what the difficulties have become with loading C64 software on modern conglomerates of hardware, and how similar problems have been addressed on other platforms. Part 2 will then get into the programming details of how to solve this problem on the C64.
When the Commodore 64 first came out there were two common storage devices that people would get along with it. If you were in Britain or certain parts of Europe you probably had a Datasette which could store and retrieve data from standard compact cassette tapes, the kind usually used for audio. If you were in North America, or some other parts of Europe, you likely had a 1541 floppy disk drive.
Most commercial software came packaged in one of these two formats. For me, personally, the cassette–based Datasette fell out of use after the Commodore VIC–20. Although the C64 has a cassette port on the back, and the original KERNAL ROM still supports loading software from cassette, loading from disk is superior in almost every way. Disks are thinner and lighter, they have a higher storage capacity, have a faster load time and allow for random access to read and write data. With the ability for random access, a disk drive also allows you to load and list a directory of the disk's contents. You can then load a program by its name and the directory tells the drive's DOS precisely where on the disk to find the first block of that file's chain of data.
There were some advantages to loading from tape. Many games used special tape loader software that could display a beautiful splash screen while the game was loading in, this generally was not the case with disk–based games.
Today, of course, there is still the nostalgia factor for cassettes, if that's what you grew up with. But that's all I'll say about tapes. They were popular in parts of the world, but I don't have much nostalgia for them personally as they were never a part of my experience with the Commodore 64.
Using a C64 Program
If you're used to a modern Mac or PC, the first run experience of using a C64 can seem utterly baffling. You have to learn and remember a bunch of arcane commands??! It wasn't ever quite that bad. Here were the steps you would typically go through to use a program on a Commodore 64:
Terry Raymond is an old school North American, Expo–going Commodore 64 fan. Throughout the years he has asked me and others to give him helpful tips on how to program his C64. He has been interested in what it would take to make a Wave audio player, particularly for GEOS or Wheels. A valiant goal, in my personal opinion. And a fun project.
The problem is that, to really do justice to the questions, I feel like I'd have to write a rather long response. I wouldn't want to do that in an email, because the time spent would not benefit anyone other than the sole recipient of the email. Instead, I've decided that this is a great opportunity to turn the dialog of the email, with my long–form responses, into a blog post. I do love the topic of digital audio, after all. This seems as good a time as any to talk about it.
Hey back in 2008 I had wanted to code something in GEOS possibly to play Riff 8-bit Mono wave files, well later in 2009 I contacted Werner Weicht he said to do this would need Wheels since it can handle its memory better, since it requires some sort of memory expansion to boot.
Yes, I remember that you were interested in making a Riff/Wave player for GEOS or Wheels. Digital audio requires a lot of data for only a little playback, and an OS is going to use a bunch of main memory. So, I agree that you would be best off targeting a platform that either requires an REU or that provides some extra REU support.
Well Werner helped me enough to have a barely working app:
WavePlay 128 40/80 column support
Every so often I like to really get into the weeds on some 6502 programming. I have recently been working with the C64 OS directory library that I wrote, as I work on the File Manager homebase application.
The directory library is assembled in two versions, a low memory and a high memory version. These can be dynamically linked into your C64 OS programs. The low memory one is designed to fit into an application binary's memory space, directly following the standard application jump table. The high memory version fits into the memory space of a utility, right after its standard jump table. Since the first code in the directory library is its own jump table, this means that your app or utility's standard jump table is extended to include the directory library's calls.
The directory library is not part of the KERNAL because it takes up at least a couple of pages of code, and only those applications and or utilities that need to work with directories will make use of it.
Welcome back one and all. I hope things are going well for everyone. This post is going to be a shorter talk about IDE64 and what it took to get it supported by C64 OS. I've classified this as a software post, and then I've gone ahead and made the icon a picture of a piece of hardware. At some point the hardware and how it works becomes a software issue. I'm going to talk briefly about the IDE64 and what I've learned about how it works, before getting into the changes I made in C64 OS.
Before we get started I'd like to thank everyone who purchased a Versa64Cart that I had available on this site. Your support is very much appreciated. I have now sold out of the stock that I brought in and put together as part of my experiment in how one can go from online open–source hardware to actually having the product in your hands. I wrote about the process in the post Versa64Cart and C64 ROMs. I learned a lot and some of the things I learned are even relevant for this post and how IDE64 works. It was also a lot of fun, and I got a Versa64Cart into the hands of a bunch of people who wanted one.
I still have Commodore Logo Patches available, if you're looking to support my work here. And I have some work to do on updating the manual and assembly instructions for the Promenade C1 clone, the Promenade Model D. But soon I'll have those available here as kits for purchase.
Now let's talk IDE64!
A quick update on myself and situation. My schedule has become a bit tighter. In addition to working from home and watching my kids through the day, there has also been a recent medical crisis. A close member of my extended family was rushed to the hospital for an emergency heart surgery. She survived and is slowly recovering, but full recovery is going to take a long time. It's been stressful, especially for my wife and extended family. During this writing I also got some bad news about the sad passing of a friend and fellow software developer.
In memory of Christopher Roy. -2020
I'm plowing ahead with developing C64 OS. And I don't want to slow down the pace of putting out blog posts and updates, but I may not be able to put out 10,000+ word deep dives as frequently as I have before. I'll just play it by ear, and maybe put out some shorter posts for a while, until things settle down a bit.
This post is about the Toolkit class hierarchy. This is probably what the finalized v1.0 will release with. Although there is always some chance that it will change. In this post we'll also look at how some of the classes are structured and how they work. A previous post discusses how Object Orientation in 6502 (take 2) works, but doesn't discuss how the toolkit classes make use of those OO–techniques.
No time to waste, so let's just dig right in.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.