The MIPS ThinkPad, kind of

Pop quiz: what classic brand of laptop is this?

I'll give you another hint.

Bright-red TrackPoint and mouse button trim, classic keyboard font, IBM logo on the top. It's a ThinkPad ... right?

Well, obviously someone on IBM's design team wanted you to think so. But turn it on and it itself announces it's not a ThinkPad:

Say hello to the RISC ThinkPad that's not a ThinkPad, the IBM WorkPad z50.

Refurb weekend: New batteries for the Palm Pilots

Everything portable has a battery, and every portable thing's battery dies. This is bad on earlier PalmOS devices that lack a non-volatile file system because they'll lose their data and you'll lose your mind. Fortunately many of my stable of Palm Pilots and other PalmOS devices use regular old batteries (like my original USRobotics Pilot 1000 and Handspring Visor Deluxe); of my rechargeable units, the AlphaSmart dana has a replaceable battery (I have multiple spares, or you can use regular batteries), and so does the Palm Centro, which has a non-volatile file system to boot. This is another reason why those two are my favourite Palm devices.

Confirmed! the MOS 7600/7601 Pong chip is a true microcontroller

In a previous article I discussed the MOS 7600 and 7601 "Pong in a chip" ICs, manufactured by MOS Technology (of the famous 6502) and actually used in a number of late 1970s Pong clones, including two that eventual parent company Commodore Business Machines sold under their own name. Most notably they appeared in the Coleco Telstar Arcade console, an unusual "triangular" machine in which specific variants of the 7600 were used as its cartridges, but were also used in a number of other Pong clones through around 1978.

The question at the time was whether the 7600 actually had ROM in it (i.e., was a true microcontroller running a stored program), or whether it was simply playing games using discrete circuitry. The Telstar Arcade — and its relative, the confusingly named Telstar Gemini, not to be confused with the separate Coleco Gemini — demonstrated that other variants of the 7600 were capable of more sophisticated games than just ball-and-bat Pong variations, including primitive versions of pinball and road racing, even though most systems using the 7600 used it purely for Pong. On the other hand, no data sheets have survived to the present day and at the time my Google-fu uncovered no die photos to review, so I could find no substantiation for the occasional claims that it did.

