Old Vintage Computing Research

I had this grand idea many moons ago about writing up a TCP/IP stack for the Commodore 64, along with a lot of other people, and several of those people eventually did so before I even wrote a single opcode of 6502 assembly. For that purpose I had bought the box set of TCP/IP Illustrated (what would now be called the first edition prior to the 2011 update) for a hundred-odd bucks on sale which has now sat on my bookshelf, encased in its original shrinkwrap, for at least twenty years. It would be fun to put up the 4.4BSD data structures poster it came with but that would require opening it.

Fortunately, today we have AI we have many more excellent and comprehensive documents on the subject, and more importantly, we've recently brought back up an oddball platform that doesn't have networking either: our DEC Professional 380 running the System V-based PRO/VENIX V2.0, which you met a couple articles back. The DEC Professionals are a notoriously incompatible member of the PDP-11 family and, short of DECnet (DECNA) support in its unique Professional Operating System, there's officially no other way you can get one on a network — let alone the modern Internet. Are we going to let that stop us?

Of course not! Here's our barebones network stack for PRO/VENIX, the Pro's only official Unix option, downloading the Google home page on real hardware (internal addresses bleeped out) over SLIP and a Crypto Ancienne proxy for TLS 1.3. And, as we'll discuss, if you can get this thing on the network, you can get almost anything on the network! Easily portable and painfully verbose source code is included.

Time for another MacLynx save point in its slow, measured evolution to become your best choice within the remarkably narrow niche of "classic MacOS text browsers." Refer to prior articles for more of the history, but MacLynx is a throwback port of the venerable Lynx 2.7.1 to the classic Mac OS last updated in 1997 which I picked up again in 2020. Rather than try to replicate its patches against a more current Lynx which may not even build, I've been improving its interface and Mac integration along with the browser core, incorporating later code and patching the old stuff. The biggest change in beta 6 is bringing it back to the Power Macintosh with a native PowerPC build, shown here running on my 1.8GHz Power Mac G4 MDD. This is built with a much later version of CodeWarrior (Pro 7.1), the same release used for Classilla and generating better optimized code than the older fat binary, and was an opportunity to simultaneously wring out various incompatibilities. Before the 68000 users howl, the 68K build is still supported!

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!

Now that our 1987 Canon Cat is refurbished and ready to go another nine innings or so, it's time to get into the operating system and pull some tricks. As you'll recall from our historical discussion of the Canon Cat, the Cat was designed by Jef Raskin as a sophisticated user-centric computer but demoted to office machine within Canon's typewriter division, which was tasked with selling it. Because Canon only ever billed the Cat as a "work processor" for documents and communications, and then abruptly tanked it after just six months, it never had any software packages that were commercially produced. In fact, I can't find any software written for it other than the original Tutor and Demo diskettes included with the system and a couple of Canon-specific utilities, which I don't have and don't seem to be imaged anywhere.

So this entry will cover a lot of ground: first, we have to be able to reliably read, image and write Canon disks on another system, then decipher the format, and then patch those images to display pictures and automatically run arbitrary code. At the end we'll have three examples we can image on any PC 3.5" floppy drive and insert into a Cat, turn it on or hit DISK, and have the Cat automatically run: a Jef Raskin "picture disk," a simple but useful dummy terminal, and the world's first (I believe) Canon Cat, two-disk, slightly animated and finely dithered, slideshow graphics demo!

But before we get to pumping out floppy disks, we first need to talk about how one uses a Cat. And that means we need to talk a bit about Forth, the Canon Cat's native tongue. And that means we should probably talk more about the operating system too. Oh, and we should go down to CompUSA and buy a brand new floppy drive while we're at it.

Telemedicine (and mobile health generally) accumulated a hunk of public mindshare during the pandemic emergency, but speaking as someone with a day job in public health for almost two decades, it's always been a buzzword in certain corners of IT with enough money sloshing around that vendors repeatedly flirted with it. Microsoft, of course, is no exception, and on at least one occasion in the late 1990s pitched Windows CE at this space. After all, WinCE was oriented at low-power portable devices perfect for medicine on the go, and like perennial predictions of "the Linux desktop" finally taking off, Microsoft's eager sales team was certain the day of the portable physician's device had come as well.

