Old Vintage Computing Research

COMPUTE!'s Gazette was for many years the leading Commodore-specific managzine. I liked Ahoy! and RUN, and I subscribed to Loadstar too, but Gazette had the most interesting type-ins and the most extensive coverage. They were also the last of COMPUTE!'s machine-specific magazines and one of the longest lived Commodore publications, period: yours truly had some articles published in COMPUTE (no exclamation point by then) Gazette as a youthful freelancer in the 1990s until General Media eventually made Gazette disk-only and then halted entirely in 1995. I remember pitching Tom Netzel on a column idea and getting a cryptic E-mail back from him saying that "things were afoot." What was afoot was General Media divesting the entire publication to Ziff-Davis, who was only interested in the mailing list, and I got a wholly inadequate subscription to PC Magazine in exchange which I mostly didn't read and eventually didn't renew.

This week I saw an announcement about a rebooted Gazette — even with a print edition, and restoring the classic ABC/Cap Cities trade dress — slated for release in July. I'm guessing that "president and founder [sic]" Edwin Nagle either bought or licensed the name from Ziff-Davis when forming the new COMPUTE! Media; the announcement also doesn't say if he only has rights to the name, or if he actually has access to the back catalogue, which I think could be more lucrative: since there appears to be print capacity, seems like there could be some money in low-run back issue reprints or even reissuing some of their disk products, assuming any residual or royalty arrangements could be dealt with. I should say for the record that I don't have anything to do with the company myself and I don't know Nagle personally.

By and large I naturally think this is a good thing, and I'll probably try to get a copy, though the stated aim of the magazine is more COMPUTE! and less Gazette since it intends to cover the entire retro community. Doing so may be the only way to ensure an adequate amount of content at a monthly cadence, so I get the reasoning, but it necessarily won't be the Gazette you remember. Also, since most retro enthusiasts have some means to push downloaded data to their machines, the type-in features which were the predominant number of pages in the 1980s will almost certainly be diminished or absent. I suspect you'll see something more like the General Media incarnation, which was a few type-ins slotted between various regular columns, reviews and feature articles. The print rate strikes me as very reasonable at $9.95/mo for a low-volume rag and I hope they can keep that up, though they would need to be finishing the content for layout fairly soon and the only proferred sample articles seem to be on their blog. I'm at most cautiously optimistic right now, but the fact they're starting up at all is nice to see, and I hope it goes somewhere.

Rockwell famously used 6502-based cores in modems for many years, but that doesn't mean other 6502s couldn't be used. If only there were a way to connect a Commodore 64's audio output directly to an RJ-11 plug ... Of the many interesting posts from Usenet's more golden days, one of my favourites was John Iannetta's "35-cent modem," where the SID chip provides one-way data modulation to a receiving modem connected via the C64's sound output. While I remember him posting it back in 1998, I never actually tried it at the time.

Wouldn't you know it, but it came to mind the other day when I was looking at a recent haul of Convergent WorkSlate stuff I've got to catalogue. Officially the WorkSlate's only means of telecommunications is its 300 baud internal modem. While we have a 9600bps way of wiring up a Workslate to a modern computer, it's always nice to have a simpler alternative, and I figured this would be a great challenge to see if John's old program could let my Commodore SX-64 talk to my WorkSlate. Spoiler alert: it works!

A merry Christmas and happy holidays from the Southern Hemisphere, where it's our year to be with my wife's family in regional New South Wales, Australia. One of my wife's relatives had an "old Commodore" in their house and asked if I wanted it. Stupid question, yeah? So they brought over, in their original boxes, a Commodore 128D (PAL) with Commodore 1802 monitor, Commodore MPS-1250 dot matrix printer and a separate box of magazines, circulars and boxed software. Let's fire it up!

I've got a few retrocomputing bucket list items I'm slowly working down, and a couple of them involve some little Commodore 64 games I've had kicking around on the backburner. However, every game needs media assets, and while there are many great tools for doing art on your present-day workstation and exporting it, sometimes you just want what you used to work with — in as convenient and quick-loading a way as possible that blends with modern emulation workflows. So here's two I tweaked and one-parted — Ultrafont+ and DOODLE! — and some tips for making self-contained tools like these yourself.

