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