Well, we now definitively know the answer and a bit more thanks to Sean Riddle, who actually did decap and photograph a 7600-002 die (the variant in Telstar cartridge #1, with racing, Pong and skeet shooting) and a 7600-001 (the most common three-Pong-and-skeet variant used in many machines, as well as in Telstar cartridge #2), and to Ken Shirriff, who made an extensive survey of the die, discussed with Sean and I attributes he noted, and posted a thread about it. Here's my own summary of the discussion plus a few other details I've run across since writing the original post.

What the KIM-1 really needs is bubble memory (plus: 20mA current loop for fun and profit)

It seems like everything has flash. Flash mobs, flash photography, Flash Gordon, flash memory. (Other than the past couple years, of course, which haven't been very flash.) And, because solid-state-all-the-things, you can get flash storage devices for tons of classic computers where even the tiny microcontroller in the SD cards is probably more powerful than the systems they're being interfaced to. Why, you can even connect one to an MOS KIM-1, the famous mid-1970s MOS 6502 single-board computer. Now at last you don't need to rekey everything in or screw around with an audio recorder.

But, of course, if you've read this blog for any period of time you know I don't go in for that sort of new-fangled nonsense around here. I like my retrocomputing frivolities period-correct. What the KIM-1 really needs as a mass storage medium ... is bubble memory.

Plua 2 continued: open source under GPL for your classic Palm

More good news for classic PalmOS development. In previous articles, I've introduced you to Plua, a PalmOS 3.5 native version of Lua 5.0.3. By generous permission of Marcio Migueletto de Andrade, its original developer, we already have a 64-bit fixed open source version of the "cross-compiler" plua2c, which we use to build Overbite Palm.

Well, Marcio has uploaded the source code for Plua 2.0 itself, which I have patched up to build on my Power Mac G5. This is really great to see because now the runtime can be updated with more features and for more devices, particularly the wide-screen AlphaSmart dana.

The dark ages of history, circa 2030

I have no intention of explaining how the correspondence which I now offer to the public fell into my hands.

* * *

The Pong you could program, possibly: the MOS 7600/7601

UPDATE: It is a microcontroller! Read more.

When people think microprocessors that MOS Technology made, they think of the 6502 and its many derivatives, as one should (which are of course frequent topics on this blog too) — but there might have been another one.

In the nethermists of time when polyester ruled the earth, G-d (or at least Al Alcorn) created the Pong machines. These started out as discrete logic that was hard-wired to play the game, both in the original 1972 Pong cabinet and then miniaturized for the Atari 3659 Pong-in-a-chip that was in the first home Pong console (sold through Sears) in 1975. By greatly reducing the component count Atari's new chip made the console cheaper to produce and assemble, significantly aiding mass production. Here at Floodgap orbiting headquarters we have an original Atari Ultra Pong Doubles with the later C010765, referred to as the "ultimate" Pong with 32 game variations for up to four players, and the last and mightiest of the Atari first-party consoles circa 1977. Still, like the original 1972 Pong, it was nevertheless controlled by hardwired logic; ultimately it just played Pong, and that was it. But that's not what this entry is about.

The Pong console wasn't the first home console; that was of course the 1972 Magnavox Odyssey, developed by Ralph Baer as a side project for defense contractor Sanders Associates, and licensed to Magnavox for sale. (For that matter, it wasn't even the first home Pong console: that was arguably the Universal Research Labs Video Action II, which ran ads for Christmas 1974 in an attempt to sell unused inventory made for ailing Pong licensee Allied Leisure and beat most of the others to market in 1975 by a couple of months.) However, it was the first Pong-in-a-chip, something the other fledgling semiconductor companies had yet to duplicate. Texas Instruments was supposed to be developing a single chip implementation for Magnavox's sequel two-game Odyssey 100, but it wasn't ready until later that year for the Odyssey 200, and the 100 ended up with four chips instead despite its simplified games. But that's also not what this entry is about.

The other thing Magnavox had besides their early market advantage was Ralph Baer's patents, and a plausible legal case. Atari themselves capitulated in 1974, determining they lacked the resources to invalidate his patents, and paying a settlement and licensing them instead. Other vendors followed suit. One of these companies was General Instrument, who devised their own black-and-white Pong-in-a-chip called the AY-3-8500, also in 1975. Ralph Baer was aware of its development from the licensing process and had a previous informal relationship with toy company Coleco's president Arnold Greenberg. This exchange was all business: Baer's patents represented a significant source of income to himself and the company he worked for, and if GI could move a lot of chips there'd be a big piece of the action in it. Coleco became GI's first customer and built the AY-3-8500 into the 1976 Coleco Telstar, which went on to sell roughly a million units. The AY-3-8500 was thus firmly established in the market and even Magnavox used it for subsequent Odyssey consoles to the great chagrin of Texas Instruments, including the 1977 Odyssey 3000 which we also have at Floodgap Orbiting HQ. But that's not what this entry is about either.

The AY-3-8500 naturally had its competitors, and Magnavox-Sanders-et amis got a piece of them too, though the design was so cheap and easy to work with that General Instruments crowded most of them out of the market. Besides TI, National Semiconductor introduced the colour MM-57100N, but despite its capabilities was too expensive to dislodge the market leader (and even its graphics advantage was eroded by the AY-3-8515, which was a bolt-on colour encoder for the 8500 and incorporated into later chips). However, there was one company at that time that was very good at making cheap chips cheaply, and it needed money fast. That company was MOS Technology, and finally that's what this entry is about.

Crypto Ancienne 2.0 now brings TLS 1.3 to the Internet of Old Things (except BeOS)

Who says you can't teach an old box new tricks? We did it before and we're doing it again. Crypto Ancienne ("Cryanc") is a TLS implementation for pre-C99 beasts and monstrosities featuring carl, a simple curl-like utility that serves as a demonstration command line tool and even as an HTTPS-over-HTTP proxy for suitably configurable browsers. Many operating systems are supported and a number of compilers too (not only gcc going back to version 2.5 and the egcs days, but also clang, MIPSpro, Compaq C and even Metrowerks CodeWarrior). Now, after a lot of late night hacking, screaming and unspeakable acts of programming, tons of bugs are fixed (including a long-standing big-endian issue with ChaCha20Poly1305) and the core has been significantly upgraded such that almost all of the supported platforms now support TLS 1.3.

And what are those supported platforms? Why, here's some of them as they were being cruelly whipped to perform like beaten dogs for your entertainment:

CP/M is (more) officially open source

This is good news! Let's see more of these classic operating systems go open for a new retrocomputing generation. Specifically, from Bryan Sparks, the current owner of DRDOS and associated IP from Digital Research,

Let this paragraph represent a right to use, distribute, modify, enhance, and otherwise make available in a nonexclusive manner CP/M and its derivatives. This right comes from the company, DRDOS, Inc.'s purchase of Digital Research, the company and all assets, dating back to the mid-1990's. DRDOS, Inc. and I, Bryan Sparks, President of DRDOS, Inc. as its representative, is the owner of CP/M and the successor in interest of Digital Research assets.

This was to clear up an apparent earlier misunderstanding that Sparks' earlier open release of CP/M in 2001 was restricted to distribution via a particular site. Sparks clarified this was not his intent.

Overall, would I prefer a more conventional open-source license? Sure. But he didn't have to do this then, he didn't have to do this now, and he did. So, thanks, Bryan.

A brief dive into Power Mac INITs and NVRAM scripts, or, teaching Mac OS 9 new device tricks

Although I'd much rather use a real Power Mac, and of emulators I tend to use my own bespoke hopped-up fork of SheepShaver for the POWER9 CPU with my daily driver, QEMU is still important for Mac OS 9 emulation because it handles the full system rather than the quasi-paravirtualization approach of SheepShaver. Indeed, certain classes of application can only run in that context.

However, because QEMU is a much lower-level emulator, that means that things like mice are also emulated, and that tends to chug a bit even with QEMU's JIT (currently KVM-PR, the virtualization system for Power ISA, does not work properly with Mac OS 9 in QEMU for reasons that have not yet been determined). If you use the default mouse support, the mouse is entirely maintained by the operating system and the polling frequency is just slow enough to be frustrating, and you have to grab and ungrab it all the time. The normal solution is to use an absolute pointing device like the QEMU tablet and solve all these problems at once, but the classic Mac OS doesn't support it and the existing Wacom driver doesn't work. (SheepSforza, on the other hand, hooks the system mouse and system mouse pointer into the guest OS, so it's much more responsive and transparent if I do say so myself.)