And, well, no. I can't think of a single product from that particular salvo that actually survived, let alone thrived. But we've got one of them here — and, as you might expect, there's a few odd things about it. First off, it's a slate. (We call them tablets now, kids.)

Not a vanishingly rare form factor for a Windows CE device, though hardly the most common. It's also got a full-size dock, a camera and ... a Data General badge? The Nova-AViiON-CLARiiON-Data General/One Data General that put two I's into everything? Yup, it's really that Data General with that naming convention. In fact, as the history will show, the Data General WiiN-PAD is quite possibly the last computing device DG ever produced before EMC bought them out and shut (most of) them down in 1999. (No, near as I can determine, the name WiiN-PAD has nothing to do with the unreleased Microsoft WinPad.)

But that's not the really wacky part. Check out the CPU it's running.

That's right: it's PowerPC, the most unloved of the architectures CE ever ran on — in fact, this is the first PowerPC Windows CE device I've ever found, and I'm the self-described biggest pro-PowerPC bigot in the world. Here's an unusual form factor Windows CE device, running on the operating system's least used CPU, from a storied computer company near the end of its run, intended for medical applications, produced in very small numbers and cancelled within months.

What are we going to do with it? Well, what do you think we're gonna do with it? We're going to program it, so that we can finally have some software! And, of course, since this wacky thing was there at the bitter end, we'll talk more about the last days of Data General and what happened next.

