NEWS, EDITORIALS, REFERENCE

WoC19 Intro to C64 OS (1/2)

This post is part 1 of a two-part follow up to my review of World of Commodore 2019. If you're interested in getting an overview of the show and a taste of what you might get to enjoy first hand if you decide to come to World of Commodore in 2020, then I encourage you to check out that post.

It would have been too long to cover my own presentations from World of Commodore within that general review post. It also didn't seem right to give myself the royal treatment and just a paragraph about other presentations. In this two-part post, instead, I will go into what I presented.

The videos from the show have been uploaded to YouTube and are embedded below. I gave two talks, the first was an Introduction to C64 OS, and the second, which is covered in the second part of this post, was Video Playback with 1541 Ultimate II. Both talks were given with the assistence of a slide presentation for the first half followed by some live demos. The presentations themselves were done from my C64 Luggable with some software that I wrote prior to the show. A few people inquired about that and I'd love to give a brief description of how that works too.

So, let us not delay any further and get right into the juicy details.

Introduction to C64 OS

Technically I had an early demo of C64 OS at World of Commodore in 2018. However, I did not give a presentation. And it really was in very early stages. Even earlier than the show itself. I'd been doing a lot of development that tore into the very heart of the system, and I wasn't able to get things stable in time. So I had to go back to the late summer of 2018 to find a stable build that was worth showing on the floor.

A handful of people who've been following me on Twitter such as MindFlareRetro stopped by my table and sat down for me to give them a run through.

Additionally I gave a small, impromptu presentation of C64 OS at Amiga North in Spring 2019, that was in my hometown of Kingston, Ontario, Canada. Nonetheless, I felt like I wanted to give an official introduction at a larger show, and knowing that the video would eventually end up on YouTube, and so that was World of Commodore 2019.

Briefly, I was a bit nervous. There were a couple of landmines in the software that I was hoping I wasn't going to stumble over. And, I felt as though the reason—why the heck I'm even bothering to do this—should be laid out to give some context to the effort, and to set expectations.

Here's the transcript of my talk, which I deviated from only very slightly when it came time to actually deliver it.

World of Commodore 2019 Presentation

Introduction to C64 OS

UPDATE: January 31, 2020

Hello.

My name is Greg Nacu, and I live in Kingston Ontario.

I'm excited to introduce you to a project I've been working on since the beginning of 2017. The project is an Operating System for the Commodore 64, which I have very aptly named, C64 OS.

I'm going to describe my vision and goals for the project. Then we'll talk about some of the technicals, and the we’ll take a look at a demo of where the project is so far, and see what could be possible.

I love operating systems, as do many computer enthusiasts. I love computer hardware too, but it is the software that brings the hardware alive. And it is an operating system that gives a computer its character, and defines its philosophy.

Some people think the C64 doesn't have an operating system. But this is absolutely not true. The KERNAL and the BASIC ROMs together make up the C64's OS.

The KERNAL has drivers for the keyboard and display, and RS-232 and IEC communications for printers and storage devices. It has logical file abstraction to connect input and output devices together to channel information, and so on.

BASIC is a programming language, but it is also a memory manager and has string and math libraries and other useful routines. BASIC provides a command line interface closely coupled to PETSCII and the KERNAL's full screen editor.

The way it all works feels foreign to us today, but it has a philosophy, which is shared in common by all of Commodore's 8-bit machines.

When I came back to the C64, a little older and hopefully a little wiser, I started studying the KERNAL and BASIC and how the disk operating systems on the various disk drives work, and I gained a much deeper appreciation for the cohesion of the system.

The parts of an 8-bit system are tightly integrated. From PETSCII and Screen Codes to 6502 opcodes, everything is made to work together, with very little abstraction. It's actually quite beautiful.

So, the Commodore 64 has a character and a nature. And we don't ever want to lose that vitality.

In my estimation, there have been two major approaches to OS design on the Commodore 64. And they both have some deep limitations.

The first approach was, let's clone the Mac, but let's do it on the cheap. Okay, this is what GEOS was. It was 1985, the original Macintosh had just been released the previous year. The Mac had a snazzy bitmapped graphical user interface with a mouse and menus and windows and fonts and icons. So that's what GEOS set out to do. The problem is that GEOS is totally unlike the C64. It completely rejects everything about how a Commodore 8-bit machine works. You can’t even copy a GEOS file with a standard C64 file copier. GEOS basically turns the C64 into a slow Mac of 1984. This was okay in 1985, because the C64 did it at a fraction of the price of a Macintosh.

The second approach has been, let's bring Unix to the C64. If you were here this morning, you saw a little taste of this with GeckOS. Let's give it pre-emptive multi-tasking, and let's create a command line shell. These projects are what I call pearls of technical acheivement, but they don't get used for much because of the constraints of the hardware. What Unix does is turns your C64 into an old PC, only slower and with more limitations.

The problem with both of these approaches is that they try to make the C64 be something that it isn't.