To support this and other QEMU virtual devices requires updating the guest Mac. And, happily, there are now two approaches at least for doing so for the QEMU tablet, which make an interesting comparison on how we could get other devices supported on the classic Mac OS.

Overbite Palm 0.2

Overbite Palm 0.2, the Gopher client for classic Palm devices, is now available (see it running on real hardware). This update includes Shawn Mulligan's Sony Clié key patch (thanks!) plus more aggressive memory management and menu compression, which should not only increase the number and length of documents that 68K Palms with their pathetic dynamic heaps can view but also cut down on the fatal Plua-generated "out of memory" errors that our memory heuristics failed to anticipate. Additionally, all transfers are hard-capped to 32K raw data since this appears to be the empiric limit for the native scrolling text gadget. It was tested on my Palm Centro and AlphaSmart dana, as well as my emulated m515. You can get it from Github (plus Plua source, natch) and I will be making a place for it on the Floodgap gopher server as soon as I get a round tuit.

prior-art-dept.: ProleText, encoding HTML before Markdown (and a modern reimplementation)

Steven P. Spackman allegedly once observed that "flat text is just never what you want." Which, I guess, is true: half the historical advances in computing have come from figuring out ways to tart up plain text, whether embedding control codes or out-of-band styling or in-band markup. However, with the exception of out-of-band styling (I always liked the Macintosh text file formats that kept the text in the data fork and the styling in a resource), you still needed to parse the file or at best you'd get blocks of text separated by gobbledygook. Enhanced text formats like Markdown were thus designed to make cognitive sense to human eyes without further parsing — but also encoding sufficient metadata to facilitate improved ways of rendering the document.