Okay, promises, promises. Here's the first of my bucket list projects I'm completing which I've intermittently worked on for literally two decades. Now that I've finally shaken out more bugs, tuned it up and cleaned it off, it's time to let people play with the source code. This is the official 1.0 release of the Incredible KIMplement, an emulator of the one kilobyte, 1MHz MOS/Commodore KIM-1 6502-based single board computer. It provides access to the KIM's built-in TTY support (even through your computer's real serial port) and has expanded RAM with 16K of addressing space, all on an unexpanded stock Commodore 64.

It's almost burying the lede to announce that, though, because the real meat in this entry is how the Commodore 64 manages to emulate a very different 6502-based system. That piece is "6o6," for "6502-on-6502," and is a full virtualized software NMOS 6502 CPU that runs on a 6502 CPU — which I've open-sourced too. It has full control of guest code execution, including trapping undocumented and jam opcodes, and completely abstracts all memory access, making it possible to remap addresses, intercept illegal reads or writes, or even run entirely from virtual memory. On top of that, it's complete enough to not only pass a full functional test but also virtualize itself virtualizing itself:

These GIF screencasts are real-time with no tricks. Here a Commodore 64 and Apple IIe are both running a guest "hello world" payload within 6o6 (stage 1), which is nearly instantaneous, then 6o6 running the payload as a payload within another instance of 6o6 (stage 2), which is a little slower, then 6o6 running 6o6 running 6o6 running the payload (stage 3), which is glacial. But all of it works!

I mentioned earlier that while I prefer specializing in non-x86 laptops, that doesn't mean I don't collect interesting or unusual x86 laptops, like the Brother GeoBook NB-60 (I finally tracked down a mostly working NB-80C, the top of the line model, which will be the subject of a future restoration). However, this one is a unit I've had since about 1998 when they were getting rid of it at the University I worked for, and in many ways a landmark PC laptop since it was the first battery-capable system with a full 80x25 or CGA 640x200 LCD — though with a notorious deficiency: more on that shortly — and also came with a terminal and text editor in ROM. This is the 1984 Data General/One. I suspect it was primarily used to dial into the campus network using the built-in modem and ROM terminal emulator, at least until better alternatives became available, and then ended up forgotten somewhere until they were cleaning things out and asked me if I wanted it. (Yes, I was retro even before retro.) It came with its bag, power supply and modem cable, and of course I said yes. It wasn't pristine, though: the floppy disk eject buttons wouldn't stay on anymore, it couldn't remember its hardware configuration, and the main drive had issues with nearly full disks. And then there was that infamous LCD.

Ah, what the heck. I finally got a round tuit. That makes it time for ... another Refurb Weekend.

We got it in 1983, I think, so it only took me about 41 years to get around to it. This Tomy Tutor isn't a replacement system I secondarily acquired, nor is it a Ship of Theseus Frankenstein rebuild. This is my actual first computer, in its original case, on its original components, with the Federated Group sticker still on the original box. And it still works. Now, why so long? Well, for one thing, it was only supposed to be a training wheels computer because a full Commodore 64 system would have cost too much, but my folks wanted to see whether we'd take to a home computer and His High Holy Munificence Fred R. Rated was blowing these babies out for a song by then. The receipt has long since disappeared, though $99 sounds about right plus maybe around $40 or so for a joystick, cassette deck and some cartridges, compared to somewhere between $200 and $300 for the recently discounted 64 — which didn't include anything else. (It tells you something about our family finances at the time when a C64 was too expensive.) I immediately started writing my own BASIC programs on it in its perverse little BASIC dialect and when my folks indeed saved up and bought us a C64 system the next year (complete with 1702 monitor and 1541 disk drive), I refused to use it. In retaliation my best interests, my parents forcibly relocated the Tomy to storage and I went on to do even bigger things on the Commodore, making it, not the Tutor, the defining computer of my childhood. That's why there's still a Commodore 128DCR on my desk.

The other reason is that there was never really a simple way to do it. Even when I found out what CPU was actually inside (incredibly a 16-bit TMS 9995, an evolved version of the TMS 9900 in the Texas Instruments 99/4 and 99/4A), there was never a Tomy assembler, and other than its small amount of scratchpad RAM (256 bytes) the entirety of the Tutor's 16K of memory is tied up in the 9918ANL VDP video chip. That sort of architecture was typical for the family, but that also means that almost everything is stored in non-executable VDP RAM, so short of burning your own cartridge EPROMs there's no way to actually create and run a machine language program on the Tutor. The first flashcart for the Tutor didn't exist until around 2016 and it was still all ROM; furthermore, while the 99/4A could have its CPU-addressable RAM expanded (as well as the 99/8, its unreleased successor to which the Tomy Tutor is closely related), there wasn't ever a Tutor RAM expansion cartridge either until very recently. But now there are multiple homebrew options even for obscure home computers like this one, and at last I've got my own assembly language program finally running on it.

And it's all done with its own, better I/O routines (if I do say my own better self) as a basis for bigger projects. But first, a little tour of the Tutor itself, and then we'll dig in.

A quick one: xa (xa65), André Fachat's compatible fast two-pass cross-assembler for 6502, 65C02, R65C02 and 65816 processors that André and I maintain is now at version 2.4.1. This optionally expands the syntax from 2.4.0 and fixes some bugs primarily with relocatable .o65 objects. As usual, there are even more tests in its extensive conformance test-suite, and it is tested on Linux/ppc64le, Mac OS X (PowerPC, Intel and Apple silicon), AIX (its primary development platform, just to be difficult), and NetBSD/macppc and NetBSD/mac68k. You can download it and read documentation in man(1) format (converted to HTML) from the main xa65 home page. xa is free and open-source under the GNU Public License v2.

I grew up primarily with the Commodore 64, where if you wanted to do anything really cool and useful, you had to do it in 6502 assembly language. Today I still write 6502 assembly, plus some Power ISA and even a little TMS9900. I like assembly languages and how in control of the CPU you feel writing in one. But you know what would make me not like an assembly language? One that was contrived and not actually the CPU it was running on. And you know what would make me like it even less? If it were kneecapped, convoluted and limited without even proper I/O facilities.

But this particular odd little assembler dialect had the bureaucratic weight of the Japanese government behind it, because in 1969 what was then the Ministry of International Trade and Industry (MITI, 通商産業省) developed a completely artificial processor architecture to help ensure everyone taking the Information Technology Engineer Examination (情報処理技術者試験) would do so on an even keel. No one would have been an expert in this architecture or how to program it because we just made it up, reasoned the Ministry, so therefore no one will have an unfair advantage on the test.

Of course, that lasted only a few years before the specifications got out, and soon afterwards a handful of Japanese manufacturers had added it to their computers as a feature — including their pocket computer line. Through the magic of Tandy badge engineering, two of them made it to Radio Shack stores in the United States in the mid-1980s, perplexing a generation of larval nerds like me who couldn't understand what the heck it was doing there. While it was no secret the Tandy PC-5 and Tandy PC-6 Assembler feature was a fake, few people knew its history or ever did a detailed exploration. Let's dig into the dark and gloomy corners of this utterly bogus virtual CPU that a few real computers ran — sort of — and write our own cross-assembler and virtual machine so that future geeks can be just as befuddled.

In the halcyon days of analogue modems and POTS dialup Internet, when the only wireless connection in your house was between the cordless phone and the wall, anything having to do with the Web was best consumed in small bites (pun intended). If you wanted to take data with you, you downloaded it first.

Which brings us to this.

Smartwatches at the turn of the century were a more motley assortment than today's, with an even wilder range of functionality. If you had a few hundred dollars or so, there were some interesting options, even back then. But if all you had was $85 (in 2024 dollars about $150), you still weren't left out, because in 2001 you could get the Web-@nywhere (the "Worldwide Web Watch"). Load up the software on your PC and slap it in its little docking station, and you could slurp down about 93K of precious Web data to scroll on the 59x16 screen — 10 characters by 2 characters — to read any time you wanted!

That is, of course, if the remote host the watch's Windows 9x-based client accessed were still up, on which it depended for virtually anything to download and install. Well, I want 95,488 bytes of old smartwatch tiny screen Web on my wrist, darn it. We're going to reverse-engineer this sucker and write our own system using real live modern Web data. So there!

xa (xa65) 2.4.0 is the newest release of André Fachat's fast and portable two-pass 6502/65816 crossassembler; yours truly is the current maintainer and I just punched "live" on it tonight. It runs on Un*xy things and Windows (with Cygwin or msys2 or similar), and probably other operating systems as well. xa 2.3 has had a good run, but it's served 17 years as the minor release (no joke: 2.3.0 came out in 2006) and time marches on. There are new features to add and old cruft to sweep away. But it's still compatible with all the systems 2.3 was compatible with and adds several new features, including:

• Listing mode, allowing side-by-side byte output with the lines in your source. You can even emit it in HTML.
• A ca65 compatibility mode that allows many of the same pseudo-ops and "cheap local labels" support. Although this obviously doesn't accept every feature in ca65, it can ease translating your assembly source considerably — because once you switch to xa, you won't want to go back. :) This feature is also used for other compatibility options such as MASM and allowing some C-like expressions.
• Assertions at the preprocessor level (#error) and assembly level (.assert), allowing controlled errors when static assertions are violated.
• Linker enhancements for .o65, including deferred linking of undefined symbols.
• You can now get the assembler major and minor version in the preprocessor with XA_MAJOR and XA_MINOR. Other predefined macros may appear in future versions.

Because this is a new minor release, there are incompatibilities. The escape character in quoted strings is now the standard backslash (\) instead of the carat (^), and recursive multi-line /* */ comments are no longer allowed, unless you ask for them with -XXA23. Obviously these features are deprecated, and they will be removed in a future version. Our expanded testsuite is designed to look for regressions and we are very conservative about that, but it's possible we've introduced other changes that may interfere with edge cases or undefined behaviour in your source, and such changes are unlikely to be reversed.

This release also deprecates printcbm(1), since it's not been touched in a long time, was never really a core part of an assembler suite, and VICE petcat does everything it did and more (even I don't use it; I have my own Perl detokenizer). It will be removed in a future version also. Of things that were already deprecated in 2.3.x, the old 16-bit argument syntax for 65816 mvn/mvp is now not accepted and the old -S and -x options are finally removed. If you need those, you must use 2.3.14.

