<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>C64 OS</title>
		<link>http://www.c64os.com/feed/</link>
		<atom:link href="http://www.c64os.com/feed/" rel="self" type="application/rss+xml" />
		<description>A blog about making a C64 useful in a modern world. Tracks the development progress of C64 OS, an event driven and network oriented unitasking OS for stock C64.</description>
		<language>en-us</language>
		<image>
			<title>C64 OS</title>
			<url>http://www.c64os.com/resources/logo-rss-c64os.png</url>
			<link>http://www.c64os.com/feed/</link>
			<width>144</width>
			<height>48</height>
		</image>
		<item>
			<title>Playing Back PCM Audio</title>
			<link>http://www.c64os.com/post/pcmaudioplayback</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 07 Aug 2020 00:00:00 +0000</pubDate>
			<category>Technical Deep Dive</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/pcmaudioplayback/icon-digimax-waveform.png'> 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. Hi Greg, Hey Terry, 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. . . ]]></description>
			<guid>http://www.c64os.com/post?p=103</guid>
		</item>
	
		<item>
			<title>Directory Library, Natural Sorting</title>
			<link>http://www.c64os.com/post/naturalsort</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Sun, 05 Jul 2020 00:00:00 +0000</pubDate>
			<category>Programming Theory</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/naturalsort/icon-sort.png'> 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. The point of the d. . . ]]></description>
			<guid>http://www.c64os.com/post?p=102</guid>
		</item>
	
		<item>
			<title>Supporting IDE64</title>
			<link>http://www.c64os.com/post/supportingide64</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Thu, 04 Jun 2020 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/supportingide64/icon-ide64.jpg'> 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. . . . ]]></description>
			<guid>http://www.c64os.com/post?p=101</guid>
		</item>
	
		<item>
			<title>Toolkit Class Hierarchy</title>
			<link>http://www.c64os.com/post/toolkitclasses</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Mon, 11 May 2020 00:00:00 +0000</pubDate>
			<category>Programming Theory</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/toolkitclasses/icon.png'> 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 r. . . ]]></description>
			<guid>http://www.c64os.com/post?p=100</guid>
		</item>
	
		<item>
			<title>Understanding SD2IEC Filenaming</title>
			<link>http://www.c64os.com/post/sd2iecfilenames</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Thu, 02 Apr 2020 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/sd2iecfilenames/logo-congratulationsW95.png'> Forward Note: 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 healt. . . ]]></description>
			<guid>http://www.c64os.com/post?p=99</guid>
		</item>
	
		<item>
			<title>CMD HD, SCSI2SD Upgrade</title>
			<link>http://www.c64os.com/post/cmdhdupgrade</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Tue, 03 Mar 2020 00:00:00 +0000</pubDate>
			<category>Hardware</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/cmdhdupgrade/cmdhd_scsi2sd.jpg'> 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 sourc. . . ]]></description>
			<guid>http://www.c64os.com/post?p=98</guid>
		</item>
	
		<item>
			<title>Stack Manipulation, Some Gotchas</title>
			<link>http://www.c64os.com/post/stackmanipulation</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Thu, 20 Feb 2020 00:00:00 +0000</pubDate>
			<category>Programming Theory</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/stackmanipulation/icon-boxstack.jpg'> 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 han. . . ]]></description>
			<guid>http://www.c64os.com/post?p=97</guid>
		</item>
	
		<item>
			<title>I2C Serial Bus in 6502</title>
			<link>http://www.c64os.com/post/i2c6502</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Tue, 04 Feb 2020 00:00:00 +0000</pubDate>
			<category>Technical Deep Dive</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/i2c6502/icon-i2c6502.png'> 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 . . . ]]></description>
			<guid>http://www.c64os.com/post?p=96</guid>
		</item>
	
		<item>
			<title>WoC19 Video playback with 1541 Ultimate II+ (2/2)</title>
			<link>http://www.c64os.com/post/woc19presentationsreview2_2</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 31 Jan 2020 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/woc19presentationsreview2_2/icon-headshot.jpg'> This post is part 2 of a two–part follow up to my review of World of Commodore 2019. If you're interested and you haven't yet read part 1, WoC19 Introduction to C64 OS, please check out that post. 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'. . . ]]></description>
			<guid>http://www.c64os.com/post?p=95</guid>
		</item>
	
		<item>
			<title>WoC19 Intro to C64 OS (1/2)</title>
			<link>http://www.c64os.com/post/woc19presentationsreview1_2</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Tue, 28 Jan 2020 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/woc19presentationsreview1_2/icon-headshot.jpg'> 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 Lug. . . ]]></description>
			<guid>http://www.c64os.com/post?p=94</guid>
		</item>
	
		<item>
			<title>World of Commodore '19</title>
			<link>http://www.c64os.com/post/worldofcommodore2019</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Wed, 15 Jan 2020 00:00:00 +0000</pubDate>
			<category>Editorial</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/worldofcommodore2019/icon-pets.jpg'> 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 return appearance. 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. . . . ]]></description>
			<guid>http://www.c64os.com/post?p=93</guid>
		</item>
	
		<item>
			<title>1351 Mouse, and Mouse Driver</title>
			<link>http://www.c64os.com/post/1351mousedriver</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Wed, 18 Dec 2019 00:00:00 +0000</pubDate>
			<category>Technical Deep Dive</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/1351mousedriver/icon-1351.jpg'> 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. . . ]]></description>
			<guid>http://www.c64os.com/post?p=92</guid>
		</item>
	
		<item>
			<title>Raster Interrupts and Split Screen</title>
			<link>http://www.c64os.com/post/rasterinterruptsplitscreen</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Wed, 30 Oct 2019 00:00:00 +0000</pubDate>
			<category>Technical Deep Dive</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/rasterinterruptsplitscreen/icon-modeswitch.png'> 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 di. . . ]]></description>
			<guid>http://www.c64os.com/post?p=91</guid>
		</item>
	
		<item>
			<title>Utilities and the Utilities Menu</title>
			<link>http://www.c64os.com/post/utilities_menu</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Tue, 08 Oct 2019 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/utilities_menu/icon_utilitiesmenu.png'> 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. Applicatio. . . ]]></description>
			<guid>http://www.c64os.com/post?p=90</guid>
		</item>
	
		<item>
			<title>Drivers and Relocatable 6502 Code</title>
			<link>http://www.c64os.com/post/relocatable_6502</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Mon, 30 Sep 2019 00:00:00 +0000</pubDate>
			<category>Programming Theory</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/relocatable_6502/plugin_6502.jpg'> 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 . . . ]]></description>
			<guid>http://www.c64os.com/post?p=89</guid>
		</item>
	
		<item>
			<title>C64 OS Networking and Chess</title>
			<link>http://www.c64os.com/post/chess_c64os_networking</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 20 Sep 2019 00:00:00 +0000</pubDate>
			<category>Technical Deep Dive</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/chess_c64os_networking/chess.jpg'> 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. . . ]]></description>
			<guid>http://www.c64os.com/post?p=88</guid>
		</item>
	
		<item>
			<title>SD2IEC User's Manual</title>
			<link>http://www.c64os.com/post/sd2iecdocumentation</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Tue, 03 Sep 2019 00:00:00 +0000</pubDate>
			<category>Reference</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/sd2iecdocumentation/sd2iec-users-manual.jpg'> Document Version: 1.2 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 speci. . . ]]></description>
			<guid>http://www.c64os.com/post?p=87</guid>
		</item>
	
		<item>
			<title>Burning EPROMs with Promenade C1</title>
			<link>http://www.c64os.com/post/promenadec1</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 19 Jul 2019 00:00:00 +0000</pubDate>
			<category>Hardware</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/promenadec1/promenadec1.jpg'> 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 d. . . ]]></description>
			<guid>http://www.c64os.com/post?p=86</guid>
		</item>
	
		<item>
			<title>Object Orientation in 6502 (Take 2)</title>
			<link>http://www.c64os.com/post/objectorientationin6502_2</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 12 Jul 2019 00:00:00 +0000</pubDate>
			<category>Programming Theory</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/objectorientationin6502_2/hierarchy.jpg'> 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 avoi. . . ]]></description>
			<guid>http://www.c64os.com/post?p=85</guid>
		</item>
	
		<item>
			<title>Versa64Cart and C64 ROMs</title>
			<link>http://www.c64os.com/post/versa64cart</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Thu, 13 Jun 2019 00:00:00 +0000</pubDate>
			<category>Technical Deep Dive</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/versa64cart/versa64cart.jpg'> 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 f. . . ]]></description>
			<guid>http://www.c64os.com/post?p=84</guid>
		</item>
	
		<item>
			<title>The 6510 Processor Port</title>
			<link>http://www.c64os.com/post/6510procport</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 10 May 2019 00:00:00 +0000</pubDate>
			<category>Technical Deep Dive</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/6510procport/MOS6510-processorport.jpg'> The 6510 is a variant of the 6502 CPU produced by MOS Technologies. People who have heard of the 6502 often associate it with the classic systems, NES, Apple II and C64, for example. The 6502 was used in the VIC–20, and also used in disk drives like the 1541, but the C64 is actually powered by the 6510. There isn't a huge difference. The 6510 has the same instruction set as the 6502, so any books and tutorials about programming the 6502 apply (almost without exception) to the 6510 as well. So why does the C64 use the 6510 then? The reason is because the 6510 includes an additional 6–bit port. In the context of the C64 as a whole, this is referred to as the Processor Port, because it's the port found on the processor. The 6510, like the 6502, is an 8–bit CPU. But what does that 8–bit refer to? Its data bus is 8–bit's wide, and most of its internal registers, Accumulator, X and Y index, Status and Stack Pointer are all 8–bits wide. Also, all of the arithmetic instructions, ad. . . ]]></description>
			<guid>http://www.c64os.com/post?p=83</guid>
		</item>
	
		<item>
			<title>File-Based Clipboard</title>
			<link>http://www.c64os.com/post/filebasedclipboard</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Thu, 02 May 2019 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/filebasedclipboard/clipboard-file.jpg'> I'll begin with a quick progress update. With the exception of the Widget Toolkit, the core C64 OS is very stable and nearly built out. I now find myself working almost exclusively (the topic of this post being a recent exception) on the applications and utilities that I want to be included as part of the OS. I have a list of utilities that I plan to create, and I've made some detailed UI mockups on graph paper (my favourite UI prototyping medium). Some of these utilities will depend on the Toolkit and in fact will be the playground and dogfooding of the Toolkit. Others do not need the toolkit and so I've been focused on banging a few of those out. For example, I've made the About C64 OS utility, and the About This App utility. And most recently I've been working on the Scientific Calculator utility. The calculator turned out to be trickier than I thought it would be, as I first had to reverse engineer the behavior of calculators, and found to my surprise that they all behave subtley d. . . ]]></description>
			<guid>http://www.c64os.com/post?p=82</guid>
		</item>
	
		<item>
			<title>Modifying the uIEC Deluxe Daughter Card</title>
			<link>http://www.c64os.com/post/modifyuiecdeluxedaughtercard</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Mon, 22 Apr 2019 00:00:00 +0000</pubDate>
			<category>Hardware</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/modifyuiecdeluxedaughtercard/deluxedaughtercard.jpg'> In late 2016, when I was setting up my workspace for Commodore computers, programming and all sorts of other retro mancave-style fun, I decided to build a couple of wood stands for monitors. Here's the post, A Workstation Stand. I got the idea from another site, BYTECellar. Anyway, they've turned out to be pretty great stands. The top surface is on an angle so it holds the display nicely facing up towards me, and conceals all the wires and other crap coming out of the back of the c128. I built a second one for a C64, too. The top surface has a bit that juts out beyond where I put the monitor too. This is a useful little shelf for pencils and programming notes. But there was one annoying problem. I've got the uIEC with deluxe daughter card from Retro Innovations, which is a nice little implementation of SD2IEC. The deluxe daughter card plugs into the cassette port for power, and to anchor to the back of the computer. And then the uIEC/SD plugs into it via a 1x13 pin terminal block. The . . . ]]></description>
			<guid>http://www.c64os.com/post?p=81</guid>
		</item>
	
		<item>
			<title>Webservices: HTML and Image Conversion</title>
			<link>http://www.c64os.com/post/conversionservices</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Mon, 22 Apr 2019 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/conversionservices/image_handling.jpg'> Near the end of 2016 I had some wide-eyed ideas about using the C64 Gfx library as part of a online service for converting images. I have since developed that idea into an actual functional webservice that has been online for a many months. But I wanted to take a few minutes to talk about how it works and how it fits into a wider suite of services. The place to checkout is http://services.c64os.com/about. This is the page that officially documents the services that are available. It currently documents and image conversion service and a relocated SID catalog. I'll write a separate post sometime in the future about the SID catalog. For now, let's discuss some of the other services. The Internet I want my C64 to be able to reach and consume as much of the internet as possible. The concept of the internet, a global interconnected network of heterogeneous platforms, sharing common protocols and exchanging common file formats, is brilliant. But, one big problem is that beginning many years . . . ]]></description>
			<guid>http://www.c64os.com/post?p=80</guid>
		</item>
	
		<item>
			<title>Context Drawing System</title>
			<link>http://www.c64os.com/post/contextdrawingsystem</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Wed, 27 Mar 2019 00:00:00 +0000</pubDate>
			<category>Programming Theory</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/contextdrawingsystem/contextdrawing.jpg'> I mentioned very briefly in the previous post that I've been working on the context drawing system for C64 OS. Believe it or not, I first mentioned the context drawing system in September 2017, in the post Organizing a Big Module. Back then, I said this: Drawing, in general, is a complex topic. So it's really hard to cover in a single post. I will eventually dedicate an entire post just to talking about how the drawing system works. Gregory Naçu — September 2017 Well, the time has arrived. This is that post in which I will go into detail talking about the context drawing system. The state of flux has calmed down and it is now pretty much in the state that it's going to stay in. The locations and names of the system calls have been worked out as well as the parameters they take. So let us dive into context drawing systems. The Hardware Level Whether we're talking about a text–based screen or a graphics–based screen there is at bottom a hardware level. Physical memory, out of whi. . . ]]></description>
			<guid>http://www.c64os.com/post?p=79</guid>
		</item>
	
		<item>
			<title>Another Progress Update</title>
			<link>http://www.c64os.com/post/progress_update1</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 22 Feb 2019 00:00:00 +0000</pubDate>
			<category>Software</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/progress_update1/krcc-logo.jpg'> Some time has passed since my last post, near the middle of January. I like to keep up a pace of at least two posts a month. And I'm loath to slip behind in that goal. But, a rather nasty gastro bug that whipped through me, my wife and kids kept me out of action for well over a week. Combined with a particularly busy week at work this month, and time has been a bit short. But there is also an exciting reason why the blog has been silent for a few weeks. I've put a lot of work into another major update to the Commodore 8-Bit Buyer's Guide. So I'd like to start with some updates about that. Then I'll move on to some updates about C64 OS, and even some fun news about C64 Luggable and the local Kingston, Ontario community. Commodore 8-Bit Buyer's Guide Let's start with why I decided to create the guide in the first place. When I came back to the Commodore scene after a hiatus of several years, my biggest surprise—and delight—was the discovery of how much activity there was. New games a. . . ]]></description>
			<guid>http://www.c64os.com/post?p=78</guid>
		</item>
	
		<item>
			<title>C64 KERNAL ROM: Making Sense</title>
			<link>http://www.c64os.com/post/c64kernalrom</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 11 Jan 2019 00:00:00 +0000</pubDate>
			<category>Reference</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/c64kernalrom/kernal_rom.jpg'> The KERNAL is the heart of the Commodore 8-Bit computer family. Although each machine's KERNAL is slightly different, there is also substantial overlap in code and design. The C64's KERNAL provides a standard jump table with 39 routines from $FF81 and $FFF3. The order of the entries in the jump table is stable, but not particularly logically organized. Most websites and books, including the C64 Programmers Reference Guide, list the routines in alphabetical order, or in the order in which they appear in the jump table. This makes it easy to find the details of any routine, if you already know which routine you want to use, but it can often lead to confusion trying to understand the relationship between the routines. Especially because many of them have similar sounding names, and in some cases similar functionality. To improve clarity, and facilitate understanding of how the KERNAL should be used, I have grouped the routines into 7 conceptual KERNAL modules, shown in the table below. C6. . . ]]></description>
			<guid>http://www.c64os.com/post?p=77</guid>
		</item>
	
		<item>
			<title>Exceptions, Try/Catch 6502</title>
			<link>http://www.c64os.com/post/trycatch6502</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Fri, 04 Jan 2019 00:00:00 +0000</pubDate>
			<category>Programming Theory</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/trycatch6502/exceptions.jpg'> I've been thinking about how to implement exception handling on the C64, for C64 OS. Exception handling would be useful for streamlining the handling of errors, and also for gracefully handling an application crashing under known exceptional conditions, with the ability to peacefully return back to the system's homebase application. In this post, I'm going to talk about about why you would want to have exceptions, how they can improve your program design, and how they might be implemented for C64 OS. Overview of Basic Program Flow Control We're all familiar, even just from BASIC, with the usual program flow mechanisms. Execution of a program flows from top to bottom executing each step one after the next. The next simplest way to change program flow is with a branch which allows skipping over some code if a certain condition is not true. In BASIC this can be done with an IF statement that jumps over some code, to the following code. The next most simple program flow control is the loop. . . ]]></description>
			<guid>http://www.c64os.com/post?p=76</guid>
		</item>
	
		<item>
			<title>World of Commodore '18</title>
			<link>http://www.c64os.com/post/worldofcommodore2018</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Thu, 20 Dec 2018 00:00:00 +0000</pubDate>
			<category>Editorial</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/worldofcommodore2018/ultimate64.jpg'> Happy holidays Commodore 8–Bit, Amiga and Retro Computer fans! It's become something of a tradition now for me to write a review of the World of Commodore Expo put on every year in Canada by the Toronto Pet User's Group, TPUG. My first review was of WoC 2016, the year I came back to the scene after a lengthy hiatus. At the time, I was just excited and it felt like something meaningful to review. Last year I wrote an even longer review of WoC 2017. I wasn't sure if I'd keep it up and turn it into a tradition, but, I guess I have, so here we go. The Road Trip Every year is a negotiation with my wife, how much time do I get to myself, how much time should I be devoting to my family. My first year back I was only able to go for the Saturday, and last year, I was unfortunately only able to make it for the Sunday. This year was my time. I had stuff to show, parties to attend, people to drink booze with and computer games to play! I said, Honey. I've been blowin' money left, right and cente. . . ]]></description>
			<guid>http://www.c64os.com/post?p=75</guid>
		</item>
	
		<item>
			<title>Commodore Hardware Information</title>
			<link>http://www.c64os.com/post/commodorehardwareinformation</link>
			<author>gregorynacu@me.com (Gregory Nacu)</author>
			<pubDate>Wed, 21 Nov 2018 00:00:00 +0000</pubDate>
			<category>Reference</category>
			<description><![CDATA[ <img src='https://s3.amazonaws.com/com.c64os.resources/weblog/commodorehardwareinformation/4-machine-collage.jpg'> This post is divided into three sections. The first gives the CPU, memory, video and audio specifications for all models of C64 and c128. The second provides a list of common storage devices with information about their transfer speed, physical interface and software loader. The last section is a list of common storage devices along with their media type, capacity and additional usage notes. Contents Basic Information: C64 and c128 Storage Solutions, Approximate Speeds Drive Sizes and Capacities Basic Information: C64 and c128 &nbsp; C64 1 C64c 2 SX-64 3 c128 4 c128 D 5 c128 DCR 6 CPU Speed PAL: 985,248.4 Hz NTSC: 1.022727 MHz PAL: 985,248.4 Hz NTSC: 1.022727 MHz PAL: 985,248.4 Hz NTSC: 1.022727 MHz PAL: 985,248.4 Hz or 1.9704968 MHz NTSC: 1.022727 MHz or 2.0454545 MHz PAL: 985,248.4 Hz or 1.9704968 MHz NTSC: 1.022727 MHz or 2.0454545 MHz MIPS(varies by instruction) PAL: 0.1407143 to 0.4926242 NTSC: 0.1461039 to 0.5113635 PAL: 0.1407143 to 0.4926242 NTSC: 0.1461039 to 0.5113635 PAL: 0.. . . ]]></description>
			<guid>http://www.c64os.com/post?p=74</guid>
		</item>
	
		
	</channel>
</rss>