Markdown circa 2004 has displaced most of the others today, but it explicitly never claimed to be the first such human-readable format; indeed, AsciiDoc predates it by about two years, reStructuredText a year before that and MakeDoc about a year before that. For that matter, some of the concepts popularized in Markdown might not have existed at all were it not for earlier ancestors like 2002's Textile.

But a forgotten rich text language predates most of these, with the interesting property in that much of the markup is encoded using trailing whitespace, almost a fusion of in-band and out-of-band styling systems. If the whitespace is munged, it's largely just a text document (like those particular Mac files if you pass along only the data fork); but if it passes through intact, an intelligent converter can use attributes encoded in the whitespace to style it into HTML. That system is ProleText.

So long, home T1 line; hello, hacking the T1 router

Floodgap has had a T1 line since I moved into this house in 2011. I'm one of those weirdos who runs my own hardware and prefers to avoid co-lo so that I can access things whenever I want despite the additional logistical complexity, and also acts as useful immunity against acquiring other expensive hobbies. The area was boonies-ish when I moved here (big house, cheap price, bottom of the market after the housing crash), arguably still is, and for at least several years there was no DSL due to its distance from the central office (fiber? hahahaha). Cable was around, but the only cable provider at the time refused to pull a run or even quote me a price to do so despite sending contractors on three separate occasions to scope out the site. After several weeks of downtime culminating in me making a formal complaint to the Public Utilities Commission, they agreed to stop messing around and released me from the contract. Of course, by then I was down for nearly a month.

T1 lines have never been cheap, though back in the day they were prized because at 1.536 Mbit/s each way they were comparatively high capacity. At my first job out of college in 1997 the university had a T1 connected to an AdTran CSU/DSU, adding more T1 lines on and bonding them for additional bandwidth until they upgraded to optical fiber. A friend of mine in the very late 1990s had his own residential T1 (this was when consumer DSL was uncommon and 56K dialup was still frequent) that his employer paid the bill for, reportedly close to a cool grand a month in those days; he would never been able to afford it otherwise. On a cost basis alone (and certainly dollars per megabit) a T1 would have been far from my first choice, but I needed a reliable server-grade connection and I couldn't find any other alternatives at the time, so if I wanted to get my hardware back online from the house I was going to have to pay up and get one. Rather than use the actual telephone company I went with an overlay vendor and was quoted $295 a month on an annual contract for a 16-address netblock plus $199 installation. Now going into my fourth week of downtime, I signed immediately. They called the telco who came out the next week, installed the smartjack (we'll talk about what this is), took over both telephone wire pairs to the house and wired it into the pedestal — conveniently, the local telco pedestal is literally in my backyard. Good thing I'd already moved the house alarm modem to a wireless connection since I could no longer have a landline now. I then ran lines from the smartjack into the server room (thanks to the telephone guys I used to work next to when I was consulting I already had good experience with a punchdown tool), the vendor came out the week after that with the T1 router, and finally Floodgap was back up.

The original idea was to use the T1 until something less expensive came along, but the T1 just plain worked and was always highest priority on service calls, so inertia and inflation eventually turned the $295 a month into $399 and a 12-month contract into 48. Still, it was a tariffed line with a service-level agreement, I had plenty of addresses and my personal bandwidth requirements have always been modest — I don't cloud, I rarely stream and YouTube is worse than television — so I ended up just using the T1 as my personal ISP at the same time and avoiding a second bill. This worked out fine for awhile except, of course, for love. My wife needed her Netflix and her iCloud, and by then the previously intransigent cable provider had been bought by someone else (fiber? hahahaha) who didn't know any of the previous history; they came out and finally pulled an RG-6 cable run five years after the fact, and switched us on. I moved the Wi-Fi to the new cable net and her bandwidth needs were thus met in the manner to which she was accustomed. We joke about the his'n'hers networks: I still had my lab and servers on the T1, and everything else including her devices was on the cable.

