The KIM-1 that sounds like Stephen Hawking (or: "jitbanging" DECtalk)

My 1976 briefcase Commodore/MOS KIM-1, a 1 MHz single-board computer with a 6502 CPU and 1K of RAM, has learned to talk — with a familiar-sounding voice.

The KIM-1's serial lines are connected to the last and smallest member of Digital Equipment Corporation's true DECtalk hardware speech synthesizers, the 1994 DECtalk Express. The DECtalk's classic default voice heard in this video is Perfect Paul, which (with adjustments) was the voice of Dr Stephen Hawking as produced with the 1988 Speech Plus CallText 5010.

The 15 keys we can read off the KIM's hexadecimal keypad are polled by a "talker" program that sends the DECtalk Express words and phrases to speak. However, although the KIM-1 has 20mA current loop output you can turn into RS-232 serial, its built-in ROM routines can't reliably communicate at the 9600 baud rate the DECtalk Express demands.

So, in today's entry, we have a veritable smorgasboard of geriatric geekery: using our KIM-1 serial uploader to push a program for execution, let's write a bitbanged 9600 baud serial transmitter routine in 6502 assembly and let the KIM-1 have its say — and crack the DECtalk Express open and look at the insides while we're at it. (Teaser: you'll find its CPU very familiar.)

Of Sun Ray laptops, MIPS and getting root on them

I like Sun Ray laptops. They make surprisingly useful thin clients. Here, going from right to left, I'm playing Quake on my Solaris UltraBook IIi while it serves a Sun Ray session via Sun Ray Server Software (SRSS) to my silver Sun Ray 2N in the middle, and on my Accutech Gobi on the left I'm root.

Wait, what? Root on a thin client?

Let's rewind a little.

Crypto Ancienne 2.2: now supported on AmigaOS and classic MacOS/MPW

As threatened we're up to the next checkpoint with Crypto Ancienne, the TLS 1.2/1.3 library we maintain for pre-C99 vintage compilers and architectures, so here's version 2.2, or "Crypto Ancienne Meets the Hooded Fang" (read about previous releases).

New checkpoints are always an opportunity for new ports. Why am I showing you a picture of my Amiga Technologies A4000T? Because AmigaOS 3.9 is one of them!

Refurb weekend: DEC AlphaPC 164LX

It's time for another Crypto Ancienne checkpoint, which will be a post Real Soon Now(tm), including some new operating system frontiers. But part of the work for Cryanc is all the build regression testing on the supported platforms: each of the platforms I vouch for has to be able to compile the updated source code and use carl, its built-in mini-curl clone (officially the "useful" demonstration application), to successfully and completely download from a selection of real websites. One of these is harlan (named for Harlan Anderson, co-founder of Digital Equipment Corporation), my one and only DEC Alpha-based machine, a DEC AlphaPC 164LX running Digital UNIX Tru64.

The DEC Alpha is a good test for Crypto Ancienne because it's a fast (for the time) and finicky (for all time) RISC architecture, with notoriously strict alignment requirements and an extremely loose memory model. Early Alpha CPUs in fact entirely lacked instructions for direct short or byte access — 32-bit, 64-bit or bust. Unfortunately the Ethernet card blew while I was testing Cryanc 2.0 and I couldn't validate that version, so I just pushed that checkpoint out the door. Well, we can't do that two releases in a row, darn it. I have a replacement NIC and a mission. It's time for a Refurb Weekend.

Printing real headline news on the Commodore 64 with The Newsroom's Wire Service

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.)

Refurb weekend: Cobalt RaQ 2

In the post on our recently resurrected fork of Dreamcast Linux, I mentioned the NetBSD NFS server providing basically all of its persistent storage. A few days into the development work I started hearing a weird whine coming from the server room and sure enough the NFS server had a bad fan — in fact, the only fan cooling the entire 1U system. That means it's time ... for another Refurb Weekend!

Dusting off Dreamcast Linux

Yes, here at Old VCR we live in the past, when RISC Unix workstations still ruled the earth like large boxy tentaculous Cthulhus. Oh, sure, if you wanted a modern equivalent you could just buy a Raptor POWER9 like the one I'm typing on now. But around here even PowerPC is too pedestrian of an architecture. We need something unique.

That's more like it! A keyboard, mouse, a NIC, VGA output, 16MB of RAM and a whole gig (you wish) of read-only optical drive space with a 200MHz Hitachi SuperH SH-4 CPU faulting its paltry 8K of I-cache and 16K of D-cache non-stop. Now freshly refurbished, its cooling fan runs louder than my Power Mac Quad G5 at idle and the drive makes more disk seeking noise than when I can't find a lost floppy. And since the buzzword with Linux distros today is immutability, what could be more immutable than an ephemeral, desperately undersized RAM disk overlaid on a live CD?

xa 2.3.14, the 6502/65816 cross-assembler

