NEWS, EDITORIALS, REFERENCE
The question driving the creation of this reference table is simple: If I press a key, or a key combined with one of the modifier keys (Shift, C=, or Control) what is going to appear on the screen?
Surprisingly, the answer is not straightforward. The keycaps of the Commodore 8-Bit family are famous for including a series of foreign–looking graphical symbols, sometimes on the key surface, sometimes printed on the front vertical face of the key. If you've ever used a C64, 128 or Vic-20, you know that in the mode immediately after turning the machine one, pressing a letter key will give you an uppercase letter, pressing shift and a letter will give you the right symbol of the two graphic symbols that appear on the key. Pressing C=Key and a letter will give you the left graphic symbol on the key.
But this is only the beginning. Many of the non–letter keys also have symbols, but not every symbol that you can generate with modifier combinations is represented on every key. And to make matters more complicated, switching the character set to uppercase/lowercase introduces other symbols that are not visible on the keycaps.
The tables below show what glyph will be produced on the screen for every key on the keyboard, in each of four possible modifications (Unmodified, Shift, C=, Control), in both character sets. See below for a full discussion.
|Row 1||Uppercase / Graphics||Lowercase / Uppercase|
|9||reverse on||reverse on|
|0||reverse off||reverse off|
|£||$1C, red||$1C, red|
|Row 2||Uppercase / Graphics||Lowercase / Uppercase|
|CONTROL||modifier key||modifier key||modifier key||modifier key||modifier key||modifier key||modifier key||modifier key|
|Q||$11, cursor down||$11, cursor down|
|E||$05, white||$05, white|
|R||$12, reverse||$12, reverse|
|T||$14, delete||$14, delete|
|I||$09, unlock||$09, unlock|
|↑||$1E, green||$1E, green|
* RESTORE generates a hardware NMI signal direct to the CPU.
Happy Valentine's Day, 6502 freaks. Here's a new genre of post, I've tagged this as: Programming Practice, because it gets right into the nitty gritty of a practical problem and the steps taken to fix it. This post includes a 30 minute video of a realtime debugging session. If a picture is worth a thousand words, well then, a video has gotta be worth something.
Late last month I posted my first video update. A video update is kind of cool because as I build out C64 OS, there will be more and more interesting things to see. And pictures are handy, but a video really gives you a flavor for how fast something is loading, or how the mouse is responding and how the screen is refreshing, etc.
In my video update, which was only a couple of minutes long, I held the camera in my left hand and worked the computer and the demo with my right. That's fine for a short clip, but to really get into the weeds you need your hands free and therefore a stand for your camera. I banged together a decent makeshift camera stand out of nothing more than a stiff metal coat–hanger, with a grippy rubber coating. My workspace is under a stairwell, so the ceiling is quite low. Hanging the coat–hanger from the ceiling works perfectly and positions it to point straight at the monitor.
Let's get into this video debugging session, and take a glance into some native coding.
I began this video knowing I had an interesting bug to find. It's interesting because it has a clear visual artifact and involves several low–level code modules that I'm working through for the first time.
Before I started my hunt for this bug, it struck me, this would be a great opportunity to catch the entire process in a video. I spend the first few minutes talking about the general layout of the source code and the convention I use for filename extensions. Then I spend maybe a minute describing the basic problem I'm having, and then we just hop right into using some tools, like DraBrowse64, Turbo Macro Pro, SuperMon64+ and JiffyDOS commands. The goal is to show how one goes about using the tools available on a C64 to hypothesize about the problem, run some tests, modify the code, reassemble and test again.
The video concludes with me being very self–satisfied, having diagnosed the problem, found the bug and fixed it, and showing that the result of the fix has removed the offending visual artifact.
WAIT, hold on. That's not the end of the story...
Shortly after concluding the video I decided I really should run it against a couple of additional test files. I very quickly noticed that I was getting unexpected results. Off video, I ended up going back into the debugging process, and after about 2 hours of testing some things out, I finally realized what the real source of the problem was. The fix shown in the video is completely wrong. It solves the visual problem by fluke, and in fact the entire on–screen display is wrong, symptomatic of the real problem, but it's only subtly wrong in a way that is hard to notice.
So, watch the video, and see how the tools work and the general process of debugging native code. And then read on below for a full description: What went wrong? How did I mis-diagnose the problem? How did my bogus fix look like it solved the problem? And what was the real problem and the real fix?
I want to talk about File References and the services provided to the developer by the File module in C64 OS. But to do that, we'll have to first take a brief tour through the IEC serial bus, the KERNAL and the C64's native I/O architecture.
To Rewrite or Not To Rewrite
First things first. C64 OS does not patch out the KERNAL ROM, it makes use of it for many low–level routines. Some of those routines include file handling. Many people who write an Operating System for the C64 make it one of their first and top priorities to rewrite the low–level file access routines. But I definitely don't want to do that. Why not?
- C64 OS is single tasking
- The C64 is already short on RAM
- Writing serial routines is hard
- JiffyDOS is already very fast
- C64 OS wants to be compatible and agnostic
If I can be allowed the pleasure of describing those points in prose, the bottom line is that writing serial routines is hard, and serial routines already exist in the KERNAL ROM. The RAM beneath the KERNAL's addressing space is still available to the machine,1 so anything you can make use of from the KERNAL, even if you only use 20% of the KERNAL, that's 20% of 8K. That's 1.6K of memory you can spend implementing something else that the KERNAL doesn't do.
Compute's 1st Book of C64: Block diagram of memory with I/O and ROM overlays.
Furthermore, the reasons people write their own file routines usually fall into a couple of categories. They want serial access to be faster, they're targeting a specific common device such as the 1541, or they're doing something more sophisticated than the KERNAL's routines can handle. These special needs might arise as a result of the the OS you're writing being more sophisticated, such as by supporting multi–tasking. C64 OS is single–tasking, that was a decision I made very early.
I want C64 OS to be able to use any type of device, IDE64, SD2IEC, 1541 Ultimate, 1541/71/81, CMD FD/HD/RL, etc. JiffyDOS, which if you don't have, you should get, already has routines that have been carefully thought out to get a good balance of greatly improved speed without sacrificing compatibility. I had a discussion with Jim Brain about how JiffyDOS's speed loading routines work, relative to how the custom speed loaders in some games work. Yes, some custom speed loaders can get more speed than JiffyDOS, but some of them also require you to have only one drive on the IEC bus, or will only work with a 1541 or 100% compatible clone. Those limitations might make sense for a demo or a game, but they are the sorts of tradeoffs that I would never make for a platform like C64 OS.
Check out this speed comparison between JiffyDOS and the original KERNAL rom. It's pretty stark.
I've been plugging away in the new year, trying to get the booter booting properly, and the ability to launch an app from an application bundle. So here's a quick video update of my progress so far.
What this video shows
The booter has run, it loads in all of the OS modules. It runs a drive detection routine and constructs a drive type to device number table in workspace memory.
The booter sets itself up as a standard app with a "quit app" jump table entry. Then it calls service routines to quit itself. This actually puts a vector to the "loadhome" service routine into the main event loop's EventLoopBreakVector. Typically this will cause the main event loop to end, and will jump to the routine to load the designated "home" application. But because we're just booting, the main event loop is not yet actually running. The quit app routine returns the pointer to loadhome in the X and Y registers. I refer to these in C64 OS now as a RegPtr. That's a standard 16 bit pointer, low byte in X, high byte in Y. The booter takes that returned pointer and jumps to it manually. This kicks off the load home routine.
Load home starts by allocating a page to be the application file reference (AppFileRef) for the about–to–be–launched app. It allocates new space because it needs to still have access to the AppFileRef for the about–to–be–quit app. Load Home then configures this new file reference with the device, partition and path to the currently designated home app's bundle. It then calls the loadapp service routine, with a pointer to the newly configured AppFileRef. In this way, the home app gets loaded just like any other app. And any app can load any other app directly, without needing to go back to the home app first. However, if you want to just quit the current app, there is a service routine that configures loading the home app for you. So it's very easy to leave your app and have the system return to the default home app.
The very first thing the loadapp routine does, is quit's the currently running app. In order to do this it jumps to the application's standard quit routine. The booter configured itself to have a standard quit jump table entry specifically so that things would go smoothly when loadapp tries to quit the booter. The booter's own quit routine doesn't need to do anything so it just RTSs.
Typically the quit routine gives the application one last chance to clean up, before it is forcibly removed from memory. It might be that it closes network connections, or saves open files to disk, or saves its own state back to its application bundle. In fact, that's the reason for maintaining the current app's AppFileRef, so it can use it during the quit phase to write data back to its own bundle.
After the previous app has completed it's quit routine, the current AppFileRef is deallocated and AppFileRef is pointed to the configured file reference for the app to be loaded. Then all application–level allocated memory pages are deallocated. Then the new app's menu file is loaded in, and the new menus are initialized. The menu initialization process deallocates the previous application's menu allocations. Memory allocations for the menu system are done at the system–level. So your application never needs to worry about setting up or taking down its own menus.
Then the application's main.o file is loaded in. And the pages that it occupies get marked as allocated (application–level.) Next, just as every application has a standard quit jump table entry, every application also has an initialization jump table entry. Load app then jumps to the freshly loaded main.o's init routine. At this early stage, I've setup app launcher as the default home app, but file manager will be next. App launcher's init routine is called. Typically it would configure its Toolkit widget UI, but I'm not there yet. It allocates space for a PETSCII image, which it then populates from a file background.pet which it finds as a resource in its own app bundle.
Next the init method sets up a screen layer struct which it pushes onto the screen layer stack. This defines its mouse and keyboard event handling routines, and its draw routine. The draw routine doesn't do much, except call textblit to copy its background PETSCII image to the screen. The mouse event routine is not yet forwarding to the Toolkit, but is instead just doing some primitive checks for where the clicks are happening. Clicking in the first column changes the foreground/background colors. Clicking in the middle of the screen changes the colors back.
Clicking in the second column puts the app into an infinite loop. This lets us test how the interrupt routine handles the situation where the app fails to return to the main event loop for a prolonged period of time. It kicks into action the CPU Busy animation, top left corner. We can see that working. It is animated by the interrupt routine. But as long as the the main event loop keeps running in a timely fashion, and events keep getting distributed, it continually updates a variable that prevents that IRQ handler from animating the CPU busy indicator. Pretty cool.
Once the app goes into an infinite loop, the main event loop is no longer running, and so events are no longer being distributed by their normal means. The interrupt handler is still updating the mouse and keyboard, though, and it's still buffering input events. The infinite loop code is scanning the key command buffer. As soon as there is a key command in the buffer it breaks the loop.
Most of these things are just a way for me to test various low–level features of the system. And things seem pretty stable. I'm making progress.
This table appears in The Complete Commodore Inner Space Anthology, pages 37 and 38. The data are rearranged here to best suit the format of a webpage, and a couple of pretty big errors in the Inner Space Anthology listing have been corrected. Corrections are noted below each block.
It is called a SuperChart because it lists the PETSCII, ScreenCode (both character sets), BASIC character/token, and 6502 operation for every value in the 8-bit range. The numeric values are conveniently given in both decimal and hexadecimal. I'm digitizing it so I can have access to it without having the reference text open on the desk in front of me, and tagging it here as Programming Reference for others to find. Hopefully someone out there will find this chart as useful as I do.
PETSCII, ScreenCodes and BASIC codes are roughly divided into 8 blocks of 32 characters each. For this reason, the chart is presented below as eight 32-row tables. See the end discussion for an explanation of PETSCII's block structure.
Bit 7 Low: %0xxx xxxx
- Block 1: 000 - 031: $00 - $1F
- Block 2: 032 - 063: $20 - $3F
- Block 3: 064 - 095: $40 - $5F
- Block 4: 096 - 127: $60 - $7F
Bit 7 High: %1xxx xxxx
- Block 5: 128 - 159: $80 - $9F
- Block 6: 160 - 191: $A0 - $BF
- Block 7: 192 - 223: $C0 - $DF
- Block 8: 224 - 255: $E0 - $FF
|29||1D||cur right||ORA X|
Corrections: Inner Space Anthology lists the block–1 alphabetic SCREEN CODES as only uppercase. They should be uppercase in the upper/graphics character set, and lowercase in the lower/upper character set, as shown above.
Corrections: Inner Space Anthology lists the SCREEN CODE $1C as a backslash. It should be the british pound symbol (£) as shown above.
Another year, another adventure. Long live the C64. Your second World of Commodore since returning to the scene cannot ever be as epic as the first one. But as the fates would have it, I would not be able to repeat last year even if I'd wanted to. This is my review of World of Commodore 2017. In a nutshell, friends and networking. Networking as in what people do when they get together? No, no, no. Digital, 8-bit, computer networking. Read on.
Last year the journey felt truely epic. I got up early on a Saturday, I brought my son along with me. I had no expectations, except bad ones, and when I arrived it was just one pleasant surprise after another. What could compare with that?
I've got several of hobbies that tug at my heartstrings and draw me out into the world, from Esperanto conferences to Star Trek CCG tournaments. Commodore Expos are a new(old) one to add to my list of places to go throughout the year. But my wife is always making me agree to compromises so that I actually, you know, spend time with her and our family. The dice were rolled, and this year the Archibald Family Christmas party at a cottage north of Peterborough came up on the same Saturday as World of Commodore's main day. Drat! I tried to argue that I've been working my butt off all year and that the one and only time and place that anyone on earth is going to care about what I've been doing is that very Saturday, in a hotel basement in Mississauga. I didn't get far along those lines. Besides, the show is a two day event, right?
So I went to the cottage on Saturday, December 9th. A 3 hour drive out, in the winter, and a 3 hour drive back at the end of the day. I was already exhausted and I hadn't even made it to the show. I packed up my C64 Luggable project, got some Commodore Logo Patches ready to bring with me and went to bed early. The next morning, I got up before the sun. Bid farewell to my wife and sleepy kids and hit the road.
I wasn't quite as excited as last year. I knew where I was going, I knew how long it would take me to get there. And I knew that the location was the same as last year so there weren't likely to be any big surprises. And there weren't. The weather was great, the drive was fast and easy, I stopped once for food and a bathroom, and I didn't even bother to get gas. By the time I pulled into the parking lot at the Admiral Inn my tank was on empty, and it was 10am sharp.
I left my equipment in the car, and didn't even bother to put on my coat. I just dashed across the frigid parking lot in my sweater, and into the hotel lobby. I ran past a guy loading a luggage cart stacked with 8-Bit Commodore goodness into the back of a van. Besides that and a tiny square sign with the chicken lips logo and an arrow pointing right, there wasn't much sign that anything was going on. I was a bit worried. Maybe last year was an exception? Maybe Bil Herd had drawn an uncharacteristically large crowd last year that would never be matched again?
I headed downstairs and found the sign in table completely unmanned, and no one was waiting to sign in. Damn it, did I miss the whole show?
Before I took five more paces, Jim Mazurek, a true 8-Bit soldier, who along with Eric Kudzin seem to go to supernatural lengths to make an appearance at every show, popped out from around the corner. He greeted me kindly, and broke some unexpected but hugely uplifting news. Dave Ross is here! Holy crap! Dave (Watson) Ross, one of my oldest online Commodore friends, together with Vanessa Dannenberg and David Wood (too bad they couldn't make it), was here in the flesh.
I took a couple of steps into the showroom and peeked around the corner to see what I could see. "No shit! Is that really Dave Ross I see sitting there?!" I called out. The same guy, only a decade older than the last time I saw him spun around and stood up with a smile on his face. After extending my arm to shake his hand, I thought, ah screw that, and gave him a hug. He could have been sitting completely alone in that giant room, and I still would have been happy to have made the journey.
A couple of quick thoughts. First, there is no doubt that this is a Sunday morning, the second day of a successful show. The tempo was way down from last year, but that was not a sign of less interest or smaller participation. Instead, the room was only partially populated by sleepy lookin' dudes who had just gotten out of bed from the partying the night before and strolled down to see what was going on. Many of the regulars, Joey and Leif, for example, weren't even there. John (CRT) Hammarberg, who I wrote about last year, was there, but he was packing up his gear and getting ready for the 6 or so hour drive back home. I barely had a chance to say hi, shake his hand and wish him a safe trip home. I also discovered that Jim Brain had not made it up this year. That's a bummer.
The second thing to point out though, is that the room was bigger. Like, two times as big. At first I was worried, were there no presentations this year? Last year the room had been divided in half by means of a folding partition that slides along a track in the ceiling. This year, that partition was neatly tucked away inside the hidden wall compartments, and the showroom floor was consequently much more spacious than last year. But, fear not, I soon found out, when the first presentation of the day was due to begin (which I'll go into later), that there is a whole separate room reserved and set up just for presentations.
This year the showroom was configured more like a giant 8 on an old digital alarm clock. The room was rectangular, like two squares side by side. Tables flanked the entire outer rim of the whole room. And in the middle, two inset squares, one for vendors the other for more demo machines.
Let's walk our virtual way around the room to the best of my memory. Last year I left a couple of people out who weren't super happy that I'd completely forgotten about them, but you know how it is with memory.
The first machine I cam across was a breadbox C64 with a conspicuously bright red 1541 Ultimate II+ hanging out the back. I got a look at it, and learned a few tidbits, such as that the onboard speaker plays sounds that make it sound like a spinning 1541 disk drive. To be honest, I'm not sure how much I like that, and I hope that feature can be turned off. The other thing I learned is that it's access to mass storage devices works a lot like the uIEC/SD. I'm still going to have to get my hands on one for testing and compatibility with C64 OS. I'd love it if this became the storage device in my C64 Luggable. Because it packs a lot into a small space, ethernet, USB Storage, REU emulation, Freezer Cartridge, and more.
Welcome back C64 and 6502 fans! This is my 50th blog post at c64os.com. Today will not be a highly technical post, but I have a lot of small things to talk about.
World of Commodore 2017
It's that time of year again. World of Commodore 2017 is just days away. Read about it here. I had a wonderful time refamiliarizing myself with everything that's new in the Commodore world at this show last year. It is sure to be a blast.
Unfortunately I can't make it on the Saturday, because of family obligations. But I will be there on Sunday, as this is a two day event. I'm not sure what I'll be bringing. I've been hard at work through the whole year, but nothing I've been working on is really ready. C64 OS has seen lots of work and now consists of lots of code, but there isn't much yet to demo. And C64 Luggable, which I'll likely bring with me, is not fully finished. But, I might bring it anyway, just to show people my progress. I know at least a couple of people are interested in where it's at.
Hopefully someone will notice, but I've put a lot of work over the course of the year, into building this website. In the last couple of weeks I have done a fair bit of work touching up the styles. I've normalized the fonts and the hierarchical usage of H1/H2/H3/H4.
I have also put quite a bit of work into getting the whole site to be responsive. This involved redoing the top navigation completely. This is now done entirely in CSS, no more graphics for those little bubble buttons. This allows the top navigation to scale smoothly down to mobile phone sizes. And in all the pages with a left side bar, WELCOME, C64 OS, C64 LUG, and WEBLOG, the side bar now gets out of the way on mobile devices, letting the content take the full width. You can call out and dismiss the side bar with new buttons that appear above the section title.
I want to give a shout out1 to my longtime friend and colleague, Brad Marshall, for his help, suggestions and patience with me, on some design and CSS questions to get this site more responsive and looking a bit snazzier. He's a talent web designer, and you can read more about him and his work on his own blog, bmarshall.ca.
The popularity of the site is growing, as I promote it on Twitter and IRC and move up the ranks in the search engines. I'm now getting hundreds of unique visitors a month. So I feel pretty good about that. I've only got ~230 followers on Twitter, so it helps a lot when people with a couple of thousand followers retweet my tweets that promote a new blog post, or a new feature in the Buyer's Guide. Thank you to everyone for that!
Following up on my technical deep dive, Anatomy of a Koala Viewer, I've been thinking about how one could go about making improvements to the viewer and its UI, or lack thereof.
My thinking about this is completely aside from work on C64 OS, except that everything one learns helps in developing other projects. And I am a C64 user after all, I'm not going to just live the rest of my life inside the bubble (an OS environment) I'm creating for myself.
I was thinking about how command line interfaces normally work. Usually the shell program offers a single line editor. And whatever you type into that line, when you press return, is parsed and interpreted by the shell. Typically the first word is the name of a program and subsequent words and symbols are meant to be arguments given to the program. The shell has a path environment variable that defines a set of file system paths to be searched through when looking for the program.
Presuming that the program is found, it is loaded and run automatically and it has programmatic access to all the arguments. Shell's do get more sophisticated but we don't need to worry about that for now.1
Think about how the "command line interface" works on a C64. It is actually the BASIC interpreter. You are free to start entering a program, simply by putting a line number at the start of a line you type out. But all immediate mode lines, those lines you enter without a number at the beginning, are constrained to a limited set of BASIC commands. BASIC 2.0 has 71 commands, but only a subset of those can be used in immediate mode.
How do you load a program? You use the LOAD command. And it takes a fixed set of arguments, "filename" (this argument can include a partition number and directory path), then a device number and a relocate-supression flag. Although all of these arguments can be omitted depending on whether the defaults match what you're after. (LOAD by itself will start the computer loading the first file it finds on the tape in the datasette.)
There are extensions to this command set that can be made, both with software and hardware. For example, when you're using an IDE64, you can directly issue "CD" and "MKDIR" and so on. That's because the hardware adds those commands to the BASIC language. JiffyDOS does the same thing to add its commands, * for transfering files, @ to read the current device's command channel, / to load relocated, etc. But none of these extensions allow you to pass arguments directly to a program that was just loaded.
BASIC Wedge Programs
One reason you'd want to add an argument to a program call is the simple use–case of being able to pass a filename to that Koala Viewer. All the viewer does is show a Koala image, but you have to manually load the data yourself. And you have to load it using the correct flags, or the correct JiffyDOS load commmand, so it goes to the right place in memory. Then you run the program and it assumes you've put the correct format of data into the correct place in memory. Otherwise, you just see crap on the screen.
It's been over a year since I started this blog, and this is my 48th post. And I'm still feeling like I've got a lot to talk about. So let's hope I can keep it up.
The Commodore 8 Bit Buyer's Guide has recently undergone a pretty major update. And I'm trying to produce a new Feature Page, one for each product, every business day. Sometimes that's not possible, because on some day's I've already got a super busy schedule and simply can't fit it in. But that is the aggressive schedule I'm trying to hold myself to. In order to keep myself motivated I'm tweeting (#8bitbuyer) every day about one product, pulled at random, from the guide. Whatever product I tweet about, that's the product for which I write the feature page. You can follow this stream on Twitter here: https://twitter.com/hashtag/8bitbuyer
The guide is now up to 175 products, projects and kits, up from just over a hundred. And these come from 25 vendors, up from just 15. It isn't that this many products just spontaneously sprang into existence, but that I keep digging deeper and expanding the set of available products to buy.
For example, I dug into the catalog at Retro Innovations, and pulled out cables, adapters and rom chips, and have listed them. I discovered Poly.Play and all the stuff they carry and listed that. And I discovered some older projects like the 64JPX adapters that are still commercially available and I listed them. Among numerous others. If it's available, if you can pull out your credit card, place an order and have a thing for your Commodore 8-Bit, then I want you to be able to find it in the Buyer's Guide.
There are some caveats to that. I don't want to list used products of limited stock that people are selling off from their personal collections. You can generically use ebay for that sort of thing. If someone came into the possession of 25 or more Commodore REUs, but they were technically all used, I'd probably still list them. What I'm saying is that, as the editor of the guide, it's a judgement call what I think will benefit people to be able to find.
All the above said, I had a tough time with deciding what I should do about the relatively new phenomenon of 3D printing.
By their very nature there is no stock of 3D printed products waiting to be sold off. Someone somewhere has designed a 3D model and upload the file to a publicly accessible catalog. And there are ways you can turn that into a product you can hold in your hand. I'll get into the details of how to do that below.
One problem that I wrestled with is that there is a virtually unlimited number of such 3D printable products, and their lack of stock means once they're in the catalog, there seems little reason to pull them from the catalog. And, doesn't that present a philosophical problem? Won't simple 3D printable components eventually overtake everything else? This was my concern.
Someone on IRC suggested some 3D printable products and gave me links to items on thingiverse.com. I decided to peruse Thingiverse for everything I could find that is C64 related and just see what I could come up with. What I found was about 12 or 13 things. But immediately didn't see the utility of listing a couple of them. They simply fell below my radar of what I thought would provide enough value that it merited a place in the guide. And I reduced the list to just 10 things.
After 10 years away from the Commodore scene, the most shocking part of coming back was not the speed of a 1 Mhz clock, or even a 320x200 16-color display. The most shocking part is the essential interaction model. And this was my inspiration to start working on C64 OS. GEOS, as I've mentioned in many of my posts, comes much closer to what you would expect from a modern computer. But even it has all kinds of oddities that show its age. And unfortunately, its fully bitmapped UI is just too damn slow to get used to. Using a C64's READY prompt to do ordinary computing tasks is truly a blast from my adolescent past. But returning after a few years away and learning all over again how it works, it feels like a totally foreign world.
Nothing better exemplifies this than my most recent experience working with koala image files and a koala viewer program. So I'm going to deep dive on exactly what I mean by totally foreign and discuss how C64 OS will work to make the whole model more modern.
What is Koala?
Koala was a suite of drawing technologies for a number of computer platforms in the 80s. You can read all about it on this Wikipedia article. It was developed by a company called Audio Light. The suite consists of the KoalaPad which is a drawing tablet and KoalaPainter which is an accompanying art/graphics program. The program, on a C64, works with Koala format image files. The KoalaPainter program can load existing files, which you can then edit using a wide range of tools like fills, boxes, lines, ellipses, and brushes with different patterns. Then you can save your work to disk, again in the Koala image file format.
That's great! It actually sounds pretty modern when described like that. It sounds like how photoshop works. The quality of the images and assortment of tools, of course scaled for the age of the machine, but it sounds like a pretty standard modern way that a computer works. You have an application, which you load and run, it has a graphical user interface, you pick a file from a directory listing from a harddrive, it loads the file in, you work on it, save it back to disk. You can later copy the image files around individually, back them up, share with your friends, upload to the internet (or to a BBS back in the day), and so on. Very modern.
As with any image file format, especially if the files are going to be distributed, the people who receive the image are most likely not artists with intentions of manipulating the image. They are normals like us who just want to look at the beautiful artwork that has been produced by others far more talented than we are. And so to view the image files it doesn't make sense to have to load the entire Koala graphics editing program. Not to mention the fact that the original full graphics editing software likely cost money, as well it should.
What you want then is to have a free viewer that is small and quick to load, which can display the image files created by the full editor to people who just want to look at them. Again, though, this is a very modern concept. You don't have to own photoshop, nor launch photoshop, to look at an image file that was produced by it.1
I like to use a Mac to convert images (JPEGs, PNGs, etc.) to Koala format, (exactly what that format is I'll mention below.) And I also plan to have a network service which will fetch images from URLs and convert them to Koala format on–the–fly for C64s to be able to browse the web, in a more meaningful way, via proxy. A viewer is therefore far more important to me than the original KoalaPainter program. And so I found a simple koala viewer online. It's just 4 blocks (~1 KB) on disk. But… how do you use it? How does it work? Where does the modern end and the antiquity begin?
Above are previews of the 10 most recent posts.
Below are titles of the 5 next most recent posts.