NEWS, EDITORIALS, REFERENCE

Updates on C64 OS, Beta 0.5

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.

Lots of people don't know how to use their C64.

As some people may know I've been running a C64 OS private beta program for just over a year now and I'll talk more about how that's going shortly. Partly from my feedback from beta testers, as well as my general engagement with retro computer folk on Twitter, something has come to my attention that I feel the need to address.

To put things in context, I used a C64/128 as my primary computing platform, for everything from games and entertainment, to school work, to email, online chat and webbrowsing (by means of BBSes and a dialup shell acount) from around age 9 to around age 20. By halfway through my 20s I had transitioned into being a professional software developer and a fulltime Mac user. I was then away from the C64 almost entirely for about 8 years, but have been back for 5 or 6. And I've learned more about my C64 in the last 5 years than in the entire stretch of time from my childhood up until the start of my hiatus.

In order to come back, to return to being productive using my C64, I had to put in a lot of effort. Reading manuals, talking to people on IRC, trying lots of things without success. The truth is, compared to how a modern computer works the C64 is quite different. The interaction model is different, the keyboard is different, the ports are different, the file system standards are different. And even if you're into command lines, the DOS commands are different. It's a completely different, but parallel, world. It can be exciting to dig in and explore, but it can also be daunting.

Information about how to use a C64 is strewn across 4 decades of manuals, books, magazine articles, blog posts and accrued personal experience from tradeshows and user group meetings. The problem is, many of those manuals, books and magazines are no longer at people's fingertips, but are instead archived away in remote corners of the internet. Blog posts are useful when you stumble upon them, but you're just as often thrown waist-deep into something too technical for your current level. And all that accrued personal experience can slip from memory if you—like me—took nearly a decade away from the machine.

What has come to my attention, then, is that a lot of people who are interested in the C64, who have had past experience with it and who perhaps have a nostalgic yearning to return, find themselves in the position of not actually knowing much about the machine. Not everyone out there who likes the C64 is crazy enough spend a few thousand hours over a couple of years to relearn how everything works. But because there are some people out there who are highly technically knowledgable, (building 6502 clones on FPGA, releasing new commercial games, creating wifi modems, and designing test harnesses and on and on,) the knowledge-level of the average person can be obscured. Here are some examples I've encountered that have brought this issue to my attention:

• What is the point of the User Port? Wouldn't the machine be better off without it?
• What is the difference between an SD2IEC and a 1541 Ultimate? I already have a 1541U.
• What is a partition, in the context of a C64?
• I don't have a text editor, how do I create a text file on my C64?
• I don't know why, but these filenames all look like strange graphic symbols.
• Why is a disk drive device #8, if it's the only drive hooked up?
• Why doesn't the machine say I have 512KB free when I plug in a 512K REU?

These and many more like them are all questions that I have gotten, some of them multiple times from different people. These are simple usability questions that indicate to me that many people who are interested in the C64 lack a general knowledge of its basic or essential features.

In order to address this problem I've been working on a piece with the tentative title:

An Afterlife User's Guide to the C64.

That piece is currently sitting at 14,000 words, which explains why it ate up my blogging time budget this month. Here's the general idea of what topics it covers:

• What is the Commodore 64?
• A Brief Overview of the Ports
• The Commodore 64 Keyboard
• The User Interface of a Commodore 64
• The BASIC Environment
• Devices and Channels
• Routing and Redirecting Data
• Storage Devices
• Reading and Writing data files
• File Management
• Extended File Management
• ...

That's where I'm up to so far, and I have a few more sections to go, to cover expanded memory, networking and the introduction of alternative operating systems.

It's written to be an easily readable introductory guide, with examples you can try. It doesn't get too deep into the weeds on any topic, but goes all the way from how to power the machine on to how to navigate directories and partitions on a hard drive, all in one place, and written from the perspective of someone who knows how to use a modern computer.

Here's the thing though. I'm not going to release it to the "weblog" section of c64os.com (a post of which you are currently reading.) It will be part of the documentation series and C64 OS User's Guide itself, which is in another section of c64os.com, and is more wiki-style than the weblog is.

I'll say a bit more about this at the end of this post.

C64 OS Beta 0.5

C64 OS Beta 0.5 (the 5th beta) has gone out to my group of private beta testers. Thank you again to those fine folk who have helped me test out C64 OS, and submitted bug reports and worked with me to fix those problems and test more.

The main new feature in Beta 0.5 is the nearly complete File Manager application, which, along with App Launcher, is one of the two main tentpole homebase applications. The File Manager provides 4 tabs, each tab remembers its place and its state, and each tab can be at a unique place. A place is a path on a partition of a storage device. Each list of files is presented by the object-oriented Toolkit TKTable class, with proportional scroll bars for vertical and horizontal scrolling, multiple resizable columns whose headers can be clicked to sort in either direction by that column's data. File system navigation and file selection via menus, optional info bars as well as extensive support for keyboard controls, is all implemented and working.