Once upon a time (and that time was Winter CES 1983), Commodore announced what was to be their one and only handheld computer, the Commodore HHC-4. It was never released and never seen again, at least not in that form. But it turns out that not only did the HHC-4 actually exist, it also wasn't manufactured by Commodore — it was a Toshiba. Like Superman had Clark Kent, the Commodore HHC-4 had a secret identity too: the Toshiba Pasopia Mini IHC-8000, the very first portable computer Toshiba ever made. And like Clark Kent was Superman with glasses, compare the real device to the Commodore marketing photo and you can see that it's the very same machine modulo a plastic palette swap. Of course there's more to the story than that.

We were a Commodore 64/128 household growing up, and Apple IIe systems at school, but that doesn't mean I was unaware of Atari 8-bits. There was a family at church who had an 800XL and later a 130XE — and a stack of COMPUTE!'s I used to read through for hours — and it was interesting to compare the two worlds, especially the relatively luxurious Atari BASIC and DOS against Commodore's spartan accoutrements. On the other hand, there was a lot more software and peripherals for the C64 by then, and you ended up becoming a lot more proficient with the guts of the hardware because you had to. Plus, Jack Tramiel's Atari was a lot like Jack Tramiel's Commodore and not always in a good way. I have an XEGS (functionally a 65XE when you add the keyboard) and a 1050 disk drive I should set up somewhere and mess around with a little.

But that doesn't mean Atari didn't try. Prior to all that, Atari in the Warner Communications days put forth substantial effort to make it competitive in all kinds of settings, notably education. Ataris had some unique hardware in that niche; an Atari was the first non-Control Data microcomputer to access the PLATO network, for example. And then there was the AtariLab.

With a very simple interface box, your Atari 8-bit could read the temperature and sense brightness. You could run experiments on it at school, including polarized and coloured light, or testing how quickly things cool and heat. You could use it at home with your own programs thanks to its comprehensive documentation.

But the surprising part is that even though these were the only such devices released under the AtariLab name, they weren't the end of the line: besides its stealthy revival for other home computers like the Commodore 128 running it here, its creator also turns up in one of the more interesting scientific data acquisition devices I've run across in its price range. We'll test-drive the software, hack on the platforms a little, and try some even more outlandish sensors. Let's go down the rabbit hole with AtariLab — and its full-fledged descendants.

Call it a "refurb weekend sequel" to our previous work on my beloved Commodore 128DCR. It's been a hot, horrid summer in Floodgap Very Sub-Orbital Headquarters and I was somewhat concerned about the heat in the house computer lab even with the A/C cranked up to "Vegas weekend for Southern California Edison's Board of Directors" levels. But it's even worse for cooling when your one and only rear vent looks like this: (No, I don't know what spilled there either.) The European plastic-case 128D (not this metal-cased "D Cost Reduced") has a cooling fan — and I recently landed an Australian one, more on that later — but as part of becoming CR the fan was eliminated, relying entirely on that vent and whatever warm air comes out of the rear ports to save the 8502 from being "well done." Fortunately Commodore determined it was also too much C to remove the mounting holes, so let's put in a fan instead of hoping the convection cooling is good enough.

Actually, it was more like a whole stinking Refurb Two Months. The KIM-1 is one of the earliest MOS 6502 computers, a single-board system with 1K of RAM (actually 1152 bytes total) and a one-megahertz CPU developed by Chuck Peddle in 1975 as a way to introduce engineers to the new 8-bit microprocessor. However, its low cost meant it ended up taking on a life of its own as it was one of the cheapest ways to assemble an entire working hobbyist system, and Commodore continued to sell them for several years after they bought MOS. You could hand-key in programs with the hexadecimal keypad and the six LEDs as a display or wire up a TTY. It also supported saving and loading from cassette and paper tape, all built-in to the standard ROMs.

I have a couple KIM-1s and they are the oldest machines in my personal collection, including a Revision A pre-Commodore MOS unit with ceramic processor and RRIOTs, but the one that's the most special to me is the briefcase Revision D system you've seen here in other entries. The Revision D is notable historically as the first Commodore-branded KIM after their 1976 buyout, but it's important to me because this unit was my first KIM, and the one we got in high school from our high school math teacher and learned to program it over the weekend (we'd grown up with the Commodore 64, so we already knew all the machine language opcodes). It conveniently sits in a briefcase with a power supply and has one of Bob Applegate (RIP)'s I/O boards to provide the RS-232 connection.