xa (xa65) 2.3, the current minor release of this long-lived 6502 and 65816 cross-assembler, gets one more stay of execution to 2.3.14 in order to fix a segfault for recursive macros with smaller arities and a regression from 2.3.13 with nested comments (though André and I may consider whether we will still support this in 2.4). The testsuite is naturally expanded and tuned up a little bit, too, and as always run to completion on the multiple current and geriatric systems here at Floodgap. I know I'm sounding like a broken record but 2.4 is coming and we will be breaking some edge-case compatibility and cutting out some long-deprecated corners of the code, so it was important to ensure 2.3.x was tuned up as much as possible before putting it out to pasture. There is no corresponding new release for dxa, the companion disassembler; work is still being done there.

The new release and archived old versions are updated on xa's home page. Both xa and dxa are available under the GNU Public License v2.

Instruction fusion and a real serial port for your virtual KIM-1: The Incredible KIMplement 0.3

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!)

Here be four bits of dragons: the Mattel Dungeons & Dragons Computer Labyrinth Game and the TMS1100

When my parents sold the house and moved to the great white north, they dropped off a few boxes of my stuff that was still in the garage. Now that we're getting things cleared away in case we have to make a move of our own in the not-so-distant future, it was time to go through those boxes, and one of the boxes was this, my old Mattel Electronics DUNGEONS & DRAGONS™ Computer Labyrinth Game.

This is the bigger, more deluxe of the two Mattel dedicated D&D games (the Intellivision of course had its own set, and we had a Tandyvision ourselves), the other being the DUNGEONS & DRAGONS™ Computer Fantasy Game. That was a handheld unit with a surprisingly compelling implementation of Hunt the Wumpus, and something we might talk about another time. This one is more like a board game, but with a computer antagonist and audio.

The box says copyright 1980 but I think we got it late 1982 or early 1983. Either way, I was probably too young for this game at the time: it advertises 8 and up, and I would have been around six or so. It requires you to juggle a number of different audio signals and build up the maze and the objects in it (you, your competitor, the dragon, the treasure, your lifeless defiled corpses when you try to get the treasure, etc.). My recollection is that we barely played it at all.

Well, better late than never. And hey: let's find out what makes it tick. (Teaser: it's four bits and we have an annotated die photo. Read on.)

Bringing TLS to the Magic Cap DataRover

Today we're adding TLS 1.3 to the one and only web browser on a 36MHz MIPS handheld running Magic Cap, the most unique mobile operating system from the most influential startup you never heard of. But before we do, a thank-you to Scott and Barbara Knaster:

Scott, who is of course well known for his Macintosh books and his work at Alphabet-Google, also worked at General Magic as a technical writer. Barbara, his wife, wrote this very complete third-party book on Presenting Magic Cap — apparently the very first! — and all the cool things users could do with it, from basic E-mail and contacts (there's a reason why there's a cloud downtown, long before the term was fashionable) all the way to building forms and interfaces with the Magic Hat in construction mode. (One demonstration is making an E-mail form for lunch orders. You send it to people, they fill it out and send it back. It's all supported by the operating system.) It also includes a look at tinker mode, letting you steal the painting from the hallway and put it in your office behind the desk, or change the pictures on the doors. All this was possible without writing a line of code: as she concluded at the end of the book, "Magic Cap has great potential to expand and enrich the way people communicate." It sure did. Thanks, Barbara and Scott!

Solbournes in space

Did a few updates to the Solbourne Solace thanks to new stuff people have sent in, Solbourne of course being one of Sun's most notable competitors in SPARC-based workstations and servers. The most interesting new entry is the space-faring PILOT ("Portable In-flight Landing Operations Trainer") laptop, reported by Scott Manley who noted it in Space Shuttle mission photographs. While the SPARC Solbourne S3000 portable workstation is well-known, this was the only known Solbourne laptop and its only colour portable, although it carried both Solbourne and Panasonic badges (Matsushita, owner of the Panasonic brand, had a majority stake in Solbourne), and was most likely designed and manufactured by Matsushita's Federal Systems division under contract instead of Solbourne in Longmont, Colorado. NASA commissioned it as a portable simulator to ensure that the Space Shuttle commander and pilot could maintain their skills in orbit, and it flew at least from October 1993 to March 1995 (the pictures above are from STS-62 and STS-63; it was documented on STS-58, -61, -62, -63, -65 and -67).

The machine had 32MB of RAM, a 15" colour LCD and a dedicated "Rotational Hand Controller." The software was NASA's own Shuttle Engineering Simulator (SES), ported to SPARC from the Control Data Corporation Cyber 180 Model 962 (an upgraded version of the RISC Cyber 180-960) at the Johnson Space Center in Houston, Texas, and ran on OS/MP 4.1A, Solbourne's equivalent of SunOS 4.1.1. Its motherboard was most likely a Solbourne "pizzabox" IDT logic board, the same one used in the S3000, S4000 and S4100 which directly competed with O.G. SPARCstations, making the reported speed of 40MHz suspect since the Panasonic MN10501 KAP (short for "Kick-Ass Processor" — yes, really) was notoriously unstable above 36MHz. A suspiciously similar laptop called the Matsushita P2100 was announced in 1992 but by then Sun was making moves to freeze SPARC clone makers out of the market, particularly Solbourne who had cornerned the more profitable upper tiers, and refused to license Solaris to anyone like they did SunOS. (Apple later pulled this same stunt with the Mac clones and Mac OS 8.) The P2100 doesn't seem to have been ever released, and while a few PILOT examples were likely fabricated, no one so far has found one. PILOT was eventually replaced by various IBM ThinkPads which went on to have a well-known and illustrious career in space.

A big thanks to Warner Losh and Dieter Dworkin Müller for the probable scoop on PILOT, as well as Scott's own research and his initial report, and this unofficial NASA description from 1994.

SAIC Galaxy 1100: a pre-CDE VUE of the PA-RISC with a security clearance

Even though I'm a Power ISA bigot through and through (typed on ppc64le!), to this day I still have an enduring sweet spot for Hewlett-Packard's PA-RISC "Precision Architecture" because it was my first job out of college. It doesn't hurt that it was one of the saner RISCs, with a fairly clean instruction set except for its odd deficiency with atomics, and was quite a piledriver in its day due to its cache arrangement and early adoption of SIMD. We ran HP-UX 10.20 on a big K250 where I developed database applications on Informix, later upgrading it to an L-class something or other (I think an L2000). When I was still consulting for the university one of my tasks was even setting up a Visualize C3750 workstation, which was a stupid fast machine at the time and I'm sure served very well for them doing protein visualization. Heck, if Commodore had stuck around longer, we might really have had a PA-RISC Amiga instead of the modern third-party PowerPC systems. (I've got some other wacky PA-RISC machines around here I might introduce you to later.)

The university only used the big stuff, though, not "low end" pizzaboxen like the versatile and (relatively) ubiquitous 9000/712 "Gecko," which besides being a popular 1990's RISC workstation of its own — id Software had one during their NeXTSTEP days — turned up as the system base in other surprising places. One of these was HP's own Agilent 16505A protocol analyser, and another was as the basis of the MIL-SPEC SAIC Galaxy portable workstations.

MacLynx beta 4: now with scrollbars and dialogue boxes

Some things you just gotta get off your Quadra 800's desktop and out to the people. Plus, the Q800's Barracuda SCSI drive is getting a little iffy and I foresee a retrofit in the not-too-distant future, and ain't no backup better than an interim release. There's still more work to be done but enough's here to make it worth a save point. C'mon now, two years after beta 3 isn't that bad, is it?

Yes, MacLynx is a real, honest to goodness port of Lynx 2.7.1 to the classic Mac OS, compatible all the way back to System 7. What makes it particularly interesting as a port is its partial integration with the Mac OS: the home page is set through Internet Config, it supports the Speech Manager, you can drop URLs on it and you can even click on links directly (cooooool!). I used it myself on my first Mac, a Macintosh IIsi, for which it was very well suited. It was released as a beta by its original author and no further releases were made, so a couple years back I decided to dust it off, reconstruct the toolchain and do some upgrades to it just for fun. It's probably the most practical browser you can run on a compact Mac, does very well on later 68Ks and runs just fine under A/UX. I build it with CodeWarrior Pro 2, CWGUSI 1.8.0 (comes with CW Pro 2) and Internet Config Programmer's Kit 1.4.

The original idea for this new beta 4 was to do both some updates to the Lynx render core to make it more congruent with later versions (there are so many hacks in this that it would be a very lengthy undertaking to find and up-port them to a current Lynx, assuming it would even compile) and also add more GUI elements, but the biggest issue remained MacLynx's Frankenstein event loop. From "beta 2" to beta 3, I managed to cut down on unnecessary screen updates but the event loop still seems to be doing a lot, a probable impedance mismatch between Lynx's main loop which reasonably expects a terminal all to itself and bolting the classic Mac OS event loop onto that. (I wonder if Olivier was struggling with the same thing when he was working on it.) While working on this release I spun my wheels quite a bit trying to figure out where key down events were getting dropped or delayed while mouse events like clicks on links were seemingly unaffected, and ended up putting further work on it aside for awhile, which is why we're now into 2023.

Then it hit me: I had always intended to make MacLynx more Mac-like and use more Mac controls. In fact, beta 3 has a dialogue resource in it I did some initial messing around with but never hooked up. If moving more things into the native mouse-driven GUI makes it faster ... let's make it faster by moving more things into the native mouse-driven GUI! Time to dig out that well-worn hardcover copy of Inside Macintosh and dive in!

The MOS 6502 is (mostly) Turing-complete without registers

It is known that the x86 MOV instruction is Turing-complete (PDF) all by itself, and is even a compiler target. More usefully, x86 can be made Turing-complete without the overt use of any registers.

These tricks work primarily because the ISA allows memory-to-memory operations, i.e., altering a memory location without explicitly moving data through a program-visible register, a historical holdover from its roots in the Intel 8086 and its ancestors. (Let's not even talk about its Turing-complete faults.) Other pre-RISC CPUs of that era also have memory-to-memory addressing, including the MOS 6502, which despite its simplicity being inspiration for the RISC ARM architecture is not itself RISC. It should be no surprise you can make the 6502 do this trick too even with its more constrained instruction set, and we can do it with just four instructions, not counting rts to return to the operating system.