Between 2.4.x and the next version (2.5 or 3.0, depending on my mood and the scope), we will be slowly embarking on cleaning up the source code's readability which has been an admitted issue for years. One big reason for not doing this earlier was because of regression risk and as André and I are xa's most important users, we definitely didn't want cleanup to impair our ability to build our own projects. Now that we have an extensive and growing regression testsuite, this can be done slowly in stages so that we have something more maintainable without introducing new bugs in the process or incompatibilities with the C compilers we already test against (our oldest in the test rotation is egcs-1.1.2 and it probably works on even earlier ones). As these changes are expressly intended not to change code functionality, they will incrementally roll out with future 2.4.x releases.

You can download it and read documentation in man(1) format (converted to HTML) from the main xa65 home page.

Most of my systems are microcomputers (and commensurately sized), though I do have some moderately larger beasts: you've met homer, my 1987 HP 9000/350 rack system, and Floodgap is powered by uppsala, a 2U-in-a-tower IBM POWER6 520 running AIX. But my first "large" machine, and indeed the first Unix server I ever personally owned, was this Apple Network Server 500. Its name is stockholm. A mini-fridge-sized server with its famous translucent blinkenlight-friendly front sliding door and oodles of drive trays, this $11,000+ box (almost $22,000 in 2023 dollars) sat forlorn and unused at the University I was employed with as an IT working stiff in 1997. The bookstore had bought it at a substantial academic discount for their UniVerse-based (a Pick descendant, now Rocket U2) point-of-sale system, but the vendor wouldn't support the hardware anymore after then-CEO Gil Amelio cancelled the ANS line, so it got dumped off as surplus in the service bay where it lurked in a corner. As it was just sitting around, I got to use it as my personal server, shown here circa 1998 in my old office on a bad scan from a bad Polaroid. In this picture it's acting as a terminal server for my Commodore SX-64 with a CMD SwiftLink 6551 ACIA serial cartridge (the SX-64 is sitting on a parallel port switchbox because its handle got busted).