While working on our most recent KIM-1 project, I noticed that the RAM from $0280 to $02bf wasn't working right. The serial uploads from KIMup would succeed, but the data it stored in that range was wrong, and when I checked with the monitor it would only store values 0-3. I got around the problem by assembling the code to a different address, but on a system with a single kilobyte of memory, you can't ignore a whole 32-byte failure. It was time for a Refurb Weekend.

If we're going to make the little old 8-bit MOS 6502 into Skynet — because we already know what the Terminator T-800 CPU is — then it's gonna need to see. How can it exterminate the last remnants of humanity without vision?

And we'll use something period-correct, too. While our favourite Cyberdyne Systems Model 101 was busy stalking Sarah Connor in 1984, the product it might have (slowly) viewed the world with was already on the market: the Digital Vision ComputerEyes. Check out the little beige camera perched on a stack of disk boxes, attentively surveilling the room at just a few, uh, seconds per frame as displayed on the monitor. Plug in a composite video source, connect it up to your Apple II, Commodore 64 or (in 1985) Atari 8-bit, and wait about six or seven seconds to identify targets — or almost fifty for the highest quality. If Skynet had chosen this option we might never have had Judgment Day.

The slow capture speed meant it was never intended as something to view live, and on the Commodore and Atari versions, DMA interference meant you could only capture with the screen off which would seem to make any live-ish feed impossible. But the Commodore 128 has a second video chip that doesn't interfere. Let's turn the Commodore 128 into a really slow potato-quality live camera you can interactively watch and freeze-frame — and then, in exchange for 11% of the screen, make it capture almost 25% faster! Time-lapse video proof at the end!

No question: the Commodore 128D is the finest Commodore 8-bit ever made. On this I tolerate no dissent, and that's not just because I sometimes hang out with Bil Herd. It's a 128, so it's got VDC graphics, 128K and 2MHz operation, but because it's a 128 it's also a 64. It's also an upgraded 128 with the fixed ROMs, (in this North American 128DCR) 8568 VDC and 64K of VDC memory, it's got a built-in 1571 (Commodore's finest 5.25" disk drive), and it doesn't have an external power brick. Plus, even though it has the desktop footprint of a 128, the detachable keyboard means you can just put a monitor on top of it (and the steel-cased North American 128DCR handles that very well) just like you can't with a flat 128, and you either get an actual cooling fan with the plastic 128D or the solder points to put one in a steel 128DCR. My only complaint is that the consolidated DCR motherboard is nearly devoid of socketed ICs, making it a little tough to do component level repair on. I like spares, so I have four DCRs, all of which completely or mostly work (and two spare keyboards, one rather yellow but fully functional and one even more yellow and useful just for parts).

This particular 128DCR has been a constant presence on my desk since the mid-1990s when I first got it as an upgrade from my ailing flat 128. But it has one flaw: it doesn't have a working CIA Time-of-Day clock, which isn't used much by software, so I never bothered to do anything about it. This was tricky when developing TOTP-C64, since the 30 second timer between emitting TOTP codes uses the TOD clock for maximum interval accuracy (the 50/60Hz Timer A interrupt that drives the TI/TI$ jiffy clock can be stalled and lose time, whereas the TOD clock is based on the AC mains frequency and thus is as accurate as your plugged-in wall clock); one of my portable SX-64 systems, my second favourite Commodore 8-bit, handled that portion of testing instead.

Well, now that I've got a new Ultimate II+L cartridge in fire-engine red with its own real-time clock (among other great features), I'd like to update TOTP-C64 to support it and I'd rather do it on the 128DCR. That means we should fix the TOD clock. And that means ... a Refurb Weekend!

Besides other things I've written or supervised, so far in my time I've also edited three periodicals, and Springboard Software's The Newsroom is a big reason why. In today's article we'll not only look at the guts of this pioneering 1984 software package, but also solve a childhood mystery I've wondered about since the very first day I touched the program by MITMing an RS-232 connection to snoop on serial data — and then print out a brand new 2023 newspaper with 2023 headlines to prove we cracked the case. (Scroll to the end if you just want to see the finished product.)