Well, it was good we did that because I mentioned in January this year that the vendor (which had changed owners twice over the years) was abruptly getting out of the residential T1 business and I had a month before it was switched off. I may well have been their last customer in the region. So I'd like to publicly thank John who reached out and offered a no-strings VPN arrangement — which I'm routing over the cable — to keep Floodgap online while we consider our housing options in a market as bad as it was good when I first bought the place. We turned the VPN on and the vendor turned the T1 off. They never asked for the router back and the smartjack still sits in the back of the house.

Now it's Memorial Day in the United States and I suppose I'll have to do something about that now superfluous wiring run sometime soon. Before I do, though, let's document the T1 for a generation who may have never seen one ... and figure out something fun to do with the router they left behind other than, you know, routing stuff.

Like every computing story, this one begins with a box.

Gopher on the Palm Pilot and the pitfalls of PalmOS connectivity

To start, an apology for 18 years of tardiness.

In 2004 I was working on a gopher client for my Palm m505, written in Lua using the new hotness of Plua 1.x, which supported UI, graphics and networking built-in. I christened an early implementation as "Port-A-Goph" and it even got a mention in Wired. Due to socket bugs in that version that never got fixed, I deferred the release until I could rewrite Port-A-Goph for Plua 2. Over the next few years I worked on it intermittently but got distracted by other projects, and eventually after moved to iOS and then Android I stopped carrying a Palm around with me entirely. Since I have my own Gopher client on Android, the PalmOS version sat in suspended animation.

Well, it's time to dust off the resurrected Port-A-Goph, newly christened into the Overbite client family as Overbite Palm. Along the way we'll make sure it works on a selection of real hardware:

Tonight we're gonna log on like it's 1979 (Telenet, Dialcom and The Source)

Teletypes may have killed a lot of forests by emitting every line to hard copy instead of a screen, but there's something to be said for the permanence of paper, especially when people hang onto it for some reason. While getting duff units to build a functional Silent 700 Model 765 ASR teletype, which will of course be a future article, one of them was more interesting for what else it came with: a set of teletype transcripts of several users logging onto The Source, one of the earliest online services, and a complete photocopy of the service's user manual. So get out your copy of Pink Floyd's The Wall, start blasting "In The Flesh," and let's head back to 1979 and 1980 when these transcripts were printed. We'll talk a little bit about the service generally and then log on exactly as these people did — because the Silent 700 transcripts indeed show exactly what transpired and how they used them.