About a year later the University said they'd throw it in with my consultant compensation because they wanted to get rid of it anyway, so it became officially mine, and I was delighted to have it. That machine, later upgraded to 200MHz and 512MB of parity FPM RAM, variously powered my E-mail and the Floodgap gopher and webservers from 2000 to 2012, and still does backup duty when the POWER6 has to be down for repairs.

That's because the POWER6 runs everything the ANS did — because the ANS also runs AIX. The ANS 500 and 700 were not Apple's first Unix-specific servers (that would be the Apple Workgroup Server 95, a Quadra 950 using a special PDS card that only worked with A/UX, Apple's own Unix with a bolted-on Mac compatibility layer), but they were Apple's first Mac derivatives that could not boot classic Mac OS at all and natively ran a non-Apple operating system. Indeed, most people treated it as exactly that, a big Unix server from Apple, and at the time I did too.

However, there was a secret weapon hidden in ANS AIX most of us at the time never knew about. Built-in to the operating system was a fully Unix-native AppleTalk stack and support for receiving and sending Apple Events, surfaced in the form of Apple's disk administration tools and AppleShare. But Apple had a much more expansive vision for this feature: full server-client "symbiotic" applications that could do their number-crunching on the ANS and present the results on a desktop Mac. Using the Program-to-Program Communication Toolbox ("PPCToolbox"), and because AIX's throughput far exceeded anything the classic Mac OS ever could ever handle, an ANS could augment a whole bunch of Macs at once that didn't have to stop to do the work themselves.

Well, today we're going to write one of those "symbiotic" applications doing something this little Mystic Color Classic could never efficiently do itself — accessing and processing a JSON API over TLS 1.3 — and demonstrate not only how such an client application looked on the Mac side, but also how the server component worked on the AIX side. If you're lucky enough to have an ANS running AIX too, you can even compile and run it yourself. But before we do that, it might be a little instructive to talk about how the Apple Network Server came to run AIX in the first place.

Giving the 1976 1K RAM, 1MHz 6502-based KIM-1 single-board computer bubble memory storage was all well and good, but the basic unit is still just six numeric LEDs for its display. Let's solve that problem. Here's a sidecar screen for my KIM-1 that's large enough to be useful, small enough to be portable, and efficient enough to be powered by my unit's built-in power supply. Plus, it can be driven by the KIM-1's unallocated I/O lines so that its 20mA current loop terminal interface remains available, with bonus points for being self-lit so you can see it like the LEDs. And the output driver takes up just 64 bytes of RAM.

I don't always often wear watches. But when I do, I prefer Palm PDAs. Wired to my wrist. Announced at COMDEX in 2001 but infamously stalled, cancelled and revived prior to release in January 2005, it's still not much bigger than my wife's Apple watch: The opinion of reviewers at the time was something like "nice try anyway." Battery estimates were overoptimistic, some buttons were missing, and the CPU and operating system were already outdated. Nevertheless, it was a real Palm OS PDA that could sync to your desktop and run real Palm OS applications, complete with a tiny screen and a ludicrously tiny stylus.

But little was said at the time about connectivity and networking. It could IR-beam (consuming the battery) and sync, but other than muted complaints about missing Bluetooth (which would have consumed even more battery), no one said anything one way or the other about getting it on the Internet. And I'm all about Palm devices on the Internet.

It turns out there's a reason for that, and we're going to patch the operating system so we can make the Fossil Wrist PDA into what may be the smallest (and first wrist-mounted) Gopher client. That also required an update to the Overbite Palm Gopher client (which you'll want for your 68K Palm anyway), and then there's the matter of the battery refusing to charge as well. And finally, we want to make all of this portable!

But let's start with the history first ...

I've been working off and on doing further Mac-ification to my updated fork of MacLynx, the System 7-compatible port of the venerable text browser Lynx for classic 68K Macintoshes (and Power Macs) running A/UX 3.x or System 7.x and later. There's still more to do, but a lot has been worked in since I last dropped beta 4, so it's time for another save point. Meet MacLynx "beta 5."

This article has been revised with recollections and corrections from former Apple employee Al Kossow, some good folks on Hacker News and the Vintage Computer Festival forums, and an anonymous individual with high-level knowledge of the project. One of the coolest things to come along in the 68K Mac homebrew community is the ROM Boot Disk concept. Classic Macs have an unusually large ROM that contains a fair bit of the Mac OS, which was true even in the G3 New World Mac era (it was just on disk), so it's somewhat surprising that only one Mac officially could boot the Mac OS entirely from ROM, namely the Macintosh Classic (hold down Cmd-Option-X-O to boot from a hidden HFS volume with System 6.0.3). For many Macs that can take a ROM SIMM, you can embed a ROM volume in the Mac ROM that can even be mirrored to a RAM disk. You can even buy them pre-populated. How's that for immutability?

Well, it turns out Apple themselves were the first ones to implement a flashable Mac OS ROM volume in 1994, but hardly anyone noticed — because it was only ever used publicly in a minority subset of one of the most unusual of the Macintosh-derived systems, the Apple Interactive Television Box (a/k/a AITB or the Apple Set Top Box/STB). And that's what we're going to dig into — and reprogram! — today.

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!

Last weekend was sad, so let's do something fun. I've mentioned I collect non-x86 laptops and portables (and not just PowerBooks: see my previous entries on the "MIPS ThinkPad" IBM WorkPad z50, the PA-RISC SAIC Galaxy 1100 and these Sun Ray laptops, among others) because they're always — and sometimes wildly — different than your average Best Buy special.

Every rule's got an exception, though:

I will try to pick up x86-based systems with "personality" (as I see fit). The PCjr, for example, had personality: love it or loathe it, it was definitely different. And the Brother GeoBook series of laptops were certainly different too, late 1990s appliance-style laptops sold at low-end prices intended for basic home tasks. Besides their chunky form factor, flash memory instead of a hard disk and an entire operating system in ROM, that operating system they ran was also different: PC/GEOS, the bigger spiritual sequel to the GEOS operating system for the Apple II and Commodore 64/128. Out of the box and built-in, you got a capable word processor, spreadsheet, drawing program, file manager, and basic personal information management, plus pervasive fax support for the included fax/modem. If you wanted, you could even install a basic web browser and E-mail client included on floppy disk.

And by golly, I do mean basic. But it was notable that a browser option existed at all, so we should make it live again. Let's take a tour around the unit's built-in applications and explore its guts, then get its PPP connection working again over null modem, hack the browser to understand what an HTTPS URL is and forward it to a Crypto Ancienne proxy, and get the GeoBook back on the Web and accessing current sites. Slowly — but it works! No Betteridge's law around here! (Teaser: see it load Hacker News and Lobste.rs at the end.)

But first, how on earth did GEOS get into the ROM of a chonktastic plastic laptop?

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