Written and Maintained by Gregory Nacu

NEWS, EDITORIALS, REFERENCE

Subscribe to C64OS.com with your favorite RSS Reader
November 9, 2018Programming Practice

Character Animation

If you've been following along, you may know the progression of thought I've undergone with regards to the use of a custom character set. Initially, I argued in A Modern Character Set that it would be worthwhile using the Character ROM, because it would save us 2K of space. Then more recently, just earlier this year, I documented my change of heart in Rethinking the Memory Map. By rethinking the memory map, I found a way to crame in a custom character set without truly sacrificing a full usable 2K of memory. That's because, not ever kilobyte of addressing space is exactly like every other, on the C64.

Designing C64 OS around the use of a custom character set has a few advantages:

  • Missing ASCII characters can be added (\, ^, { and } for starters.)
  • UI elements can be drawn in some spare characters
  • Special symbols such as the Commodore logo can be used on menu shortcuts
  • And, an alternative font can easily be swapped in

A custom font has opened the door for other creative possibilities I had considered before.

Character Range Breakdown

If any of this is unclear, be sure to checkout my programming reference posts on PETSCII Codes, Screen Codes, and a the Vic-20 / Commodore 64 SuperChart. Briefly, there are 256 screen codes, each a unique visual glyph, with one minor exception: space is identical to its reverse. The second set of 128 are the reverse of the first 128. So, there really are just 128 characters, as each character needs its reverse. 128 divides neatly into 4 groups of 32 characters. An operating system, meant to interact with the modern world of networked services, communications and productivity apps, definitely needs both uppercase and lowercase characters.

These are grouped roughly as, the first group of 32 characters are the lowercase letters, plus 6 typographical symbols. The second group of 32 characters are more typographical symbols, plus the digits 0 through 9. The third group of 32 characters are the uppercase letters, plus 6 more typographical symbols. For a total of 10 digits, 34 typographical symbols, and 52 letters.

November 9, 2018Help This Site Succeed

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 buying a Commodore Logo Patch 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

Want to support my hard work? Here's how!

November 2, 2018Programming Theory

Floating Point Math from BASIC (2/2)

This is Part 2 of a two part post on BASIC and floating point math. Originally I wanted to talk only about math and floating point numbers. However, because of the integration of floats into BASIC, I wanted to give a quick overview of how BASIC stores variables and manages memory. This prelude ended up being kind of long, so I split the post into two parts. If you haven't read part one yet, I recommend you read that first.

My interest in floating point math is because I want to use it in C64 OS. But it could just as easily be applied to any machine language program on the C64, which doesn't use BASIC but does not want to reimplement the concepts and the routines of floating point math. The first use case I have in mind is for a Scientific Calculator Utility.

Zany mock-up of a Scientific Calculator.
Here's a zany mock-up of how that could look.

C64 OS extends the KERNAL, it doesn't completely replace it. While some routines of the KERNAL are never called, others are absolutely depended upon. Despite this dependence, the KERNAL ROM can at times be mapped out, so C64 OS can make use of the RAM underneath. It uses this RAM either for Utilities or alternatively for bitmap data. There are rules to follow when mapping out the KERNAL so things continue to run smoothly. The same is true for use of the BASIC ROM in C64 OS, but with a few important differences.

Any operating system, or really any program, needs to decide how it will deal with the overlapping of ROMs and I/O with potentially usable RAM. As discussed in part one of this post, the standard C64 OS (KERNAL ROM and BASIC combined) "deal" with this overlap by ignoring a huge portion of RAM. 24K of 64K is essentially just never used. The system modules of C64 OS itself take up precious RAM, therefore we want to have available as much RAM as is possible to use.

The PLA, controlled by the 6510's processor port, handles mapping the ROMs and I/O overtop of the underlying RAM's addressing space. Only certain mapping combinations are permitted. I've frankly always found this confusing, but find it much clearer when all the possible combinations are laid out in a table, such as this one:

October 23, 2018Programming Theory