Everyone should have the retrocomputing experience of a 1976 1MHz MOS 6502 single-board computer with 1K of memory, six hex digit LEDs and a keypad. One of the earliest such systems and one of the least expensive, you program the KIM-1 in 6502 assembly language right on the keypad in hexadecimal and it's amazing what you could do with a system that little. You could even hook up a cassette deck and an external terminal and have a full system for just a few hundred dollars; MOS Technology (and later Commodore) consequently sold a ton of them. We first experienced the KIM-1 in high school and having grown up with Commodore 64s and 128s it was like meeting their long-lost little brother. We spent the whole weekend typing in hex opcodes and learned how to bang on the hardware and make it do surprising things in a space that small. That's the very unit in the picture, still in my possession, and over four and a half decades old it still works.

While I now personally own four KIMs (an MOS Revision A, plus a Commodore Revision D, a Commodore Revision G and this Commodore Revision F, my first), it's naturally more convenient to develop on an emulator and then test on the real thing. The KIM is such an easy system to understand that there are other KIM-1 emulators like it, but this one is mine. And the Incredible KIMplement runs on a Commodore 64, so anyone can run it on just about anything that can emulate a Commodore 64, or even a real Commodore 64.

However, I also think the KIMplement is a darn handy emulator if I do say so my darn self. It naturally supports the keypad and hex LEDs, and loads and saves memory like every other basic KIM-1 emulator, but it also supports a virtual teletype on the Commodore 64's console (the MAME driver still can't do that) and implements a true KIM-4 expander with 16K of total addressing space.

But new in this version, and the only emulator that currently supports it so far, is you can now redirect the virtual KIM's TTY to the Commodore 64 user port as a real physical serial connection: a physical serial port for your virtual KIM-1. The picture shows a real Commodore 128D running the emulator, connected to minicom on my Linux workstation over USB serial from the 128's userport at 300 baud. From the Linux machine's perspective it's practically indistinguishable from my real Revision F unit, and on Commodore 64 emulators that support it (like VICE), you can tunnel the emulated 64's user port over a TCP socket to give your virtual KIM an Internet connection — we'll demonstrate that below. Plus, this means your virtual KIM can now call out to the real world as well as in! (What can you do with that? Stay tuned for a future entry!)

Multi-factor authentication is ripe for disruption. SMS 2FA is inherently defective. Phone authenticators get stolen. Security tokens get lost.

But just try misplacing a Commodore SX-64. And any thief who tries to grab it and run gets a free hernia truss from the prison infirmary:

Plus, I've got a colour for every key! And it actually works: The terminal window is showing a generated time-based one-time password for a full key, and the emulated 64 is showing the correct key, at the correct time, which was known and tested to be valid. Yes, you really can use your Commodore 64 for multi-factor authentication to generate TOTP codes!

The Commodore SFD-1001 is an oddball and a rarity even among Commodore IEEE-488 5.25" floppy drives, which nowadays aren't particularly common either (though my preferred IEEE-488 device is the MSD Super Disk Drive SD-2, which also conveniently has IEC serial). The SFD "Super Floppy Drive"-1001 is a low-profile single drive version of the CBM 8250 dual drive and stores a whopping 1MB per disk, which when the series was introduced in 1980 was really quite something. Unfortunately it requires 96tpi double density "quad density" floppies to do it — not the 48tpi double density disks you'd feed a more typical 1541 or 1571, nor the 96tpi high density PC floppy drives use — so there wasn't a whole lot of megabytes to store into even when these drives were newer. I also have a CBM 8050 which is the single-sided (but still dual drive) version of the 8250; it can store roughly a cool meg too but you have to flip it over for the second half.

This SFD came to me from a seller who said while it powered on it also made a weird noise and he had trouble inserting disks. Nevertheless, it's still an odd enough duck it was worth buying to see if it was repairable. We have an extra hour this weekend from the daylight savings change, so let's crack this sucker open.

I mentioned the Wordle craze, including the extant ports to the Commodore 64, in our KIMdle sorta-Wordle for the KIM-1. But the Commodore 64, and I suspect this was actually a PET game originally, had a five-letter word game before that. Jim Butterfield's port of the 1955 Jotto board game isn't Wordle — it tells you merely how many letters matched — but it's undeniably an ancestor concept. Jotto appears in the Commodore 64 user's guide on page 145 and is believed to be public domain. It is reproduced in its entirety in this scanned image.

