NEWS, EDITORIALS, REFERENCE
It's that time of year again, when we kick back, warm up behind our computer screens and read long reviews about cool Commodore and retro computer shows.
World of Commodore 2019 has come and gone, and it certainly didn't disappoint. This will be my fourth review of a World of Commodore event. Each year, after I digest for a bit, I try to come up with a theme to guide the narrative of my review. A couple of things though.
This is the first year that I have given a talk at any retro computer
event since at least 2008. It's been 11 long years, so I was kind of nervous to make my first
- The second thing is that the show this year was shortened from a 2–day Saturday/Sunday event, to a 1–day Saturday–only event.
I was worried that the shortened timeframe was a prediction of lower attendence or decreased interest.
I am pleased to inform you, there was no shortage of interest or attendance. I've never seen the showroom floor so packed with people, machines and vendors. Even the number of PETs set up this year blew me away. There were PETs along all four sides of the room, and even on the inner rings of the room, and none of them was owned by the PET–master himself, Steve Gray, who wasn't there this year.
It's hard to pick just one theme this year, so I think I'll sum it up like this:
So many people, so many machines, so little time. Greg Nacu, "theme of the year," World of Commodore 2019
I feel like I say this every year, but I am always pleasantly surprised to find that so many of the people who show up are people I've never seen before. Obviously many of the fun and familiar regulars, Eric Kudzin and Jim Mazurek, Dave Ross, Joe Palumbo, Leif Bloomquist and Golan Klinger, and many others were there. But it isn't just the same group of people who attend, even the show floor presenters had many faces totally unknown to me.
The room was packed with people and machines, every table was full.
In 2016, when I first returned to World of Commodore after an 8–year hiatus, one of the organizers of the show, in a moment of unbridled pessimism, said, "There's only one way that the membership of a Commodore club goes…" He left the word down to linger in our imaginations.
I can't speak for TPUG's actual membership, but as for World of Commodore? I was there in the mid 2000's. I remember when we were in a church basement made of mint green painted cinder blocks, adorned with Jesus fish. Okay, those were dark days. So, if these last few years are any indication, one thing is sure. Attendence and enthusiasm at this Commodore event isn't going down.
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
Lots of people now have asked me if C64 OS is open source. And, the answer is, no, it isn't.
Will it ever be? Who knows. My feeling about open source is that sometimes it's useful, and sometimes it's just a big pain in the butt. I don't want to negotiate with other developers about the direction of the project. I am planning to open a private beta, very soon. I like getting ideas, and in time I hope people will contribute by writing apps, utilities, and drivers for C64 OS and even sell those apps and utilities. That'd be good.
That said, I'm not putting in any copy protection, because I don't think there is a good way to do that in a way that doesn't hinder the software. We're now in an age of the C64 when the fine folk who want to support the work of others will pay to get a copy, and the people who don't want to never will. Copy protection basically just punishes the people who have paid for it, by making it harder for them to make legitimate copies and use it as they see fit.
I also believe that a project that gets open–sourced, especially if it becomes free, takes on the unfortunate stigma of being worthless. If you buy a copy, you've got some skin in the game. You're in the club. You're a user and a customer, and you're in a community. I think that's the way I want C64 OS to be positioned.
That said, from time to time I will publish the source to some aspects of what I'm working on. These are small stand–alone components that can be used by other people. And the first of these will be the 1351 mouse driver.
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.
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.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.