NEWS, EDITORIALS, REFERENCE
Welcome back. Hopefully this post will get technical with some useful information, but not so archane that it'll turn away more casual readers. A fine line to walk, but we'll see where we get.
Not too long ago I tweeted out my excitement about getting the split screen mode in C64 OS working. On the tails of that I put split screen to work in the NES Tester application and shortly after in Chess. Both of these applications have more than one purpose. Besides making use of split screen, working out its bugs and seeing what we can pull off, the NES Tester is useful for testing my NES Controller mods (see here and here) and also for experimenting with OS drivers for 2 and 4 player game controllers. Chess, as I outlined in my recent post C64 OS Networking and Chess, displays a graphical game board, but is also a place to experiment with networking, drivers, communications protocols and so on.
I want to dig in to what I've learned about the VIC–II, raster display updating, and more, and discuss what was necessary to get split screen working. But along the way, I've learned so much about the history of computers that I can't pass up the opportunity to talk about some of the details. I love the cake of computers, but I find their history to be a particularly tasty icing.
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
Last year I made a nice post introducing C64 OS Utilities. In which I discuss their advantages over GEOS Desk Accessories, and go into some detail about what they can do and how they will be used to augment the functionality of the system and its applications. That post is mostly still accurate, and is well worth a read. A few key points will be repeated in this post, but it should be considered a continuation of the earlier introduction.
Utilities are useful small apps that can be loaded, one at a time, concurrently with the main application. By relying on multiple smaller Utilities to do a chunk of work for your application you get several advantages:
- Your application's main code can be made smaller
- More main RAM can be freed up for use by your app's data
- Your application will launch faster
- The utilities you create can be used to enhance other applications
- Using your application will be more consistent with the rest of the system
C64 OS's system folder is quite structured. Applications go in the applications folder. Drivers go in the drivers folder. And Utilities go in the utilities folder. The downstream benefits of even a simple level of organization like this are bigger than you would expect. Now to be fair, the opportunity to organize the many files of an OS like this often comes on the heels of hardware that enables it.
Let's recap GEOS for a moment. GEOS ran from a single side of a 1541 floppy disk. That's a 170K disk with a formatted capacity of just 166K. That's only 2.5X the total capacity of the C64's RAM. If you put the essential system files and the deskTop on a disk, you've already used just under half of that capacity. Then you add one application, maybe geoWrite, one document file and a couple of fonts, and the disk is full. Another thing to consider is that 1541 disks don't support subdirectories. But frankly, there's not much point in supporting subdirectories when the disk is full with just 10 or so of these files.
Some quick housekeeping on my previous post, C64 OS Networking and Chess. I updated the post adding credit to Bo Zimmerman for the creation of the Zimodem firmware. And I had a chat with him about what I'd written. Turns out there are a couple of pieces of good news which I did not know.
The Zimodem firmware is entirely open source, in the update I linked to its GitHub Repository. But what I learned is that there is nothing particular to the C64NET hardware that the Zimodem firmware requires. What this means is that if you purchased a WiFi modem other than the C64NET, and you want to have access to this more advanced feature set, you can likely update the firmware on your existing modem.
Any wifi modem that uses either the ESP8266 or ESP32 or NodeMCU is likely to take the Zimodem firmware just fine. In fact, I got a Strikelink modem at one point and immediately blasted over it with my own firmware. Bo Zimmerman — 2019
For anyone who might ask, "Well then what's the point in getting the C64NET hardware itself?" It has some advantages over the other hardware as well. Most are powered directly off the C64's 5V lines. This can put stress on the power supply as it wasn't designed to drive the extra load. C64NET gets its power from the user port's 9V lines which it converts to 5V on the board. Additionally, the hardware handshaking lines, RTS and CTS are wired up on C64NET and are not always on other WiFi modems.
One more piece of good news. I said I was hopeful that we'd be able to get Zimodem's feature set on a highspeed RS-232 modem, as that would be the ultimate combination. Well, there are two options for this. It is likely that you could update the firmware on, say, the WiModem232. Or even easier yet, electronicsisfun.com has also made the GuruModem.
The GuruModem is a highspeed modem that connects over standard RS-232, so it can be connected to a C64 via GLINK232 or Turbo232, and can transfer data at up to 230Kbps! It is also based upon the Zimodem firmware and supports all of its features and commands, plus has some additional features that are enabled in the firmware's codebase when it targets the GuruModem's slightly larger and more capable microcontroller. If you ask me, this is the gold standard for high speed networking on the C64. I am so excited to get it working and supported in C64 OS, and to see what our old brown friend can accomplish.
Now on to the show, a technique for making relocatable code on 6502.
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.
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.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.