As I manage to eke out a little more time now for personal projects, since TenFourFox is coming to a close and the OpenPOWER JIT is developing at record pace, it's time to dust off some older items I've really neglected. This last week I started by updating the Incredible KIMplement, my MOS/Commodore KIM-1 emulator for the Commodore 64.

No, that's not a joke. The KIMplement runs real KIM-1 code using a software 6502 core I've christened "6o6" (6502-on-6502). 6o6 implements protected memory, exception handling and all legal NMOS instructions. In addition, the KIMplement not only emulates those famous six seven-segment LEDs and the hex keypad, but also is one of the few KIM-1 emulators that emulates a TTY connection (an old-school ASR-33) and a KIM-4 expander with 16K of RAM, allowing you to run "big programs" too.

The KIM-1 is one of the earliest single-board computers, at least in the sense we conceive of them today. It was introduced in 1976 as an enticement for engineers to play with the MOS Technology 6502 which was then the cheapest microprocessor on the market. MOS had just gotten its pants sued off by Motorola, who did not like the prospect of an inexpensive drop-in replacement for their 6800 CPU; the MOS 6501 was completely pin- and bus-compatible, and where the 6800 cost $179 the 6501 was priced at just $25. The "lawsuit compatible" 6502 was just as cheap, but because the pins had been rearranged, couldn't be substituted without additional design work. The KIM-1 provided a platform for engineers to become more accustomed with the 6502, featuring a 1MHz CPU, 1K of RAM, cardedge I/O, a keypad, LEDs and in-ROM support for teletypes, punch tape and cassette tape, for only $245.

MOS expected this would be a low-volume item mostly of interest to circuit designers. Instead, hobbyists bought them in large numbers because it was easily the least expensive microcomputer you could purchase at the time. With a KIM-1 at its center, you could have a full system with teletype, power supply and cassette storage for around $500. No other system came close to competing on cost. When Commodore Business Machines bought the ailing MOS in 1977, they wisely kept producing the KIM-1 until 1979 even after the introduction of the PET. Several clone systems exist, most notably including the Synertek VIM-1/SYM-1, as well as one unusual clone I'll talk about in a moment. I am the proud owner of four KIMs (including an original pre-Commodore KIM-1) and they all work.

I don't know if KIMplement's CPU core could be truly considered "virtualizing" the 6502, but it's more than just a naïve emulation. Rather than manually setting results and flags, the core looks at the guest instruction and runs the same instruction (or a safe variant) in the core context so that all the side effects, in particular changes to the status register, occur "for free." There is no way that a Commodore 64 at 1.0225MHz (or, worse, 0.978MHz for PAL) can do full-speed emulation of a KIM-1 running at 1MHz, but because there is much less code running per instruction, I think this scheme is probably near the fastest way a 6502 can run "untrusted" 6502 code. In practice it is about 35-50 times slower than native code, and this upsets programs that use tight timing or cycle counts, but it's still absolutely enough to actually "do things."

What sorts of things? Besides a couple LED-based games (originally Jim Butterfield's version of Lunar Lander, and I also added the misère game variant Black Match) and toy applications, you can run Tom Pittman's Tiny BASIC in the TTY, and with the bug fixes in 0.2b now you can successfully run FOCAL-65:

This screenshot in VICE shows the emulated 64 running a full FOCAL-65 program to manually compute square roots using Newton's method. It takes it a few seconds to do each iteration, but it all works. This is also a good demonstration of the FOCAL programming language itself including its unusual "floating point" line numbers (actually module and line), which it inherited from its more complex ancestor JOSS.

For this version of the emulator (0.2b), I finally finished some performance improvements to the CPU core that had been gestating in my mind for literally years -- the last version of the KIMplement was released in 2006! -- and also fixed a problem with the TTY emulation where typing characters could get out of sync under CPU load. It can still drop keystrokes if you overflow the Kernal keyboard buffer, but it's a lot smoother generally. I also worked around a bug in VICE where, if you try to load files from a directory on the host machine, the RENAME-the-file-to-itself test used to check for the file's presence doesn't work (a real 1541 would respond with error 63 FILE EXISTS but VICE says 0 OK).

The other bug I fixed was caused by the CPU core, but can't be fixed in it. The 6502 has a decimal flag which can be set in the status register and causes add and subtract instructions to operate in binary coded decimal (e.g., $90 - $01 normally is $8F, but in BCD mode it's $89). Famously, or perhaps infamously, the Commodore 64 Kernal IRQ doesn't turn off the decimal flag, and there is at least one SBC in the normal execution path. Because 6o6 executes instructions for their side effects, if a program had previously set the decimal flag (and this is not at all uncommon in KIM-1 code) it needs to be on for those math operations. The usual solution is to turn on the interrupt flag first with SEI to suppress IRQs while decimal mode is on, but the normal state of guest code is to have the interrupt flag clear because the KIM-1 doesn't have this problem. If an IRQ hits right that moment, the IRQ will be executed with the decimal flag on, and possible unexpected behaviour could result.