What we want to do is build on what was there, give the C64 a more powerful base upon which to write more modern software, but without denying the machine its own fun and quirky nature.

So what is C64 OS? C64 OS extends the KERNAL and BASIC ROMs, it provides additional core capabilities, and it adds a point and click user interface with pull down menus.

In addition to the OS foundations, C64 OS provides an easy-to-use set of applications and utilities that gives you an environment that you can stay within, and manage your computer from within.

The goal is for C64 OS to be an environment that I actually want to use all the time.

Here's what the core OS provides:

• Dynamic memory allocation
• Multi-layer screen compositor
• String, Math and File libraries
• Timers
• Exception handling
• Relocatable drivers
• Runtime module lookup

At a level slightly higher than that:

• Mouse-based UI in text mode
• Graphical UI character set
• Consistent, system-wide menu bar
• Consistent, system-wide Status bar
• System support for text/graphics splitscreen mode
  
  
• Object-oriented widget toolkit
• Advanced mouse and keyboard event system
• Event-driven execution model
• Universal cut, copy and paste

All of these features are designed to make using your C64 easier, faster and more consistent. And it makes writing user-friendly applications for the C64 much easier.

Running C64 OS does not require an REU. But it does require a storage device with support for nested subdirectories. These include any of the CMD devices, any of the SD2IEC devices and/or an IDE64.

C64 OS is written 100% in 6502 assembly, and has been programmed using a Commodore 128 with an REU, and some combination of Turbo Macro Pro, Novatext (which is a text editor that comes with Novaterm) and a handful of machine language monitors. And lots and lots of notes on paper.

Here's what everybody wants to know. But is it multi-tasking?

The short answer is, no, C64 OS is not multi-tasking. But neither is the C64's built-in OS. The list of core features we just went through are helpful and useful without the added complication and overhead of multi-tasking.

The moment you introduce multi-tasking, everything changes. All of a sudden, everything must be relocatable, routines must be reentrant and everything must be written aware that it is sharing resources, all the time. All memory usage, all stack usage, all usage of I/O chips. All disk accesses. Everything has to be, in some way, shared or abstracted. This really detracts from the nature of the C64.

Part of the charm of the C64 is its simplicity, its hackability and its familiarity. C64 OS aims to maintain as much hackability, customizability and modularity as possible. Just as you can find a table in a book like the Complete Commodore Inner Space Anthology, of what all the Zero Page and workspace memory addresses are used for, most of the addresses are still valid, but the C64 OS equivalents to these tables will be published.

C64 OS supports running one utility concurrently with the primary application. Utilities are somewhat like desk accessories from GEOS, but both are usable at the same time and there is greater interaction between them. As well as small relocatable background processes, such as for playing music or running a timer. And also, Timers can be used to interleave timed functions.

The reason you need a storage device with subdirectories is because all components are split into many different files. And these files are named and organized in standard ways across different subdirectories. The idea is for the user to be able to swap components of the OS and its applications without having to reassemble anything from scratch.

Take the boot up process, as an example. As C64 OS boots, it loads components from external resources:

• Boot and Main UI character sets
• Boot screen
• Components
• KERNAL modules
• Toolkit classes
• Utilities
• Settings: system config, mouse, time, toolkit, homebase and memory
  
  
• Loads the input driver
• Loads a Drive detection driver to configure a detected drives table
• Loads an RTC driver to configure the system date and time
  
  
• Launches the homebase application

Every step and every one of these components and more is exposed as a separate file for hacking and customizability.

Every application is composed not of a monolithic binary, but a family of components stored in individual files within that application's directory bundle.

• The application icon
• The credits and copyright file
• The help file
• The system menu definitions file
• The application main binary
• And depending on the application, could have additional files and resources in its bundle.

This design philosophy of resource openess, and the ability for the user to poke around with an application's components is totally dead in the modern computing world of sandboxing and code-signing and encryption and memory protection.

Okay, so now that we know what we're looking at, let's boot up C64 OS.

You now know that a lot is actually going on under the hood of this screen. And the logos and color scheme of this screen, the components and settings loaded are totally customizable.

At startup we are launched into the last homebase application we were in. There are two homebase applications in the works, the App Launcher and the File Manager, these are very aptly named. At this point only the App Launcher is close to completion. The App Launcher lets you customize up to 5 desktops. Each desktop can have a custom background PETSCII image, a hint color and up to 32 aliases.

Double clicking on an alias will open either an application or a utility. Aliases can be dragged around the desktop to group and arrange them as you prefer.

And aliases can have their color set.

But what's really cool is that you can drag a box to select multiple aliases, and you can then drag them at the same time, or change their color en masse. Note also that, you can drag them around while the color picker is still open and floating above them.

Let's take a moment to review the common system UI components.

The color picker is implemented as a utility. So it's a standard component that can be loaded by any application and used concurrently with the application. Utilities and applications are designed to pass loosly coupled messages back and forth.

