NEWS, EDITORIALS, REFERENCE
Welcome back dear readers. Let me start with some quick updates. I didn't put out a post in August, and I hate missing my deadlines. I took a week off in August to go off grid and spend some time with my family at a cottage. Rather than having a couple of smaller posts, I spent a lot of time working on a rather large reference document, the SD2IEC User's Manual. I worked on it for about 6 weeks, but just didn't have enough time to finish before the end of August. I posted the it to the blog on September 3, 2019. It's a doozy of a post. The original sd2iec github readme (upon which it is loosely based) was no slouch at 7,000 words. But at 28,000 words the SD2IEC User's Manual is 4X the size. I drew on the CMD HD User's Manual for inspiration in the syntax and BASIC and JiffyDOS examples. And I added a lot of descriptive content that was simply not present in the original. It is my hope that my work will become the go–to reference document for all SD2IEC users out there. Please link to the document and tell people about its existence.
It may seem odd that I post full user manuals to what is ostensibly a blog. However, I mentioned a couple of posts ago that I've introduced a new layout for navigating and finding the blog posts. The new View By Categories organizes the posts into categories based on how they've been tagged. This allows me, for example, to pull all the "Reference" documentation posts out and collect them together. The SD2IEC User's Manual can be found there now, side by side with other reference documentation posts, such as: C64 KERNAL ROM: Making Sense, the 6502/6510 Instruction Set, Commodore Hardware Information and reference tables for PETSCII, Screen Codes and key mappings.
Shortly after tweeting about the new SD2IEC user manual, Jérémie Marsin of Double–Sided Games recommended that to improve site SEO and general usability I should consider making the URLs of c64os.com friendly. Up until this point, posts have been referenced by their ID in a GET variable. Other parts of the site, the Buyer's Guide, C64 Luggable, and C64 OS documentation also exposed GET variables to access their subpages. I have plunged into Apache's MOD_REWRITE and manually updated a number of hardcoded links. The whole site now has more human readable and user friendly URLs. (The old urls, of course, continue to work. So any external links to my site won't break.)
In C64 OS news, I have recently got split screen mode actually working! Something I started talking about earlier this year. I've got it on my short list to write an in–depth technical post about what I learned and what I had to do to make a stable raster interupt that can be moved arbitrarily by dragging the status bar with the mouse. Look forward to reading about that.
I have also completed the work on getting the system–wide Utilities menu working. I had some original plans for how to implement it, thinking I didn't want to waste much memory. But I ended up with a solution that actually resulted in decreasing the memory footprint of the menu system in the process of adding support for the utilities menu. I've got another post planned to go into some detail on how this worked out. It's pretty cool.
And now on to the topic of today's post, C64 OS Networking and Chess.
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
There are many SD–Card–based storage solutions for Commodore 8–bit computers today, virtually all of which are based on the sd2iec firmware. The hardware comes in a variety of packages, with different buttons, cases and means of obtaining power. Some go under different branded names, and some include special features such as an LCD display, a daughter board or an internal mounting bracket. But they almost all run some variant of the same software. And it is the software inside the devices that make them feel and behave alike when using them on your C64.
sd2iec is firmware, used in hardware designs like MMC2IEC, SD2IEC, and uIEC. It allows the Commodore serial bus to access removable storage devices (MMC, SD, CF). Think of SD2IEC as a CMD HD but with a modern storage medium instead of a SCSI harddrive.
This User's Manual covers the sd2iec firmware, its commands, features, configuration, software support and limitations. It does not cover hardware device specific features. There are some generic hardware features that the firmware interacts with. These are covered, but they may or may not be present on your particular hardware device. Examples include: a reset button, swap button, next and previous buttons and device address jumpers or switches.
SD2IEC Hardware Devices
Check the Commodore 8-Bit Buyer's Guide: Storage for more information about the assortment of SD2IEC hardware devices currently on the market.
Some common sd2iec–based, SD2IEC hardware devices.
NOTE: To distinguish the hardware from the firmware, hardware devices which use the firmware are referred to in this User's Manual in uppercase: SD2IEC. References to the firmware are in lowercase: sd2iec.
The sd2iec command set and file and device access features are based upon Commodore DOS that was developed for Commodore's original floppy disk drives, and was used and popularized by the widely sold 1541. sd2iec includes other features that were added by later Commodore disk drives and by the CMD line of storage devices, (CMD FD, CMD HD and CMD RamLink). Building upon the command syntax of Commodore DOS helps to maintain compatibility with existing software, although, compatibility is not complete.
sd2iec supports the majority of features available to earlier disk drives, and adds many new features to take advantage of the more advanced hardware. Although some DOS commands are not available in sd2iec, the biggest reason for compatibility issues is that the original DOS ran on the drive's own stripped down 6502–based computer. Commodore DOS exposed implementational details that allowed programmers—encouraged them even—to execute code on the drive. This was taken advantage of by many speed loaders. Such software may encounter compatibility issues with sd2iec, which is not based on a 6502 microprocessor, and cannot run drive specific code.
Some quick updates to start with. If you haven't noticed, I've recently put a fair bit of work into the "C64 OS" section of this site. Originally intended to be for technical documentation, and so named for a while, I have rebranded the section as, C64 OS: USER'S GUIDE
I've divided the left–side table of contents into two sections. The first half is just a basic user's guide for regular users. Then part way through there is a subheading for Programmer's Guide, followed by the programming documentation. I've put a good chunk of work into both halves of the guide. The Programmer's Guide is divided primarily by C64 OS kernal module, and I've completed 6 of 10 modules, plus an introduction to the C64 OS kernal, macros, registers, flags, symbols and lookup tables.
I've also been working on a paper version of the manual. But, the limited space in the paper manual means the online version can go into a lot more detail. Having the online version will make me more comfortable about trimming down the paper version to probably 14 or 16 pages.
A second quick update, I've introduced a new layout to the weblog section of C64OS.com. If you look to the left you'll see three buttons at the top, View As Newsfeed, View By Category and View Full Archive. The archive view has been around for a while, but getting to it was never as easy as it is now. View By Category is new. It's got a table of contents at the top, reminicsent of the Buyer's Guide, and the posts are laid out in a grid grouped by their main category tag. I think it's quite nice. Though, now I've got to get better at making nicer "icons" for the posts.
Okay, so following up on my recent post, Versa64Cart and C64 ROMs, I wanted to discuss my experience using the Promenade C1. The Promenade is an EPROM burner with a 28–PIN ZIF socket, in a rugged aluminum case. It connects to your C64 or c128 via the user port. I remember seeing this advertised in the back of a buyer's guide catalog that Commodore put out in the late 80s. I loved that buyer's guide, and I used to drool over all the third–party peripherals. As a kid, the Promenade was one of those that looked interesting, but I never quite understood what it was for.
Who knew that, 30 years later, I would eventually own one, figure out how to use it and then blog about it, singing its praises. But that's pretty much what happened. When the Versa64 Cart came to my attention and I got interested in trying to assemble and sell some, I also wanted to find out if there was any way to burn EPROMs right from my C64. I like doing things with the C64 as much as possible. It's fun, and it feels more authentic to me. So I did a little search and discovered the Promenade. "Oh, that's what that thing from my childhood memories is for." Nice.
Every so often when I'm writing a new post it reminds me of something I wrote in an earlier post, so I'll go back and read it to make sure I'm covering new ground instead of just repeating myself. I wrote about "Object Orientation in 6502" in July 2017, which does not feel like a long time ago. Please, don't bother to read it.
It is not a fine example of writing, nor of clarity of thought. But, it was my first attempt at writing about Object Orientation. I've been programming object oriented code for 15 years, and I've read countless articles about OO, and even a book or two, but I've never had to take what I know from practice and put it into my own words. Writing is hard. Writing coherently and pleasingly on a technical subject is even harder. I hope this time around will be a bit better.
There is good software practice, and there is bad software practice. We all learned long ago that the GOTO command in BASIC is bad news. It leads to unmaintainable spaghetti code, and should be avoided whenever possible. Most modern languages don't even have an equivalent. When we think about the choice between programming languages, it's easy to imagine that they are mere conventions, different ways of expressing what ends up at bottom the same thing, the machine code. But abstracting in this way can hide some harsh low–level realities.
When you write in a high level language you leave a lot of the dirty work to the compiler. One of the many benefits of compilation, then, is that it enforces good practices. Code can be namespaced, functions take parameters which decreases reliance on global state, data can be typed and can only be used outside its type with explicit notation, which means it can't be misused by accident. And without a GOTO command your code can't just jump around, even though the underlying CPU probably has the equivalent of a JMP instruction.
So, essentially, high level programming languages make it easier to code well by abstracting some of the underlying details. Right? Well… it has gradually become clear to me that this is only part of the story.
A computer is a computer.
Everyone knows that CPUs get faster. In the early 80s it was 1 to 4 Mhz, in the late 80s it was 7 to 14 Mhz. The 90s saw crazy increases from 20 Mhz to hundreds, and by the mid 2000s it was GHz. Eventually we hit a clockrate plateau, but two other shiny numbers have risen along the way: The C64 was 8–bit, the Amiga was 16–bit. Later came 32–bit Macs and PCs, and now 64–bit is common across the line from workstations to smartphones. And let's not forget about cores. First you could get a PowerMac with two G4s. Separate CPUs soon turned into two cores on the same die. Two turned into 4 which soon became 6, then 8. And now you can spec out an iMac Pro with 10, 14 or 18 CPU cores. Numbers are getting bigger, more memory is available, everything's getting faster. Ergo, software can be made more sophisticated, because the raw compute resources allow for more abstract and circuitous pathways to be followed. That seems to make sense.
But this is not really accurate. It's a consumer's–magazine simplification of a much more nuanced advancement. If you only look at two, maybe three, broad statistics a large part of the story is missed.
I learned about the Versa64Cart, by Petter Hans (BWACK) over a year ago on Twitter, and the project intrigued me. At the time I knew very little about how external cartridge roms work, but I knew there were a handful of new ROM cartridge boards being made and sold for the C64 and c128, and for the Vic–20 and C16 too.
I love hardware, which is part of the reason why I made the Commodore 8-Bit Buyer's Guide. I continue to work, slowly, on writing reviews of the various projects in the guide, but it's hard for the things that I know little about. Maybe creating the guide was just an excuse for me to get to try everything that's out there. The Versa64Cart was a bit different than some of the others, the PCB, parts list, and documentation are all open source. The buyer's guide lists projects and kits as well as ready–made products, but I like to have a clear understanding of how a regular person can get the final product in their hands. Similarly to 3D printable parts, it's not enough for there to be some spec files, there has to be a clear and easy path to realization. In late 2017, I wrote 3D Printed Components, in which I detail the steps necessary to go from an online catalog of 3D parts, to holding the item in your hands. I want to do the same for the Versa64Cart.
We will get there, I promise. But along the way, it proved to be a somewhat more complicated path to enlightenment. 3D printed keyboard brackets, for example, are pretty easy to use. You stick 'em under your keyboard, put in a few screws, and the keyboard is conveniently positioned correctly. And that's all there is to that. But the Versa64Cart needs the PCB professionally printed, the correct parts list to be ordered, and then everything assembled. But even then, you're not quite done. The Versa64Cart is called "Versa" because it's versatile. It can take EPROM chips of various sizes, which must be programmed correctly with Commodore 64 cartridge software. The versatility allows for multiple binaries to be written into different regions of the same EPROM. The Versa64Cart has 5 jumpers and a bank of 5 dip switches, which must be set correctly for the ROM programs to work.
After getting all the parts and assembling, I also ordered a batch of 32K EPROMs, and then bought the Promenade C1 eprommer that lets me burn EPROMs from my C64. Finally, I set out to do my homework to figure out how this thing actually works, and how the C64's memory mapping extends to support external ROMs. And now, I want to share this whole process, end–to–end, with you.
Let's start with the Commodore 64's memory mapping. This seems fitting, because I just finished writing a post about the 6510 Processor Port. In that post, (if you haven't read it I recommend you do,) I discuss how the port built into the 6510 CPU uses some of its bits to configure the PLA, which is the central hub of the C64's memory mapping. This clever system provides the C64 a great deal of flexibility and expandability.
The 6510 is a variant of the 6502 CPU produced by MOS Technologies. People who have heard of the 6502 often associate it with the classic systems, NES, Apple II and C64, for example. The 6502 was used in the VIC–20, and also used in disk drives like the 1541, but the C64 is actually powered by the 6510.
There isn't a huge difference. The 6510 has the same instruction set as the 6502, so any books and tutorials about programming the 6502 apply (almost without exception) to the 6510 as well. So why does the C64 use the 6510 then?
The reason is because the 6510 includes an additional 6–bit port. In the context of the C64 as a whole, this is referred to as the Processor Port, because it's the port found on the processor. The 6510, like the 6502, is an 8–bit CPU. But what does that 8–bit refer to? Its data bus is 8–bit's wide, and most of its internal registers, Accumulator, X and Y index, Status and Stack Pointer are all 8–bits wide. Also, all of the arithmetic instructions, add and subtract, rolls, shifts, and logical AND, OR and EOR, all operate on 8–bits at a time.
The address bus, though, is 16–bits wide and for this reason the Program Counter is 16–bit as well. This allows the CPU to read and write 8–bits at a time from 65,536 unique addresses, which is the equivalent of 64 kilobytes of addressing space. The C64, famous for its namesake, comes with 64 kilobytes of RAM. But it doesn't come only with 64 kilobytes of RAM, or it wouldn't be able to do very much. It also has a SID chip and a VIC–II chip, a pair of CIA chips for general I/O, and a special static RAM chip for color data. It's also got ROM chips for the Character Set, BASIC and the KERNAL that collectively give it the blinking blue READY cursor.
But something is amiss. If the CPU can address 64 kilobytes of space, and the C64 has 64 kilobytes of RAM, PLUS all that other stuff, how does the CPU manage to talk to all of it? BASIC and the KERNAL span 8K of addressing each, the Character Set is 4K, the VIC and SID and CIAs need addressing space too, so you end up with 64K + 8K + 8K + 4K + 4K that's 88K of addressing. How can a CPU with 64K of addressing space address 88K worth of stuff?
The 6510's built–in port plays a critical role.
I'll begin with a quick progress update. With the exception of the Widget Toolkit, the core C64 OS is very stable and nearly built out. I now find myself working almost exclusively (the topic of this post being a recent exception) on the applications and utilities that I want to be included as part of the OS.
I have a list of utilities that I plan to create, and I've made some detailed UI mockups on graph paper (my favourite UI prototyping medium). Some of these utilities will depend on the Toolkit and in fact will be the playground and dogfooding of the Toolkit. Others do not need the toolkit and so I've been focused on banging a few of those out. For example, I've made the About C64 OS utility, and the About This App utility. And most recently I've been working on the Scientific Calculator utility. The calculator turned out to be trickier than I thought it would be, as I first had to reverse engineer the behavior of calculators, and found to my surprise that they all behave subtley differently.
The main application I've been working on is the App Launcher, one of the two HomeBase apps, used to launch into other applications and to open utilities. While working on this I've also been using it as a playground for figuring out how to send messages between the running application and any utility. So, for example, my original implementation of the Colors utility was to have a "Choose" button at the bottom. This would send a color to the application and close the Color utility. And then I had a way of passing an initial color to the Colors utility when it first opened. This turned out to be a terrible workflow, the Colors utility had to be opened and closed over and over again while trying to set the colors of the various aliases on the App Launcher's desktop.
In late 2016, when I was setting up my workspace for Commodore computers, programming and all sorts of other retro mancave-style fun, I decided to build a couple of wood stands for monitors.
Here's the post, A Workstation Stand. I got the idea from another site, BYTECellar. Anyway, they've turned out to be pretty great stands. The top surface is on an angle so it holds the display nicely facing up towards me, and conceals all the wires and other crap coming out of the back of the c128. I built a second one for a C64, too. The top surface has a bit that juts out beyond where I put the monitor too. This is a useful little shelf for pencils and programming notes.
But there was one annoying problem. I've got the uIEC with deluxe daughter card from Retro Innovations, which is a nice little implementation of SD2IEC. The deluxe daughter card plugs into the cassette port for power, and to anchor to the back of the computer. And then the uIEC/SD plugs into it via a 1x13 pin terminal block. The daughter card includes two IEC ports on the bottom, 4 momentairy push buttons on long the left side, for reset, disk image swap, etc. Plus, the daughter card has two female headers for the uIEC/SD to plug into.
Near the end of 2016 I had some wide-eyed ideas about using the C64 Gfx library as part of a online service for converting images. I have since developed that idea into an actual functional webservice that has been online for a many months. But I wanted to take a few minutes to talk about how it works and how it fits into a wider suite of services.
The place to checkout is http://services.c64os.com/about. This is the page that officially documents the services that are available. It currently documents and image conversion service and a relocated SID catalog. I'll write a separate post sometime in the future about the SID catalog. For now, let's discuss some of the other services.
I want my C64 to be able to reach and consume as much of the internet as possible. The concept of the internet, a global interconnected network of heterogeneous platforms, sharing common protocols and exchanging common file formats, is brilliant. But, one big problem is that beginning many years ago the resources on the internet began to scale up with the ever increasing power of personal computers, and consequently most of those resources have become undigestable by older computers with more limited resources. This is not only a C64 problem, it's a problem for Amigas, and vintage Macs, and others.
The situation is not entirely unlike CD ROMs. Many years ago, when CD ROM drives became popular, the C64 was not long to follow in its ability to read the content of CDs. The IDE64 had support for CD ROM drives, the CMD HD could be connected to SCSI CD ROM drives, and even today the 1541 Ultimate can be used for accessing CD ROM drives connected via USB. The problem is that these discs and their relatively high capacity were immediately taken advantage of to store large media files. Large (for the time) images, rich with thousands of colors and compressed to save space. Video clips, audio clips, PDFs, HTML files and of course Windows– and Macintosh–only executable code. Our C64s could read the CDs, traverse the file system, but there was little that we could digest from those discs. Besides the odd small GIF, a bit later the odd small JPEG, a few text files that became rarer and rarer and contained less and less useful information, like copyright and license files. Yay for those.
I mentioned very briefly in the previous post that I've been working on the context drawing system for C64 OS. Believe it or not, I first mentioned the context drawing system in September 2017, in the post Organizing a Big Module. Back then, I said this:
Drawing, in general, is a complex topic. So it's really hard to cover in a single post. I will eventually dedicate an entire post just to talking about how the drawing system works. Gregory Naçu — September 2017
Well, the time has arrived. This is that post in which I will go into detail talking about the context drawing system. The state of flux has calmed down and it is now pretty much in the state that it's going to stay in. The locations and names of the system calls have been worked out as well as the parameters they take. So let us dive into context drawing systems.
The Hardware Level
Whether we're talking about a text–based screen or a graphics–based screen there is at bottom a hardware level. Physical memory, out of which a graphics chip or chipset interprets data to generate the video signals necessary to put pixels on a screen. On newer hardware, exactly where that memory is and how the translating of memory to pixels works can be very complicated and is always several layers of abstraction removed from what the programmer is coding. On the C64 everything is much simpler, and it is easy to remove all the layers of abstraction and work directly with hardware. But we'll see why that isn't a great idea, and that even the C64 KERNAL introduces a layer or two of abstraction.
The C64 KERNAL doesn't provide anything for abstracting bitmap drawing. But it does for text–based drawing. And C64 OS's primary UI is also text–based, so let's start there.
The VIC-II chip has a native text mode. In this mode it reads screencodes out of a 1000 byte matrix, 40 by 25. Each screencode is in fact just an index into the selected characterset. The characterset is a 2K bitmap. There are 256 screencodes, therefore 256 indexes. Each character is composed of an 8x8 pixel square, or 64 pixels. 64 times 256 is 16,384 bits or 2048 bytes, aka 2K. One register in the VIC-II, $D018, is used to specify both the start of the 2K characterset, and the start of the 1000 bytes of screen matrix memory. I drew up this diagram on paper to help me visualize how the bits work.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.