NEWS, EDITORIALS, REFERENCE
Hello folks and welcome back to another blog post on C64 OS. I've got so much to talk about, and no time to talk about it.
How about the elephant in the room first? It's May of 2022, and I haven't made a blog post since December of 2021. What's more, I said the next blog posted would be the follow-up part 3 of my exposé of VIC-II timing for an FLI routine I disected, commented and figured out from Codebase64. But this blog post is not that post. Has C64 OS development stalled? What happened, where am I at? Why the silence?
The good news is that, it's basically all good news! I have been developing like a cross over between a cave troll and a 6502 code producing machine, that's powered by coffee beans. And whenever I'm not coding, I've been discussing things with my beta testers, designing a new logo, overhauling the /c64os/ subsite of c64os.com, and writing the online version of the C64 OS User's Guide. The only bad news is, I simply haven't had time to write the lengthy and detailed blog posts that I like to write. What's more, the last blog post I was working on, that is only maybe 25% written, is a long, detailed, technical piece that requires a lot of work. And every time I sat down to think about working on it, I realized that I've got a mountain of work in front of me to get C64 OS ready...
So this blog post—I don't know how long it'll end up being—is here to give you an update on all the stuff I've been working on, to make some announcements and to show off some things that are coming.
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
I wrote the first two posts in a 3-part series about the VIC-II and FLI Timing (Part I and Part II,) but I have a lot to say about things I'm working on presently, and I don't want to miss the moment to talk about them while they're fresh in my mind. We'll return to Part III of the VIC-II and FLI Timing after this.
In mid-2019 I wrote a post called Webservices: HTML and Image Conversion. I have since revisited the image conversion part in the post, Image Search and Conversion Service, but have not yet returned to the idea of a simple marked-text format, which I refer to as MText.
In the meantime, I have implemented the Toolkit classes that are always memory resident:
Plus several more that are runtime loadable, relocated in memory and dynamically linked to their superclass:
All these classes and the whole Toolkit system are now quite mature—many bugs have been found and squashed, and several optimizations have been made—and are in productive use in the File Manager and across numerous Utilities.
Most recently I have been tackling the TKText class. It is for displaying (but not editing) multi-line text. It has numerous features that we'll get into in some detail in this post.
I stumbled upon a Stack Overflow question about how to optimize for making text selections in a custom text rendering view. The consensus opinion is that implementing a custom text rendering class is "obscenely difficult." That's why operating systems provide classes to do that work for you. And that's what TKText is all about.
The reason for an OS to provide a class is twofold:
First, so you don't have to do the technical heavy lifting yourself. You can just instantiate the class, call some of its methods and—BOOM—your application has rich text handling.
Second, text handling is tricky and nuanced. If every application implemented its own solution, the quality of the experience would vary substantially between applications. (Just as it does between two Commodore 64 programs chosen at random.)
By providing a class that handles it for you, lazy programmers (lazy-good, not lazy-bad) will rely on the provided class and the users benefit from a more consistent experience. Now let's get into what TKText provides and some of the difficulties implementing it.
This post is part 2 of a 3 part series. If you haven't read Part 1: Memory Access yet, I'd recommend starting there first.
I like to start with a few updates on the progress of C64 OS. If you're not interested in the updates, you can skip to the the main topic.
Update on C64 OS
TKInput Class, File Lock Library, and File Info Utility
I've recently finished the TKInput class, which is a single line text input field. It supports most of what a modern text field supports. Selections, cut/copy and paste to and from the clipboard. Content length constraints, blur, focus and character insert events, ability to filter or substitute typed or pasted characters. Good keyboard controls. I've also recently finished the File Info Utility, which makes use of the TKInput class for editing a file's name.
C64 OS applications use a standard pointer to a file reference for the currently open or selected file. The system's status bar has a mode that automatically renders this file reference. Now, the File Info Utility also taps into this file reference and allows you to rename the file, back it up, or see its metadata such as size on disk, its last modified date/time, and its file type.
Any application that uses the standard open file reference automatically integrates with and benefits from the features provided by the File Info Utility.
The directory library in C64 OS now has the ability to optionally read in the date-time stamps on files from CMD devs, SD2IEC and IDE64. And the date/time is now shown in the File Info Utility. #c64 pic.twitter.com/E7hADKBhAr— Gregorio Naçu (@gregnacu) October 20, 2021
The File Info Utility also lets you lock or unlock the file, by making use of a new File Lock library (flock.lib). The File Lock library toggles the lock bit on any file specified by a C64 OS file reference. The library supports the 1541, 1571, 1581, IDE64, CMD HD, FD and RamLink. The only devices not supported are SD2IEC, (because they don't support file locking.)
The File Info Utility can be used in any application. For example, in C64 OS's App Launcher, the selected alias can be edited with the File Info Utility. Locking an alias prevents the alias from being deleted from one of App Launcher's desktops. Very cool.File Rename
The File Info Utility's main purpose is to rename files. It uses the TKInput class which gives full support for selections and the clipboard, so you can copy and paste to edit filenames.
If the new filename is taken, a disk error is generated. The error gets rendered in the status bar and the original filename is restored. An alert is generated (which blinks the border) to notify you of the error. You can also use C=+Z to revert the filename field to the current name of the file, undoing any edits you have made.
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.)
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?
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.