Memory Management in BASIC (1/2)

I'm working away on C64 OS. And I've got a few things on my plate, but some things have to come before some others. Here's a quick summary of the current state of dev.

Nominally, I'm working on the class hierarchy of the Toolkit. And I'll return to this subject soon to discuss how that's developing. Before I can dig deeper into that, though, I need to improve the memory manager. There is a page allocator, which works well and I'm currently using only that for all my memory allocation needs. There are also the regular malloc() and free() routines that deal with arbitrarily sized chunks of memory from within a memory pool. A memory pool is typically a block of consecutive pages, that have been allocated by the aforementioned page allocator, and initialized.

At the moment, malloc() is quite primitive. It searches for a range of memory that's bigger than the requested chunk size, that has never previously been allocated, and it carves off a chunk of that memory turns it into an allocated chunk and returns a pointer to it. Free() can mark a previously allocated chunk as available. Additionally, if malloc finds a previously allocated chunk, that is exactly the same size as the current request, that is available, it can mark that as allocated and return it again.

But what it can't yet do is take a previously allocated chunk, that is available and bigger than the current request, and split it into two chunks; One which it marks as allocated and returns, and another that remains available but smaller. The memory manager also cannot (yet) merge two small consecutive free blocks into one larger free block. Shouldn't be too hard, it just hasn't been a priority until now. The Toolkit's classes are all kinds of varying sizes, and their instantiation depends on malloc. So malloc can no longer afford to be only half implemented. Before now, though, I haven't actually needed malloc for anything.

This post is part one of a two part post which begins by looking at Memory Management of the C64 and BASIC's role in managing its region of memory. Part two is about how to extract Floating point numbers and math routines from the BASIC ROM, without making use of, or triggering, the memory management and execution environment of BASIC, as a language.

ZeroPage

Okay, now let's take another step back. The 6502 depends HEAVILY on zeropage to perform many common tasks. Zeropage (memory addresses $0000 to $00FF) has been described, by at least one paper I read, as almost an extended register set for the CPU. Because, it isn't just faster to access but many instructions need it for some addressing modes. Essentially, all instructions that support the Indirect–Indexed, and/or Indexed–Indirect addressing modes, can do so only by referencing a pointer that is in zeropage. Many other instructions can use zeropage addresses both to save memory and for faster execution than doing the same thing in any other page.

October 4, 2018Hardware

NES to C64 Controller, Part 2

You're writing ANOTHER post about NES to C64 Controller modding? Are you serious? You just wrote one in August!

I know, but there have been a few interesting developments, so I figured I'd come back with a Part 2 to finish what I started.

If you want the background on how a NES controller works, and how this modification for C64 works, then you should read the original post on this topic, first, NES to C64 Controller Mod. This post goes into additional features. It shows how to make use of the Select and Start buttons on a C64, as well as the software to test it, and a video demo.

This post also relates to my C64 Luggable project. C64 Luggable has 4 joystick controller ports on the front panel. I knew from the beginning of that project that I wanted it to have a PS/2 Mouse port on the back, plus 4 joystick controller ports on the front. You know, to make it the ultimate C64 party machine. Plus four controller ports makes it look extra cool. You can read about the front controller ports of C64 Luggable here: Front I/O: Controller Ports.

Now, if you're going to have a custom machine, with a built–in display, built–in speakers and a handle on top, you really want to have four joysticks that look like a set that belongs with the machine. All my other joysticks are a motley collection, one each of a wide assortment of totally different shapes and styles. Back in the day I'd converted a Nintendo NES controller for use on my C64, and that one, of all the joysticks I have, became my favorite and my go to controller for almost any game.

Wouldn't it be great to have a set of four perfectly matching NES controllers to go along with C64 Luggable? That was the goal I had in sight.

The in-progress Front I/O panel of C64 Luggable, with 4 controller ports.
The in-progress Front I/O panel of C64 Luggable, with 4 controller ports.
September 24, 2018Programming Theory

Distributed Jumptable

