NEWS, EDITORIALS, REFERENCE
I was in the middle of working on this post, and very suddenly Corona Virus became the only thing anyone could talk or think about. I was just about to start March Break, which I took off work to be home with my kids, when we found out that Canada was closing the schools for the 2 weeks following March Break. Then during March Break the University where I work announced they were closing their doors and everyone would be working from home. There are no more on–campus classes until September. And the elementary school closures are most likely to be extended until the beginning of next school year.
I am now homeschooling my two kids, making breakfasts, morning snacks and lunches for 3. I'm going on daily walks, teaching reading, creative writing, social studies, geography, science, religion and mathematics during 3 hours of every day; working in my home office 3 hours a day; trying to stay sane by having some semblance of a life in the evening with my wife, who is a healthcare worker in a hospital under duress. And then working from 10pm to 1am on C64 OS programming, documentation and blogging. I must admit, I've fallen asleep at my desk more than once so far. So, please be patient. I really do not want my projects to get derailed by this unexpected global crisis. Although this post took me longer to finish than I'd hoped, here it is, and over 17,000 words strong. I hope it's useful.Greg Nacu
Husband, Father, Teacher, University Employee, Writer, C64 OS Programmer
NOTE: This post explains the ins and outs of how some of SD2IEC's settings affect its behavior, but it does not teach you how to configure SD2IEC's settings. I recommend opening the SD2IEC User's Manual, and following along with this post and trying its examples on your own SD2IEC as you read. Refer to the User's Manual when necessary to learn how to change the settings that are described in this post.
Back in 1995, Apple put out a cheeky print ad that said merely, "C:\ONGRTLNS.W95" with a little 6–color Apple logo beneath it.
Why did they do that? Besides the fact that they were cheeky and so arrogant that they couldn't foresee that Windows95 was coming in like a steamroller. Microsoft was about to lay them so low that many consider it a miracle that they escaped the clutches of bankruptcy during the 5 darkest years of their history.
But they did it because, when you're facing stiff competition, it's important to talk up your own strengths and point out the competition's weaknesses. And one of Microsoft's weaknesses was that they were obsessed with maintaining full backwards compatibility with the PCs that stretched back into the mists of time. (You know, the era of the Commodore 64.)
At the time, Apple's HFS file system supported filenames up to 255 characters long, with very few illegal characters.1 Eventually HFS got long in the tooth, but at the time it sported many clever features. Files could have both a data and a resource fork, such that metadata, including the file's datatype, creator code, custom icon and more could all be attached to even simple plaintext files.
Windows95 on the other hand was clearly evolved in small gradual steps from its MS–DOS days, and was released with an extended version of FAT16. FAT16 limited filenames to only 8 characters, plus a 3 character extension that was used as metadata to indicate the file's datatype. Windows also had drive letters. C: to this day, is still the drive letter for the primary harddrive, because A: and B: are for floppy drives. Even though most PCs haven't shipped with a floppy drive in 20 years.
VFAT Directory Entry Structure
True to form, Microsoft remediated FAT16's rather sad state of affairs by introducing a layer called Virtual FAT. VFAT enabled Windows95 to show and use long filenames, without changing the data structures of the underlying FAT16 file system. This added a raft of complication, but it had the advantage that Windows95 files could still be accessed and used by MS–DOS.
"But, sir, we use our Commodore computers. So, why are you sharing with us this fascinating history?"
Because, dear reader, like it or not, we have inherited this madness, by way of SD2IEC. And I am going to do my best to try to explain how it works and what impact it has on the C64. But first, we will review how typical or native Commodore devices and file systems work so that we have some frame of reference.
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
First a quick update. Work on C64 OS is continuing apace. I'm now working full bore on the Toolkit. The structure of objects is worked out, and working out well. Hit testing is implemented, sizing and anchoring, resizing and the whole context drawing system are working. I've implemented the first few Toolkit classes and anticipate that I'll be able to hammer out a few more relatively quickly. After that, I'll be able to start putting together those applications and utilities that have a more complex UI, that I've not wanted to start working on until the Toolkit is available to lean on.
However, my creaky old SCSI harddrive has been giving me SCSI controller errors periodically, it makes strange noises every now and then, besides being generally very loud, and to make matters worse, it has about 3 partitions that are totally corrupt. I tried to acquire a CF Aztec Monster a year or so ago, but was unable to find a reliable source. I placed an order from, shall we say, an unreliable source. After giving me the end runaround for a few months, I cancelled my order and submitted my whole exchange to PayPal to try to get my money back. They refunded the money in full. That was a close one.
The CF Aztec Monster being unavailable, I decided to order a SCSI2SD which are available from numerous trustworthy sources, including AmigaKit.com. The short story is that transitioning my CMD HD to the SCSI2SD was an enjoyable, plainless, and successful process. I did not require the use of any computer other than my c128 to do it. And I'd love to walk you through how I did that and what tools and software I used.
Before we get going on this post, just a quick reminder than the Commodore Logo Patches are back in stock. These are high quality embroidered patches with an iron on backing. You can order these directly through this site over in the Buyer's Guide. I also have a few Versa64Carts still in stock, which you can also order from the Buyer's Guide. Ordering one of the select items I'm selling helps to support C64os.com and my work here.
The 6502/6510 has a fairly limited stack. This is one reason why the processor is really not designed to do pre–emptive multi–tasking. The CPU is 8–bit, meaning all of its internal registers, (besides the program counter,) are 8–bits wide. The stack pointer, too, is only 8–bit. Which means the stack can only be 256 bytes deep.
There are two points here. On the one hand, that's way more than enough. Most 6502 programmers realize, after they've been programming for a while, that they rarely if ever use more than around one quarter of the total available stack. In normal 6502 code, the return address of a JSR is what the stack is most often used for. But that's only 2 bytes. You could call 120 subroutines each one nested within the previous one, and still not run out of stack. This is a huge amount of stack. It's so huge things like BASIC string conversion use the end of stack memory as temporary working space, because almost never is anything using that memory.
On the other hand, if you program in C, it's a different story. The nature of C is that all the arguments of a function, and all the additional local variables of a function are passed via and stored on the stack. This has the advantage that C functions are re-entrant by default, and recursion is therefore a breeze. This is particularly handy in a multi–tasking environment where those functions may be being shared concurrently by more than one process. And this technique is helped along by the fact that other more powerful CPUs have more flexible stack–relative addressing modes.
However, as long as we're not writing in C, or some other stack heavy high–level language, we do have a lot of stack available.
Let me give some context for why this project exists. Then I'll go into some detail on what I discovered, and we'll explore how the i2c bus and protocol works and dive deep into my 6502 implementation.
I'm working on an operating system, C64 OS, for the Commodore 64. An operating system can almost always benefit by knowing the current date and time. At the very least because it's useful for setting the clock that appears at the end of the menu bar.
The C64 didn't originally ship with a built–in realtime clock, nor did it include a standard port for an RTC, like the later Amiga did with its clock port. With the arrival of more advanced operating systems, such as GEOS, several options for accessing an RTC became available, but there was no one standard. Creative Micro Designs, CMD, always eager to make the C64/128 productive, embedded RTCs into most of their products. The CMD HD, the CMD FD, the CMD RamLink and the CMD SmartMouse, all included RTCs. For the storage devices, the RTC is accessed as a standard DOS command and the response is read from the device's error channel. In other words, the communications with these RTCs is piggybacked on the IEC serial bus, for which there is already an implementation built into the C64's KERNAL ROM.
The SmartMouse must have employed a different and custom communications method.
SD2IEC, for which I have written a full user manual, has support for an RTC in the firmware, that is nearly 100% compatible with the CMD storage devices, but most SD2IEC hardware implementations don't actually include one.
The IDE64 has an RTC, but I haven't yet explored how to talk to it. The 1541 Ultimate II+ and the Ultimate 64 have an RTC built in, and it is accessible using Ultimate DOS commands which are sent over its proprietary Ultimate Command Interface. This requires some effort to actually support, but it's not too hard. C64 OS already includes an RTC driver for the Ultimate Command Interface.
The 1541 UII+, the Ultimate 64 and IDE64 are, however, outside the budget of many potential C64 OS users. And the CMD devices are no longer commercially available. In all likelihood a typical C64 OS user will gain access via the minimum hardware requirements of an SD2IEC. They are likely, however, to end up with one that does not include an RTC. It would therefore be convenient if they could acquire an affordable, stand–alone, RTC module. Of course, such modules exist for the Arduino. The DS3231, costs less than $2. A very affordable, convenient addition that makes your C64 running C64 OS better.
I had a one hour block of time to present at World of Commodore, but I asked them to split it into two half–hour blocks, because I wanted to give a talk about Video Playback on the C64 with 1541 Ultimate II+. It doesn't really need an introduction, because, that is the whole point of the presentation itself, which we'll get to shortly.
Additionally, I mentioned in part 1 that my presentations were given with slide presentations from my C64 Luggable. It is hard to tell in the YouTube videos exactly what is going on because the camera spends most of its time focused on the screen and only a few shots actually include me. And of those, you don't see much of my C64 and probably don't notice what's going on in my hands. However, if you check the thumbnail image for this post, above right, you'll see that I'm holding a NES controller.
I do love NES controllers for joysticks on my C64, as I've talked about here and here. But it turns out that a NES controller also makes for a really great, inconspicuous, one–handed slide clicker. The two red fire buttons make for easy back and forward controls that can be triggered with your thumb by holding the controller such that the d-pad is buried in your palm. Additionally, the long 6' cable provided me ample freedom of movement.
So, before we get into the presentation I wanted give a technical overview of how the presentation software works.
This post is part 1 of a two–part follow up to my review of World of Commodore 2019. If you're interested in getting an overview of the show and a taste of what you might get to enjoy first hand if you decide to come to World of Commodore in 2020, then I encourage you to check out that post.
It would have been too long to cover my own presentations from World of Commodore within that general review post. It also didn't seem right to give myself the royal treatment and just a paragraph about other presentations. In this two–part post, instead, I will go into what I presented.
The videos from the show have been uploaded to YouTube and are embedded below. I gave two talks, the first was an Introduction to C64 OS, and the second, which is covered in the second part of this post, was Video Playback with 1541 Ultimate II. Both talks were given with the assistence of a slide presentation for the first half followed by some live demos. The presentations themselves were done from my C64 Luggable with some software that I wrote prior to the show. A few people inquired about that and I'd love to give a brief description of how that works too.
So, let us not delay any further and get right into the juicy details.
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.
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.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.