prior-art-dept.: 5 letter words (Jim Butterfield's Jotto)

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.

xa 2.3.13 and dxa 0.1.5

I've updated xa, André Fachat's venerable 6502 cross-assembler, to version 2.3.13, but also dxa, its companion disassembler based on Marko Mäkelä's d65, to version 0.1.5. I keep promising version 2.4, but somehow for years we never noticed that // and /* */ in quoted strings get improperly treated as comments instead of part of the string, and that seemed a pretty important bug to fix. A test case is now part of xa's fairly extensive regression analysis suite. 2.3.13 also includes patches for segfaults with parameter handling (but never run xa as root, kids, it kills kittens) and a miscellaneous correctness fix with null file handling. Although its development home platform remains AIX (with gcc) because I'm one of those people, and portability mumble mumble weird operating systems mumble endian, it is also tested and validated on Linux/ppc64le (gcc and clang), NetBSD/macppc and NetBSD/mac68k (gcc), and Mac OS X macOS (gcc on PowerPC, and clang on x86_64 and Apple silicon). Seriously, this is the last 2.3 release, dammit. No fooling. I mean it.

dxa's development was a little more colourful. This started with a file that didn't disassemble correctly (Paradoxon BASIC from 64'er, as it happens) because apparently d65 was never able to handle files that stretched riiiiiiiiiiiight up to the very last addressible byte ($ffff), let alone files that overflowed the addressing space or were bigger than 64K. However, even with that problem fixed, this particular test file also caused dxa to emit completely nonsense branches with unpossible displacements and even jumps to non-existent labels. This violates its core guarantee that you should be able to take dxa's output, feed it back into xa and get the binary you started with. It turns out that this is due to some weird C casts used for interpreting relative branches, so I made them more explicit, plus changes in the C preprocessor that caused the macro to check if a label exists to evaluate to true in one place and false in another. I think this file made a great test vector, so now dxa has a test suite too (make test; xa is naturally required) using it and a DOS wedge routine, and I'll probably throw in more exemplar code in the future. This new test suite is already earning its keep: it found a new bug when dxa is compiled with clang, which required even more reworking of the same section and some nearby code. Interestingly, even though now the test suite passes on all the same platforms as xa, dxa-built-with-clang generates subtly different output than dxa-built-with-gcc despite the fact the assembly files they both generate will yield bitwise identical binaries. Most of this seems to circulate around detecting vectors; clang flavour finds this in some places that gcc doesn't and vice versa. It's deterministic and predictable, but I'm not sure which one of them is "doing it right," so for now it'll be a curiosity until I can dig more into the differences.

Both xa and dxa are available under the GNU Public License v2.

KIMdle: Sorta-Wordle for the KIM-1

UPDATE: I'm trying to solve a debouncing bug for someone who reported it, though I can't reproduce it. If you have a similar issue on real hardware, please try the version up now.

Wordle mania (trademark, probably, of the New York Times) continues. My wife and I, who bonded over word games and later got married because that's how you pick a good life partner, play daily on a private instance, except that she's 19 hours ahead so she has to be careful not to give out spoilers. Retro has gotten into the action. There are Wordle ports for Windows 3.1, Palm Pilots, Game Boys and at least three versions for the Commodore 64, such as this, this and this poop themed one called Turdle, ha ha ha.

Still, however, while these ports ditch dependence on JavaScript and HTML, they still rely on other modern conveniences such as, you know, a screen, a keyboard, and multiple kilobytes of RAM.

You see where I'm going with this.

Refurb weekend: Texas Instruments Silent 700 Model 745 teletype

The first terminal I ever used was a teletype. Somehow my buddy when we were in high school got a hold of this weird "printer typewriter" which was none other than one of the famous Texas Instruments Silent 700 series.

Overbite Android 0.2.6

UPDATE: I've received a couple reports the .apk doesn't install. The actual reason is that the keys, and thus the author signature, have changed and Android doesn't let you replace an app with another app signed by "someone else." Delete the old version and install this one fresh rather than installing it over the old one. Sorry about the inconvenience.

Overbite Android 0.2.6 is available, the (persistently alpha-quality) native Gopher client for Android. This is merely a maintenance update for version 0.2.5 to fix visual issues with dark mode and Android 12, and a couple edge crashes. The screenshot is from my Pixel 6 Pro (the camera still crashes on it, Google, damn your eyes) running Android 12 but this release will still work with and is tested all the way back to 4.0.3 (Ice Cream Sandwich). After all, this is a retrocomputing blog! Source code for Android Studio (built with Bumblebee) is available under the BSD license.

Unfortunately, it is likely that 0.2.x will be the last release of Overbite Android to support OS versions prior to 9.0 (Pie). This is because right now I'm running Android Studio on an M1 Mac (hoping to get it working properly on my Talos II, but not there yet) and it is apparently not possible to run API 27 or earlier under the emulator. (I tried myself and it just dies immediately. There should be a way to make it run within a full system emulator, but it doesn't.) For testing purposes I dug out an Intel MacBook Air with a previous version of Android Studio, booted up a emulated Galaxy Nexus with 4.0.3 and checked the APK installs and runs, but this is rather inconvenient to test with for obvious reasons, and Google doesn't make it easy for you to keep working with old Android versions if you're trying to also support new ones. For the time being, though, I still think supporting a 10+ year old release of a mobile operating system is pretty darn good, and if I do any other 0.2.x bugfixes I will at least test them to the extent I can on Android 4 before release.

Yes, I know Overbite Android still doesn't do downloads yet. This is largely laziness on my part, since I'm only scratching the itches I personally have, and I haven't needed to download files via Gopher to any of my Android devices so far. But that's probably the major feature I plan to introduce in 0.3 when I get some time to sit down and actually write the support.

Old releases compatible back to Android 1.5 (Cupcake) are still available, including source code.