I've suffered a minor setback, I'd say it put me back maybe a week. Our work office was broken into last weekend. Front window smashed. My 2016 MacBook Pro was stolen right off my desk. Fortunately I had most things backed up. I didn't lose anything Commodore related, or anything personal really. But I have had to spend some significant amount of time reconstructing my work environment on a new iMac.

Also, very frustratingly, I lost perhaps a month of development on my current work project. As the sole developer, I wasn't committing to SVN very regularly. Which is something I'm going to start doing, probably once a week, in light of the rude awakening that fires and spinning disk failures are not the only way to lose data. Now back to the post I was working on.


Sometimes I feel like I'm climbing a mountain 1 inch at a time. This post is about some changes I've made to how the system jumptable works, and how modules are linked together.

I've been here before, and wrote about this general theme of development in at least four previous posts: (In chronological order, oldest first.)

To recap, C64 OS uses the C64's KERNAL ROM, and adds its own KERNAL on top of that. The C64 OS KERNAL is divided across 10 modules. These are units of code that get assembled independently, and that export routines that can be called either by other modules, or by application code.

The set of modules has been fairly stable for a while now, and consists of:

C64 OS KERNAL
Memory String Math File Timers
Input Screen Menu Service Toolkit

When assembled, all the modules pack together and end at $CFFF. As I write more code the amount of space the KERNAL consumes continues to grow down into memory. It currently ends somewhere around $A800. Which means it's approximately 10K. 6K overlaps where the BASIC ROM normally sits. And 4K in himem from $C000 to $CFFF.

August 27, 2018Software

Menu/Status Bar: File and Memory

I'm feeling good that I'm back on pace with my posting rhythm. This is my third post in August. Today I just wanted to show off a system feature that I built in last month or so. It's the system status bar, as well as new global, configurable keyboard shortcuts. And this also includes some work on the File and Memory modules to support the status bar.

Let's just dig right in. I was anticipating that this would be a briefer post than some of my others, but it's me after all. I'm very wordy and detailed. So, this may turn out to be longer than I'd originally expected.

Drive Status

You know, it's funny, I've been using a C64 since I was 9 years old, and it never fully dawned on me until just recently the importance of reading the drive's error channel.

As I discussed at some length in the post from earlier this year, KERNAL, File Refs and Services, the C64 itself really doesn't know anything about files or file systems, or anything else about disk management. I argued then that this is a strength, when you consider the nature of the system. The machine is small, with limited RAM and even less ROM. And yet, it can easily make use of modern storage media like CD roms, SD Cards, CF Cards and hard drives. This is because the DOS is entirely offloaded into the device.

The C64 merely opens a connection over the serial bus, and sends commands over the command channel. This allows the C64 to read and write files, and issue commands to the device's DOS to let it handle the nitty details of manipulating the data on the storage medium.

Consequently, though, the C64 itself doesn't know very much about error states in the devices it talks to. There are a couple of conditions it handles. For example, if you try to access a device number that doesn't exist, well, the C64 knows about that. And if you're reading in bytes and you hit the end of the file, the C64 knows about that too. But, imagine that what you really want to do is change a directory, then create and open a file, write some data to it, and close it. To do this, the C64 must send the change directory command, over the command channel, prior to trying to open the file. If all goes well, the file will end up being created inside the subdirectory.

But what happens if things don't go as planned? What happens if, for some reason, the directory doesn't exist? What will happen is that the C64 will issue the change directory command. That will produce an error internal to the drive, about which the C64 knows absolutely nothing. If the C64 then simply proceeds to open/create the file, it will be created in the wrong place. Even worse, if you open with an overwrite flag, who knows, you might accidentally overwrite a file with the same name that's not even supposed to be there, because you're not where you think you are.

There is only one way to deal with this: Read the error channel, religiously.

It's not like this hasn't been known for 40 years, it's right there in the User's Guide. But, when you actually get into the details of programming, somehow things that have always been there but that you've never thought much about suddenly pop up become noticeable.