This is an extremely infrequent occurrence, but in a long-running system "infrequent" is a synonym for "inevitable." This can't be efficiently solved in the core because there is no atomic method for controlling two flags at once. A better solution is very simple: we just make a patched IRQ that clears the decimal flag explicitly, and calls the normal Kernal IRQ. I did the same for NMIs as a belt-and-suspenders approach.

The eventual goal is to open-source the KIMplement, and in particular 6o6, but I want to have another demonstration application for 6o6 as well before I do. A small multitasking general-purpose kernel sounds like an ideal way to show off how it works.

On my main KIM-1 site I also put in a few words about the microproducts Superkim. This 1979 variant of the KIM-1 was developed in Redondo Beach by Paul Lamar, who had been using KIM-1s for automotive performance testing but was unsatisfied with their expansion capacity. Unlike the hobbyist audience of the KIM-1, the Superkim is all business. The unit in my possession was clearly in a card cage; the hex keypad was never even fitted. It uses a custom board rather than a modified KIM-1 with sockets for RAM, ROM and up to four 6522 VIAs (this unit has 4K of static RAM and a Rockwell R6502P), and sports a full prototyping breadboard on-unit. But its most noticeable (and, I might add, intimidating) characteristic is the 200 gold wirewrap pins penetrating the board: I have no idea what the sam heck this board was doing, but it clearly did something major in whatever its application was. Don't ask me to power this thing up because I'm worried I'll short something out somewhere. I don't know how many of these were ever sold and Commodore and MOS seem to have had nothing to do with its development. Of the clones I find the Superkim the most interesting. While many people mention the Rockwell AIM-65 as a clone (my unit is above), and it is strongly based internally on the KIM-1, its substantial expansion (wide alphanumeric LED screen, full keyboard, printer) would not make it generally recognizeable as such. I think the Synertek VIM-1/SYM-1 are more characteristic, though that is one unit I don't personally possess.

In the future, and hopefully that future isn't in another 15 years, I want to add actual cassette support (right now you just dump memory to and from disk) and maybe support for one of the hi-res video boards like the Visable. It may also be worth trying to port the KIMplement to a faster 6502-based system like the Commodore Plus/4 or the Commodore 128 in 80-column mode, or maybe even the Apple IIgs, though all of these would need a solution for the sprites I currently use for the LEDs. (Okay, you Atari freaks, I know, I know.) The KIM-1 is a great little machine and surprisingly capable. The fact all of mine have survived over four decades proves they don't make them like they used to.

You can download a .d64 or .sdas of the Incredible KIMplement and its demo applications, or read more about the KIM-1.

I'm testing lots of units in storage, including a whole mess of Commodore 264-series machines, mostly C16s (in both the domestic U.S. and Mexican Sigma variants, which are exactly the same internally), but also a couple of Plus/4s. The Plus/4 was beaten up in the United States press as the "Minus/60" because of TED's deficiencies (more colours but no sprites and worse sound) and its intentional incompatibility with the Commodore 64's large software library. Indeed, that's probably why my family upgraded to the 128 instead and completely skipped it.

Another aspect of the +4 that was mercilessly derided was the 3-Plus-1 pack-in software. Based on an integrated suite called Trilogy by Pacific Tri-Micro, it included a word processor, database and spreadsheet; the fact they were intended to be basic applications did not prevent critical displeasure. Popular Computing Weekly pointed out how small the working space was and their limited features, and InfoWorld complained that "[t]he word processor is the worst I've ever seen," but The Transactor's editor Richard Evers was particularly barbed, famously observing that "[t]he word processor is barely that, the data base [sic] defiles the name and the spreadsheet has little spread." But while this quote got wide currency, the rest of the article is actually far more complimentary, adding, "Each package is well written, taking into consideration the limitation of trying to make them all work within the confines of each other. Running two packages in tandem is possible with this system ... think of the software as an almost free bonus, and accept its limitations."

