NEWS, EDITORIALS, REFERENCE
I am writing about a drive technology that was released in 1982, but whose essential origins stretch back into the decade before that, let's call it 40 years old. And I'm writing this just a few nights after watching Apple's 2020 iPhone 12 media event. This year, as every year, this new iPhone is the bestest at everything. The juxtaposition of the modern and the retro has never been more extreme. But, here's the thing, it doesn't matter whether it's 11 billion or 5 billion or 1 billon whatevers, one thing remains the same: you can't get into an iPhone and see how it works.
I used to be the kid who loved this new–fangled thing called home computers, and looked down my nose at my father's friend who drove a restored antique buggy down the back roads. He took me for a ride once. It was slow and deafeningly loud, like hundreds of explosions going off inside a metal box right beneath your head. It was bumpy and rough, and frankly, it stank of gasoline. But now I'm almost 40, and you know what? I get it! I understand now. Sure, he's 70 now, and that's why he was into antique cars not computers. But when a youth of today looks at a Commodore 1541 drive, surely they will not understand why anyone would waste their time.
A 1541 drive weighs several pounds, it heats up like mad as it sucks back electric power, it's loud and is prone to a variety of failures, and yet it only has a maximum throughput of between ~4 to ~25 kilobytes per second. And its storage media are fragile, with sensitive parts open and exposed, 5.25" square, with a maximum capacity of only 170 kilobytes (per side.) The analogy to the antique car is nearly perfect. Why would anyone want to waste their time frigging around with one of these ancient lumbering monstrosities? But it has all become clear to me. You can open a 1541 drive up, you can see its components with your naked eyeballs. You can clean and tune its parts by hand. But best yet, you can study it and learn about it, and actually come to a satisfying level of comprehension about how it works. And that feels fantastic.
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
Originally I thought I'd pack this into one post. I decided to split it into two so we could get into some details about the power up process both in hardware and software, and then have room in this post to get into the details about how to deal with the variations and complexities—that have crept in over the years—for what was once a simple task, loading and running a program on a C64.
If you've just stumbled upon this post, I encourage you to read part 1, Load and Run from 6502 ASM (1/3), first. Here's a very brief summary of what was covered in part 1:
It used to be very straightforward to load and run a program on a C64. Most users had only one disk drive, on device 8, which was the drive's default. The load instruction was one command that would frequently appear on the disk label itself or in the first page of the software package's manual. Early software, i.e. most software, came to rely on being booted from device 8, even as users purchased and hooked up additional and more sophisticated storage devices.
C64 programs assume they own the whole machine, and often depend on the machine being configured as it would be following a fresh power on. When the machine is powered up it goes through an initial reset cycle, which runs 4 standard KERNAL routines before passing control over to BASIC. From BASIC there are several ways that a program can be started, depending on how it was written and whether the machine has a stock or third party KERNAL ROM like JiffyDOS. The sad fact is that there is no one single reliable command that will guarantee the program will be started correctly.
I'd originally planned this discussion to be a single post. But it turns out there was a lot to talk about, so I've split it into two parts. This is the first part which talks about what technically goes on when the computer is powered up or restarted, and how programs get loaded into memory and run. The second part, discusses exactly what the difficulties have become with loading C64 software on modern conglomerates of hardware, and how similar problems have been addressed on other platforms. Part 2 will then get into the programming details of how to solve this problem on the C64.
When the Commodore 64 first came out there were two common storage devices that people would get along with it. If you were in Britain or certain parts of Europe you probably had a Datasette which could store and retrieve data from standard compact cassette tapes, the kind usually used for audio. If you were in North America, or some other parts of Europe, you likely had a 1541 floppy disk drive.
Most commercial software came packaged in one of these two formats. For me, personally, the cassette–based Datasette fell out of use after the Commodore VIC–20. Although the C64 has a cassette port on the back, and the original KERNAL ROM still supports loading software from cassette, loading from disk is superior in almost every way. Disks are thinner and lighter, they have a higher storage capacity, have a faster load time and allow for random access to read and write data. With the ability for random access, a disk drive also allows you to load and list a directory of the disk's contents. You can then load a program by its name and the directory tells the drive's DOS precisely where on the disk to find the first block of that file's chain of data.
There were some advantages to loading from tape. Many games used special tape loader software that could display a beautiful splash screen while the game was loading in, this generally was not the case with disk–based games.
Today, of course, there is still the nostalgia factor for cassettes, if that's what you grew up with. But that's all I'll say about tapes. They were popular in parts of the world, but I don't have much nostalgia for them personally as they were never a part of my experience with the Commodore 64.
Using a C64 Program
If you're used to a modern Mac or PC, the first run experience of using a C64 can seem utterly baffling. You have to learn and remember a bunch of arcane commands??! It wasn't ever quite that bad. Here were the steps you would typically go through to use a program on a Commodore 64:
Terry Raymond is an old school North American, Expo–going Commodore 64 fan. Throughout the years he has asked me and others to give him helpful tips on how to program his C64. He has been interested in what it would take to make a Wave audio player, particularly for GEOS or Wheels. A valiant goal, in my personal opinion. And a fun project.
The problem is that, to really do justice to the questions, I feel like I'd have to write a rather long response. I wouldn't want to do that in an email, because the time spent would not benefit anyone other than the sole recipient of the email. Instead, I've decided that this is a great opportunity to turn the dialog of the email, with my long–form responses, into a blog post. I do love the topic of digital audio, after all. This seems as good a time as any to talk about it.
Hey back in 2008 I had wanted to code something in GEOS possibly to play Riff 8-bit Mono wave files, well later in 2009 I contacted Werner Weicht he said to do this would need Wheels since it can handle its memory better, since it requires some sort of memory expansion to boot.
Yes, I remember that you were interested in making a Riff/Wave player for GEOS or Wheels. Digital audio requires a lot of data for only a little playback, and an OS is going to use a bunch of main memory. So, I agree that you would be best off targeting a platform that either requires an REU or that provides some extra REU support.
Well Werner helped me enough to have a barely working app:
WavePlay 128 40/80 column support
Every so often I like to really get into the weeds on some 6502 programming. I have recently been working with the C64 OS directory library that I wrote, as I work on the File Manager homebase application.
The directory library is assembled in two versions, a low memory and a high memory version. These can be dynamically linked into your C64 OS programs. The low memory one is designed to fit into an application binary's memory space, directly following the standard application jump table. The high memory version fits into the memory space of a utility, right after its standard jump table. Since the first code in the directory library is its own jump table, this means that your app or utility's standard jump table is extended to include the directory library's calls.
The directory library is not part of the KERNAL because it takes up at least a couple of pages of code, and only those applications and or utilities that need to work with directories will make use of it.
Welcome back one and all. I hope things are going well for everyone. This post is going to be a shorter talk about IDE64 and what it took to get it supported by C64 OS. I've classified this as a software post, and then I've gone ahead and made the icon a picture of a piece of hardware. At some point the hardware and how it works becomes a software issue. I'm going to talk briefly about the IDE64 and what I've learned about how it works, before getting into the changes I made in C64 OS.
Before we get started I'd like to thank everyone who purchased a Versa64Cart that I had available on this site. Your support is very much appreciated. I have now sold out of the stock that I brought in and put together as part of my experiment in how one can go from online open–source hardware to actually having the product in your hands. I wrote about the process in the post Versa64Cart and C64 ROMs. I learned a lot and some of the things I learned are even relevant for this post and how IDE64 works. It was also a lot of fun, and I got a Versa64Cart into the hands of a bunch of people who wanted one.
I still have Commodore Logo Patches available, if you're looking to support my work here. And I have some work to do on updating the manual and assembly instructions for the Promenade C1 clone, the Promenade Model D. But soon I'll have those available here as kits for purchase.
Now let's talk IDE64!
A quick update on myself and situation. My schedule has become a bit tighter. In addition to working from home and watching my kids through the day, there has also been a recent medical crisis. A close member of my extended family was rushed to the hospital for an emergency heart surgery. She survived and is slowly recovering, but full recovery is going to take a long time. It's been stressful, especially for my wife and extended family. During this writing I also got some bad news about the sad passing of a friend and fellow software developer.
In memory of Christopher Roy. -2020
I'm plowing ahead with developing C64 OS. And I don't want to slow down the pace of putting out blog posts and updates, but I may not be able to put out 10,000+ word deep dives as frequently as I have before. I'll just play it by ear, and maybe put out some shorter posts for a while, until things settle down a bit.
This post is about the Toolkit class hierarchy. This is probably what the finalized v1.0 will release with. Although there is always some chance that it will change. In this post we'll also look at how some of the classes are structured and how they work. A previous post discusses how Object Orientation in 6502 (take 2) works, but doesn't discuss how the toolkit classes make use of those OO–techniques.
No time to waste, so let's just dig right in.
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.
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.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.