Well, as some of you know (by some, I mean maybe two people at most), I've been working on projects to explore various OS API implementation techniques using the Commodore 64 as the test-mule, especially with an eye towards implementation of these concepts on the Kestrel 2. One particular project is called Colonel, and its stated goal is to add a hierarchial namespace to the Commodore 64 environment while minimizing the alteration to the existing runtime environment. By hierarchial namespace, I'm talking about something like Unix, where files, directories, and device drivers are all presented uniformly in a hierarchial system of naming.

Colonel works by revectoring all of the kernel's I/O functions. Commodore thoughtfully put their vectors in RAM back in 1977, with the introduction of the first PET computer. Therefore, Colonel can, in theory, actually run on a PET-2001. Only the load address needs to be changed, as far as I can tell.

Colonel appears as GPIB device 255. Attempting to open device 255 without a filename will always result in a device not found error. If a filename is given, Colonel will attempt to locate the best-matching candidate mount point handler and ask it to actually perform the open operation. Otherwise, it will return a device not present error.

I use the colon as the path separator because slashes are permitted in disk filenames (which makes the LUnix-style /disk8/foo/bar pretty ambiguous -- is it referring to a file bar in directory foo? Or is it a file truely called foo/bar?). Also, there is no need for the leading slash or colon because filenames are always anchored at the root (due to the ROM kernel not implementing any concept of current directories).

Anyway, with that bit of background, I just wanted to announce the successful completion of the new implemention of OPEN! It has been tested from both machine language and from Commodore BASIC V2.

CLOSE is not yet finished, but between OPEN and CLOSE, those are the two hardest kernel functions to patch. CLRCHN, CHKIN, CHKOUT, CHRIN, and CHROUT are all just dumb stubs to invoke the driver's equivalent functionality.

The total code for OPEN and its self-test code is less than 600 bytes. Without its self-test code, the binary comes to 338 bytes. I predict that OPEN and CLOSE combined will easily fall under 512 bytes. The implementation of the remaining functions can easily be done in less than 256 bytes. I'm willing to guesstimate another 256 bytes for the new "Kernel" functions BIND and UNBIND (which add and remove mount-points, respectively). Therefore, not including self-test code, Colonel will occupy no more than 1024 bytes (estimated). This has to be one of the highest "power to weight" ratios in software I've personally ever encountered, because those 1024 bytes allows for some pretty exciting opportunities, including true support for directories, soft-devices (e.g., reading DEVS:MOUSE:B0 and DEVS:MOUSE:P0 to get button and position reports from the mouse in joystick port 1, for example). And, because Colonel patches the ROM kernel's I/O vectors, BASIC sees the new functionality too.

Anyway, I'm just babbling, I suppose. I'm just glad that the new OPEN functionality works every bit as well as I thought it would.

Back to coding for the CLOSE function . . .

CLOSE has now been implemented.