The top of the screen has the pull down menu bar. The contents of the menus, their textual labels, the actions they invoke in the application and their keyboard shortcuts are all parsed from a menu configuration file on a per app basis. So, without reassembling the app, or even having its source code, you can completely reorganize an application's menus. You can even use this to change the language that appears on the menus.

Menus are hierarchical and have rollovers and organization spacers. Menu items can be assigned keyboard shortcuts that involve modifier key combinations, so COMMODORE+A is different than COMMODORE+SHIFT+A. And so on.

Notice how quickly the menus draw. This is essential to making the system feel speedy.

The leftmost top level menu is a system wide Utilities menu. This menu doesn't come from the application, and is populated with the same items across applications. It is constructed from a common configuration file. This allows you to launch Utilities from within whatever application is running.

Here I've put the Utilities "About C64 OS" and "About This App" at the top of this menu. You can launch "About This App" from within any app, and it gives you contextual information about the app that's currently running.

On the rightmost end of the menu bar is the system clock. Whether the clock is visible or hidden, 12 or 24 hour time, and whether the seconds blink is all customizable. The time is set from an RTC driver, which is relocatable so it can be run at any time to read your RTC hardware and update the time.

And lastly, there is a global keyboard shortcut, also customizable, to toggle visibility of the menu bar.

At the bottom of the screen we have the system wide status bar. It has three modes, Application specific mode. In the case of the App Launcher it gives you feedback about how many aliases are selected and other status messages.

You can click to toggle through disk status and open file modes. In these latter two modes the rightmost end shows the currently available RAM. This is measured in 256-byte pages. A memory page is roughly the same size as a disk block. So there's a correspondence there.

A global keyboard short cut can also be used to toggle the visibility of the status bar.

In addition to the Utilities menu, the menu and status bars can also be used to launch Utilities. Double clicking the time launches the Today Utility.

And double clicking the available memory will launch the Memory Utility.

Now let's launch into an application. I recently put together this Image Gallery, to demonstrate some C64 OS features.

This is a standard splash screen you see while an application is loading. The icon is read from the application bundle, every app has a user customizable icon. Icons can even be cut and paste between different instances of the "About This App" utility.

Now we see the status bar is still here, and the menu bar is still here. But the main body of the menus has been changed. The utilities menu persists, with the same content, allowing us to open a utility above the application. Let's do that, just for fun, I'll open the Calculator.

This demo Image Gallery app has 4 image Galleries built in, of images that I've converted from the web. So let's just go ahead and open the sports car gallery.

Okay, so we get this nice metadata loading in here. That's pretty cool. Filename, type, size, rating, title, source, and notes. We also have some indicators, this is image 1 of 10 in this gallery. We have buttons to switch image. And there is a checkmark on this sports car box over here. There is also a checkmark on the menu item for sports cars. But... where is the image?

Ah ha. Here we see that C64 OS provides system level support for splitscreen mode. When there is image data available, the system allows us to just drag the status bar up, to reveal the graphics mode below.

We can just drag the status bar back down to close splitscreen like this.

Additionally, there is a global keyboard shortcut, which is customizable, to toggle between splitscreen and fullscreen graphics mode.

While in this mode, mouse events are routed appropriately to a different part of the app. So we can do things like click on the left or right sides of the screen to move to the next image.

Even while in fullscreen graphics mode, however, keyboard shortcuts on the menu items are still active, so, with a keyboard shortcut we can change which gallery is open.

And we can use keyboard shortcuts to trigger the menu options to change images like this:

This is a small demonstration of stuff that you can do with very little code in a C64 OS application. This entire Gallery application is remarkably small. Its only about one and a half kilobytes of code. The OS provides the menus, the mouse and keyboard input and event system, the screen compositing, the splitscreen mode, and more streamlined access to the file system. Plus the ability to concurrently run a utility.

C64 OS also provides timers. So in an application like this, we can use timers to schedule changing of images, like a slideshow.

And when we're finished with this application, we can choose Go Home from the menu, to return to the App Launcher.

I have other applications and utilities written for C64 OS and I still have plenty to go. But, I hope this has given you an introduction to what C64 OS is all about. And I hope that it has given you some insight into what might might be possible with it in the future.

Meta analysis

I was a bit nervous. And I was short on time. I'd prepared my talks and timed them down to almost exactly 30 minutes. The problem is that the scheduled block didn't provide any time for setup or take down of equipment. So I got started a few minutes late.

There are some things in the video that I said that aren't in the original script and some things in the script that I forgot to say. That's to be expected of course. There was also some sort of auto-focusing issue with the camera. My apologies about that.

There was also a question/answer period for a few minutes at the end of the presentation that was edited out of the YouTube video. It probably didn't capture well. But, this also took up some time.

Additionally, I think I could have shown that I have other apps and utilities written or partially written. For example, I put a couple of weeks at least into a networked two-player Chess game. The networking component isn't ready, and perhaps this will all make for a fun demo this upcoming year. But, at the very least, I could have shown that the graphics splitscreen mode is not only for static images, but can also consist of interactable graphical UI.

Overall, I felt the presentation was well received.

Look for part 2 of this post coming soon.