The File Manager's functionality is backended on a relocatable, shared library system in C64 OS, making use of numerous OS-provided libraries. The device detection, directory and path libraries support a wide variety of storage devices: CBM 1541, 1571 and 1581, CMD FD, HD and RamLink, SD2IEC and IDE64. Partitions and directories are fully supported across all these devices types. The File Manager can be used to launch C64 OS applications and utilities, and to open files that open in C64 OS applications and utilities.

The File Manager sets up the job structures for recursively copying, moving and scratching multiple files and directories, and then opens a corresponding Utility to perform that function. These supporting Utilities haven't been implemented yet and are therefore not part of Beta 0.5. But the code to invoke them is done and working, so the File Manager proper is very near completion.

What's left to do?

The remaining tasks before a v1 release of C64 OS is possible include: TKInput class, and TKText class. These are Toolkit classes for single line text input, and multi-line text output. For the TKInput class I'm working on rich mouse and keyboard controls for text selection, for cut, copy and paste, as well as events for filtering the content and interacting with the control. For the TKText class, I'm working on realtime text reflowing, and text selections for copying content. All these features will be automatically inherited by any C64 OS Application or Utility that embeds UI objects of these standard classes.

Several Utilities need still to be written to flesh out the complete cycle of usablity. These include the Move, Copy and Scratch utilities the File Manager invokes. As well as the File Utility used for renaming and viewing other information about a single file. All of these Utilities will be invokable and usable by other applications to perform common tasks.

The File Open and File Save Utilities are also critical and still need to be written. These will really kick open the doors, allowing a simple application with relatively basic functionality to be able to access the full file system to open or save its data files.

There are a number of useful Utilities that have already been thoughtout and designed that will follow these. But I'm not sure, yet, perhaps the v1 release should go out before these are finished. And then these extra Utilities can be released as Freeware additions to C64 OS v1, and then be packaged into future versions too. The only reason to release them after is to get v1 out the door instead of always waiting on another useful idea to be implemented. Some of these additional Utilities include:

• Help (a viewer of an Application's included help files)
• Time (a timer, stopwatch and clock, with a section for configuring the RTC driver and system date/time settings)
• Today (this already exists, but extending it to support creating and viewing events)
• Mouse (a user interface for configuring mouse settings and setting mouse driver)
• Date (a date picker utility that can be used by any application that needs to acquire a date)
• Clipboard (an interface to view the data type and content of the current clipboard, and add multiple clipboard support)

I have ideas for 14 or 15 more Utilities, but I have definitively scheduled these to not be included in v1. They will likely become new features released in some future C64 OS version.

Quirks of the IDE64

One area that seems to have required the most beta testing feedback is supporting the IDE64. It is fairly compatible with C64 standards. But it's also got a bunch of quirks that need special attention.

I don't have time to go into the full details here, but I thought it would fun to mention some of the issues we've overcome in supporting it.

Partition directory

The IDE64 supports multiple partitions, just as the SD2IEC and CMD devices do. All three support filtering the partition directory by partition name pattern matching, but only CMD devices support filtering by partition type. SD2IEC and IDE64 therefore skip this part of the command.

CMD devices support partition types of NAT for native, and 41, 71 and 81 for emulation mode partitions. SD2IEC lists ordinary FAT partitions as "NAT" which matches CMD devices. Also, if you mount a disk image on SD2IEC, the mounted image takes over just that one partition, and that partition's type changes to 41, 71 or 81 depending on if it's a D64, D71 or D81 image, which match the emulation partitions on CMD devices. The IDE64, though, reports its native partitions as type CFS.

IDE64 includes a special "*" before the partition type code. Normally a "*" in a directory indicates that a file is currently opened or was improperly closed, in this case it represents the IDE64's default boot partition.

On SD2IEC and CMD devices, the partition directory simply ends with the last listed partition. Unlike regular directories that end with the blocks free line. IDE64, though, ends its partition directory with a status line about partition count. That needed to be handled.

File types

On all other device types files have one of a very limited set of file types. These are: PRG, SEQ, USR, REL, DEL and DIR. File types are not data types, of which there are essentially an unlimited number. But to express data types a standard C64 filename can include an extension. There is no reason why a C64 filename couldn't be "my homework.txt" (the plaintext data type) and also be of file type SEQ. But for some reason IDE64 conflates the concepts of file type and data type and allows the file type code to be basically anything.

This makes things kinda difficult. But it also seems like they may regret having introduced that, and are now shying away from it. I've decided not to put too much effort into supporting this fully in C64 OS. Unrecognized file types no longer cause the directory library to interpret them as subdirectories, but classifies them instead as SEQ files. There are still some bugs in there though.

Accommodating long file sizes

Another interesting quirk was discovered. In the directory data, the filesize is returned as two bytes, a 16-bit size, which BASIC converts to a decimal number. The problem is that a 16-bit int converted to decimal number varies in length from 1 to 5 characters (9, 99, 999, 9999, up to 65535). Those are the breakpoints. On all devices the number of spaces between the 16-bit filesize and the filename varies depending on the decimal number's length. It's easy to see why, because whether a filesize is 5 blocks or 15 blocks, or 105 blocks, they wanted the filenames in the directory to line up.

Unfortunately, on CMD and SD2IEC devices, if the filesize is 4 or 5 digits, the filename for that entry is pushed rightward out of alignment with the others. It's not a huge deal, as most single files on a C64 are not that big, and on a 1541 no filesize could be more than 3 digits. Interestingly, there is room for a 4-digit number to not push the files out of alignment, but only if there are zero spaces between the 16-bit filesize and the first quote of the filename. On CMD and SD2IEC devices, there is always at least one space, but not on IDE64. IDE64 has allowed the number of spaces to fall to zero to accommodate a 4-digit filesize without misaligning that filename. It's a nice touch, but it's also a quirk that has to be handled, because it is different from all the other device types.

Measuring usage

Here's another little difference: On a CMD device that uses 256-byte blocks, that's 65,535 blocks * 256 bytes per block, for a maximum partition size of 16 megabytes. A file can also be up to 16MB, if it fills a 16MB Native partition. CBM devices have always listed the number of blocks free on a disk at the end of the directory listing. That's useful, because, you really want to now if you've got 100 blocks free, or 10 or only 1 free, that makes a big difference. Things get more complicated on SD2IEC and on IDE64 because their partition sizes can be larger than 16MB, but BASIC can only handle 16-bit numbers.

SD2IEC handles this in a way that doesn't break anything, but it's not quite accurate. It says Blocks Free, but it is actually reporting FAT clusters free and a cluster can be larger than a 256-byte block. However, even with the larger cluster sizes, an SD card can easily have a total size much larger than can be shown in a 16-bit number. For example, if the clusters are 1K, then 65,535 clusters is still just 64MB, while in fact the partition could be gigabytes in size. If the number of free clusters exceeds 65,535, SD2IEC just says: 65535 Blocks Free. That number will only change when you finally drop below that many free. In other words, on SD2IEC, 65535 means "greater than or equal to" 65535 Blocks Free.

IDE64 takes a different approach. Its block sizes are 512 bytes, with 3-byte pointers, allowing for a partition size up to 8GB. (256 * 256 * 256 = 16,777,216 * 512 = 8GB) Rather than list the blocks free, IDE64 lists the blocks used. I'm not sure how helpful that is, as BASIC's maximum number will show up to 32MB only. After that, I don't know what happens. In C64 OS, though, the File Manager now displays blocks "Used" if the device is an IDE64.

Introductory/Tutorial Videos of C64 OS

I like to blog, because I like the medium of the written word. I find that I can organize my thoughts much better in sentences and paragraphs, which can be accompanied by tables and pictures and other visual aids. But occasionally I'll capture a quick video of something I'm working on. Those videos often get sent off to Twitter, but Twitter is kind of a weird medium. It isn't designed to surface interesting old things, but to keep you up to date on what is happening right now or perhaps within the past couple of days. It's much more of a news medium than something like a blog. A blog can provide news, but long-form blog posts also stay online for years, get indexed by search engines, and serve as useful tutorials regardless of when they were first published.

I upload some of my quick videos to Vimeo. But I only use a free account, which offers a small capacity of just 5GB, and weekly upload limits of 500MB. Usually I use the Vimeo player to embed a relevant video into a new blog post. Eventually, when I run out of space on my free account, I move the oldest couple of videos to long term storage on Amazon S3, and update those Vimeo embed links to be a standard HTML5 video tag backending on the S3 file. This makes the videos a little less compatible with some web browsers, and it's also more expensive because I have to pay for S3 bandwidth. But because that's only on older blog posts, the traffic is lower. So that's how I roll, and it seems to work out okay. In other words, I don't use Vimeo as a way to get my stuff noticed. I use Vimeo because they take the brunt of the cost of the traffic to a new blog post. As the post gets older, and traffic gets lower, I move the old stuff to the more expensive medium to make room for more new stuff on the free medium. Thanks Vimeo!

It has been brought to my attention that I should be taking advantage of YouTube. YouTube is an interesting hybrid platform. It's kind of a social network, people subscribe to (aka follow) channels, and can leave comments on videos. But it's also a kind of video-specific search engine. And it's also a recommendation engine to feed you more content you're likely to enjoy based on what you've watched before and who you're subscribed to. But then it's a bit like a blog too, because YouTube doesn't shy away from feeding you up videos that are years old. A lot of video content retains its value despite not being brand new. Especially because YouTube videos can be hours long, in the form of lectures, debates, interviews and tutorials. So content length is another way that it's like a blog, and hence the word vlog. The other important point is that millions of people use YouTube every day.

Unfortunately, I'm not that great at speaking. I can deliver a prepared speech or presentation okay, but when I'm forced to verbalize on-the-fly how something technical works, I tend to get tripped up. With the written word, you can write a bunch of stuff, and then read it. And if it doesn't make sense you can just keep changing it until it does make sense. That's a lot harder with video. So, frankly, I would never dream of giving up the long-form, 10,000+ word, blog posts, in favor of video that tries to convey the same information.

But there are some things that videos can be really useful for. So I've decided to make a series of Introductory/Tutorial videos about C64 OS and about how to use some of its features. Each video will be short, 2 to 5 minutes max, and show me sitting in front of my C64 and showing you how to use C64 OS. I recorded a few samples and sent them out to friends to give me feedback. Step one, I need a better microphone, because clear audio really makes a difference for the listener. I set up a stable camera stand, with bright lighting at a distraction-free workstation. Step two, I'm going to simultaneously record myself in front of my Ultimate 64, and also screen capture the Ultimate 64's digital video stream to an iMac. In post, I can cut to the digital screen capture to present a much clearer view of what's going on on the C64.

One other tip I learned. When talking to the camera, you should always look into the lens. That way, you end up looking like you're making eye contact with the viewer. This is all new to me! But I've ordered a half-decent lavalier (aka lapel) mic and it's on the way.

Here is a short list of a few topics I'll cover in videos.

• App Launcher: Customize your desktop
• Peek: Getting a little glimpse into memory
• The Menu Bar: System features of the menu bar
• App Launcher: Changing alias colors and the hint color
• Splitscreen Mode: Active bitmap UI in the other screen half
• C64 OS Configuration: Configurable options
• Utilities: Helpful small applications that can be run with the main application
• The Status Bar: A system wide feature
• The Menu Bar: Application features of the menu bar
• App Launcher: Multiple desktops
• And so on...

So that'll be kinda fun! It's a change for me. And that'll help me spread the word about C64 OS via YouTube.

C64 OS User's Guide and Programming Documentation

Lastly, I mentioned earlier that the piece I've been working on this month, An Afterlife User's Guide to the C64, has eaten up a good deal of my blogging budget for this month. I do have a fulltime job, and a family (who are stuck at home on lockdown, no less,) so my time has to be split between real life and the C64. The time I have for the C64 I prefer to spend programming and reading/learning whatever I need to know to help with that programming.

Putting together a Beta, for example, takes time. I first have to get everything stable. So I spend time just hammering out bugs without adding new features, because new features inevitably introduce new bugs. Then I have to change the default configuration to something suitable for other users, and then run the archiver to create the installation archive. Then I test out the installer and usually update the configuration program. I test running through the install process to make sure the testers aren't going to hit immediate snags. Then I have to document everything: what's new, what's changed, bugs/issues fixed, and known issues. Plus I usually put together some a short tutorial about how to use any major new stuff. Then come the inevitable bug reports and a bunch of back and forth ensues, with patches and tests to figure out what's happening and how to fix that. So beta release time takes a chunk of time away from just straight up development time.

I really enjoy blogging, I enjoy explaining how things work, and what I've learned. I like to tell people about things I've discovered, and the topic of the next blog post is usually driven by what I'm most excited about having just learned. (The next blog post will probably be about FLI graphics, and how the VIC interacts with RAM. That's my new frontier of learning, and it should be relevant to the general C64 user, not just people interested in an alternative OS like C64 OS. I'm really excited for this one!)

However, I have to start spending time working on the User's Guide and Programming Documentation of C64 OS. And, like the Afterlife User's Guide, working on those other sections is going to come at the expense of blog posts. But, that's okay. I've put out over 110 blog posts, totally over 600,000 words. And more will surely come, but I need to relieve some of my own stress about worrying about putting out blog posts on schedule, so that I can spend that time on the equally (or perhaps more) important work of writing the C64 OS User's Guide and Programmer's Guide.

Final Thoughts

So thank you all, and stay tuned. In the meantime, go spend time with your C64! Or, if you've got a family then I should be encouraging you to spend time with them. But if you can get away with it, do both at the same time. 😀