1541 Users Guide, read the error channel.
Taken from 1541 User's Guide at archive.org.
August 15, 2018Hardware

NES to C64 Controller Mod

Just a few short years ago, it was almost a total mystery to me how the electronics of NES, SNES and other controllers worked. C64 controllers are easy. There is one wire for every button, plus one wire for ground. You push a button and that button's wire is connected to ground. 5 buttons plus ground is 6 wires. The 5 controller wires lead directly to pins on the CIA chip for either its Port A or Port B. The CIA port pins internally pull up, so every IRQ cycle your program can read them to see if they're low. Any port pin that's pulled low is because the button is depressed connecting it to ground. Simple.

But, how do these controllers with many buttons communicate with the computer? Especially when they have fewer wires but more buttons than a C64 controller. By what magic does this work?

This is gonna get a bit technical. Better buckle up!

How does the NES controller work?

First off, if you don't know much about digital electronics, but you really want to learn more, I recommend reading this: All About Circuits – Textbook – Vol IV – Digital

The whole site is basically free online education. Volume 4 of the textbook walks you through everything you need to know about digital electronics. I learned more about electronics from that tutorial than I had in my whole life up until that point. From there, the large fold–out C64 schematics, that came in the spiral bound C64 Programmers Reference Guide, actually started to make sense. And I began to be able to lookup the spec sheets on the chips to see how they work.

The short answer for how these controllers work, is that they use a shift register. But, to understand what a shift register is, we have to understand a number of more primative components. Let's quickly go over the components that combine together to build up to a shift register.

August 9, 2018Software

Introduction to Utilities

Alright. I don't want lose my cadence of approximately two posts a month. However, I've got a much needed summer vacation coming up in a few days which cuts this month short. I've got a couple of small news items to cover first.

Whoops, I didn't get this post finished before my vacation. So, this post didn't make it into July.

1) I recently got some more work done on C64 Luggable, and its documentation. The table of contents is now pretty much filled out, and I've published a new section, Front I/O. If you missed the announcement on Twitter and you're following along or interested in my progress on that project you can read about it here.

2) I have started to organize the C64 OS section of this site. It's mostly for technical documentation for programming, but it'll also include user documentation. I haven't written much content for it yet, but I've reorganized it so it is structured very similarly to the documentation for C64 Luggable. Sidebar table of contents, separate page for each section, with forum comments and analytics on each page. This will give me a place to start writing real documentation, that will be final for v1.0.

3) Speaking of v1.0. I'm still quite a ways off, many months I would guess. But I can see glimmerings of light at the end of the tunnel. For a long time, I was just coding and coding and I couldn't even run my code. It only worked in theory, even though a lot had been written. In this last few months things have really come together. The code is working, the system is running and I'm able to see and try out the fruits of my labor. If you've been following on Twitter, I've been able to bang out some utilities fairly quickly. And I've been doing the design work for several more. Finally being able to work on code that is not part of the KERNAL is a huge relief.

4) As if my attention isn't split enough ways already, I've also been putting some thought and time into packaging, and distribution of C64 OS v1.0. I've been doing some research on other OSes, (GEOS 1.0 and 2.0, Wheels, Risc OS, and early versions of Mac OS and Windows) to see what commonalities they have, and what applications and accessories they shipped with. I'm setting realistic targets for a core set of applications, utilities, and extras to include in C64 OS that I can A) actually accomplish, but that B) will make a compelling offering. Along with this, I've been writing the first draft of a User Manual. I'm formatting it for 5.5" x 8.5"1 and looking into reasonable production options. I've also decided to distribute C64 OS on 16 megabyte SD Cards, (sorry, not 1541! and not .D64) which will be affixed to the inside cover the User Manual. I'll have a lot more to say about this in future posts.

Now on to Utilities!

July 16, 2018Programming Theory

Command and Control

