NEWS, EDITORIALS, REFERENCE
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.
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
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.
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.
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.