I certainly thought so. While I didn't pick up my first +4 until I was a starving medical student, it was a cheap thrift store purchase and I made good use of the spreadsheet as a household budget. The word processor was just good enough for letters (school papers I typed in Pocket Writer on the 128D, until I got a Macintosh IIsi) and I barely used the database at all, but the spreadsheet actually worked fairly well for basic figures. Best of all, it loaded instantly because everything was in ROM, and you really could switch back and forth from one to the other and exchange data without losing anything, neither of which was true of the programs I had on the 128. In some respects it was even more "integrated" than bigger integrated packages (think Lotus Symphony, etc.) on the PCs of the time. It is debatable how useful this feature would have been versus simply having the applications run one at a time for a larger workspace, but it did work.

Something else that worked was this Plus/4 that I dredged out of storage to test. While checking the contents, I found it had this letter in the box which I don't even remember noticing before:

The previous owner, in August 1986 (granted about a year and change after the +4 had flamed out), was invited to a computer literacy class, "an introduction to computers, teaching you basic data entry terminology, to help you feel confident working with computers. You will recieve [sic] a Commodore Plus 4 [sic] computer that adapts to your television for passing the class." The class was administered in Oregon.

There is no mention of any peripherals being included, and no Commodore could directly connect to a standard cassette deck for storage. Furthermore, it is likely the Plus/4 was selected solely because they got donated stock that didn't sell. Still, here was a computer that was cheap enough to just give somebody and connect up to their television. You pressed a key and almost instantaneously you got a word processor, a spreadsheet and a database that came built-in. You could type letters, do a household budget and maintain an address book. If you picked up a 1541 disk drive, which by then was selling for under $200, you could save files. If you picked up any of the cheap Commodore 1525-compatible printers on the market, you could print letters. If you cared to crack out the manual, you could learn to write your own programs.

For this person in western Oregon, this Plus/4, as idiosyncratic and artificially limited as it was, may have been their gateway to computer literacy — and at that time it very likely was all the computer they actually needed.

Although I was a registered hardcore user of Power64 when my daily driver was still a Power Mac, now that I'm a daily Linux user on this Raptor Talos II the best Commodore 64 emulator is clearly VICE, the Versatile Commodore Emulator. It not only has highly accurate emulation, but can talk to real disk drives over OpenCBM (I use it with a ZoomFloppy xum1541) and even emulates a whole mess of peripherals, including Ethernet cartridges like the RRNet and clones (on my real Commodore 128, I use a 64NIC+).

However, I'm a Fedora user and SELinux is on by default. SELinux will really ruin your day here because it (quite reasonably) sees a random user application trying to tunnel out a network connection through libpcap/libnet as a security risk and disables it by policy. You find this out the hard way by trying to enable the Ethernet cartridge from the VICE preferences interface and getting a message you need to run it as root. I don't run things like Commodore emulators as root, spank you very much.