In the last month of so, I've been working on Utilities, how they are loaded and how they are quit. How they load and save their configuration data, and how they efficiently redraw. I want eagerly to write in detail about Utilities and get into the details of how everything comes together around them. However, before I do that, I've got to take a bit of time first to document my plans and work on something a bit more low level. I've been thinking about what exactly to call this lower level system, and I've decide to call it Command and Control.

Command and Control is the flow of execution, the order of event processing, and the execution of processes and timers. I've discussed in other posts already many of the elements that will be covered in this post, but this post will bring them together into a more coherent picture. Also I've done more of the programming legwork since the time when I was just planning. Some ideas have gone by the wayside and others, I've never mentioned before, have crept in. So, no need to go any more meta than that, let's just talk about the details.

Interrupt Service Routine and Events

Whatever the CPU happens to be working on, the details of which we'll get into below, the IRQ is triggered by CIA1 60 times a second. This is the standard time, the KERNAL also configures the system this way at start up. The main system timing is therefore built around 1/60th of a second.

The interrupt service routine makes use of I/O and the KERNAL, and so it is essential that these are mapped in whenever it is time to service the IRQ. When the CPU is interrupted, it hops through an IRQ vector which it finds at the end of memory, $FFFE and $FFFF.1 You don't have much control over the state of the machine when an IRQ goes off. But you do have some. Initially, if I ever needed to patch out the KERNAL I would be very meticulous about calling SEI (SEt Interrupt mask bit), so that IRQs would be ignored. And then after patching the KERNAL back in calling CLI (CLear Interrupt mask bit). Unfortunately, this is not without its issues.

Clip of Mapping The C64 and C64c, showing hardware vector addresses.
From, Compute!'s Mapping the Commodore 64 and C64c, pg.245

It is the Interrupt Service Routine that reads and updates the position of the mouse cursor. If you disable interrupts for too long, the consequence is that the mouse becomes jerky and unresponsive. It is really a subpar experience.

June 26, 2018Technical Deep Dive

Menu Systems, a comparison

Well, at the very least, this post has got the right number!1 Although I don't know if its content will live up to the hype of the number, I do have some fun stuff to show today. We'll be looking at the menu system in C64 OS, seeing it in action, and doing a comparison to GEOS. It's just as a friendly comparison, since GEOS is the quintessential OS-with-menus that people think about on the C64. So, how do they stack up?

The menu system was something I started designing a long time ago. In my head it was something I knew I wanted to have, and I spent a good deal of time pondering how it could all come together. Consequently, the menu system has been mentioned many times and is the subject of at least two posts from early last year. Recursion and C64 OS's Menu UI (3/3) from March 1st, 2017 when I did a technical deep dive on writing recursive code in 6502 ASM. And then again on May 9th 2017, in Pointers in Practice, Menus, which was a programming theory post about pointers and how they can be used in creating hierarchical data structures.

I'll be the first to admit that I'm apparently a slow coder. In the earliest days it was a huge hill for me to climb to understand how to do anything in assembly language. And I went through many stages of reforming the code in order to be able to sustain large project development coding natively on the C64 itself. Additionally, I've really had to educate myself about each new aspect of the computer as I've gone. Learning about how the CPU works, and the VIC modes, and how memory is mapped, and how the CIAs can be programmed, and how to use interrupts, etc. It's been quite a trip.

But it has all come to fruition. I had the menus actually functioning and doing what I wanted them to starting maybe 3 or 4 months ago. Since then I've been adjusting them, and experimenting with what I can do with them in the context of writing a real world application, or the new C64 OS utilities. This has lead to the addition of numerous small features and behavioral tweaks to get them to where they are now. I'm finally ready to show them in action, and I'm really eager to get into a technical discussion about how they work and all that you can do with them. So let's dig in.

Older Posts

Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.

June 5, 2018Editorial

Review: 1541 Ultimate II+

April 25, 2018Programming Theory

Mouse Acceleration

April 19, 2018Programming Practice

Double Click and Timers

April 16, 2018Programming Theory

Timers, One More Time

April 2, 2018Programming Theory

Switch Macro



View full archive ⇒

Want to support my hard work? Here's how!