Fortunately, there's an easy, (probably) one time workaround; with libpcap and libnet installed (using tun/tap isn't supported yet), you will have to be root just once to fix the problem. Assuming x64sc (or whichever VICE component you're using) is in /usr/bin, you can give it raw network access with setcap cap_net_raw,cap_net_admin=eip /usr/bin/x64sc. Now you should be able to run it without root privileges and be able to access the raw interface. Here's a little test in Kipper BASIC:

Makes cross-development a lot easier!

Just some potpourri over the weekend. While working on other stuff and doing laundry, I finally put that keyboard extension on my Commodore 128DCR so I can put the keyboard in my lap if I want to. Any straight-thru DB-25 will work, so I used a 3-foot parallel printer extension cable.

Also, I was pointed to some additional BeOS PowerPC files, so I deduped and sorted them, and they are on Be-Power. Among other things there are now many more apps and also some of the OS updates. I also heard from someone who claims to have the old ftp.be.com archive completely mirrored, though for obvious reasons I'm mostly just interested in the PowerPC stuff. Haven't heard back from him yet when I asked for more details, but that's very encouraging for having a nearly complete mirror.

Happy holidays and to those of you that celebrate it a very merry Christmas. As a holiday-appropriate entry, let's unbox ... a Commodore SX-64!

The Commodore SX-64 has the distinction of being the first portable colour computer. Originally part of an entire family of portable Commodore 64 systems, it was supposed to be the midrange model between the black-and-white SX-100 and the dual drive DX-64 as announced at Winter CES 1983, but only the SX-64 was ultimately released by May of that year. (There was even an SX-500, based on the Amiga 500, but it never got past the prototype stage.) Portable in this case is used advisedly, as it weighs about 23 pounds, but it has a 5" monitor which isn't terrible, a built-in 1541 5.25" floppy drive and a detachable keyboard all in one tank-like enclosure that can be lifted around by the handle (which doubles as a stand). Power usage is too much to run on an external power source any smaller than your typical car battery but in the age of systems like the Osbourne 1 such a machine wasn't implausible as a luggable. It did not sell particularly well but the sheer number of SX-64s that survive and see regular use today (I actually own three others) attests to their residual popularity. I acquired this SX-64 as NOS still in its original box and packaging a few months ago and decided to get it out of storage as a fun little exploration.

Getting it out, we experience our first Christmas emotion: anticipation. This box was only opened by the previous owner to check the contents, though it got flattened a bit by sitting stacked in the storage unit.

Obviously Commodore didn't lose a lot of sleep making the box pretty (not like the regular C64 or other packages); it's plain jane cardboard in the same look as their printer boxes and certain other sub-sexy accessories. The indication "PHILADELPHIA" on the label suggests this was stocked at their West Chester, PA headquarters. Although it's likely some stores did sell the SX-64 at retail, at least as a kid in Southern California I didn't see any retail sales at the usual suspects of the day, including where we bought our 64 and 128 and peripherals (Target, Sears, Toys R Us, etc.). We will verify the serial number shortly.

And now the second Christmas emotion — delight — as we see the SX-64 inside. On top is (in protective foam wrapping) the manual, and (in protective plastic) the "saddlebag" accessory that is very precious to SX-64 owners that is often separated from used units. I have put the manual aside. Let's get the saddlebag out of the plastic.

The "commodore" and logo are silk-screened onto the fake fuzzy exterior, which on my other units is worn or faded, but not so here on this absolutely pristine one. Inside the saddlebag are two boxes of the type 5.25" floppies used to come in. One contains a totally ordinary grey IEC power cord but the other contains a beautiful new DB-25 keyboard connector cable. (A straight-thru DB-25, suitably machined to fit, will do if your SX-64 doesn't have one.)

Serial number checks out. This unit has a manufacture date of September 1983 and was "made in Japan." SX-64s have the full complement of ports except for cassette; the SX-64 Kernal ROM instead defaults to device 8 (the internal disk drive), but has a bug that overruns the input buffer when using the SHIFT-RUN/STOP shortcut to load from disk. The Kernal also uses different, higher-contrast colours. You can connect an SX-64 to an external monitor, but do it when the power is off or you can kill the SID (I've actually done that once, to my great chagrin).

The other major glitch with the SX-64 was the top-loading expansion port. Its ribbon cable to the mainboard was so inadequately shielded that devices like REUs would not work reliably, forcing Commodore to issue a service pack to correct the problem.

Each side of the main unit's Styrofoam packing has "SX-64" and a Commodore logo stamped on it.

Portrait with the foam sheet protection still on the handle.

Foam protects the screen.

... well, sort of. Degrading as polyethylene foam of this age often does, the foam had also left a little "extra" but it was easily wiped off.

With the disk drive and monitor control door open. The 1541 disk drive still had the original head protector, which is a cardboard insert to prevent the disk heads from clattering themselves to death during transport. Please, if you're shipping a 5.25" drive, put a head protector in. A throwaway floppy disk will do nicely.

And finally, all plugged in and ready to rock, we now experience the last and most bittersweet Christmas emotion: disappointment. This unit does not power on. After some cursory checks of the fuse, it appears to be the power supply, which while more reliable than the obnoxious C64 potted epoxy brick is still subject to the capricious ravages of time. This unit will thus become a spare.

(The unboxing experience isn't exactly contemporary Apple, but I think I still would have been excited.)