MacOS Extensions pack for the Apple Network Server v1.0

By now regular readers of this blog are quite familiar with my affection for the 1996 Apple Network Server, Apple's Unix-through-and-through $10,000+ server that only shipped with, and only officially ran, Harpoon, its unique superset of IBM AIX. An ANS 500, the lower tier of this dorm fridge-sized computer, was the first server I ever personally owned, a nearly-new hand-me-down after Steve Jobs convinced Gil Amelio to cancel the machine and the bookstore's vendor at the University I worked for wouldn't support it anymore. There are several fascinating features present in Harpoon that were never implemented in any other Apple product. Currently I have three, that original ANS 500, this ANS 700 here which I use for testing, and a battery-bombed EVT prototype (a so-called "Shiner ESB" that used to be at Netscape).

The ANS was strongly based on the Power Macintosh 9500 and Apple was known to have demonstrated the ANS with Mac OS during development, but this confused potential buyers, causing the ability to boot Mac OS to be stripped from production systems. While then-CTO Ellen Hancock claimed in 1997 a ROM swap would enable the ANS to boot Mac OS again and Windows NT, these ROMs were believed to be vapourware until a former Apple employee presented a working dump of both the preproduction ROM and the later ANS Mac OS ROM. A prototype Windows NT ROM also emerged from another former employee, though there are pieces missing and booting Windows NT natively on the ANS is still a work in progress (hopefully to be the subject of a future article).

It turned out I had one of the preproduction ROMs myself and didn't realize what it was. Because the later Mac OS ROM was apparently unfinished, it doesn't properly support the L2 cache and consequently runs substantially slower, and it can't boot AIX. The preproduction ROM does boot both operating systems and does support the cache. On the other hand, it doesn't support the on-board video or the front Fast Wide SCSI-2 controller, the on-board MACE Ethernet doesn't work, and after MacOS first boots, the next restart without zapping the PRAM will come up with a black screen.

The good news is, many of the issues with the preproduction ROM in Mac OS can be fixed or worked around in software. So I've fixed or worked around many of them in software: the MACE Ethernet is fixed, the on-board video is now supported, and the ANS can restart properly back into Mac OS. Plus, because it's the preproduction ROM, you can still boot AIX, thus preserving the entire historical reason for Shiner's existence. Here's the first cut of that software and how it was developed.

6o6 v1.1: Faster 6502-on-6502 virtualization for a C64/Apple II Apple-1 emulator

I'm doing periodic updates on some of my long-term projects, one of them being 6o6, a fully virtualized NMOS 6502 CPU core that runs on a 6502 written in 6502 assembly language. 6o6 implements a completely abstracted memory model and a fully controlled execution environment, but by using the host's ALU and providing a primitive means of instruction fusion it can be faster than a naïve interpreter. This library was something I wrote over two decades earlier for my KIM-1 emulator project for the Commodore 64, and relatively recently I open-sourced and discussed it in detail. It runs on just about any 6502-based system with sufficient memory.

For this update I made some efficiency improvements to addressing modes, trimmed an instruction out of the hot path, provided an option for even more control of the 6502 interrupt flag and implemented a faster lane for direct stores to 6502 zero page (as well as the usual custodial and documentation updates). And, of course, any complex library needs a suite of examples, and of course, any update to a complex library demands new examples to play with too.

So, given that this year is Apple's 50th anniversary (and, as it happens, my own 50th year of existence personally), what better way to show off a 6502-on-6502 virtualization library than with an Apple-1 emulator ... that runs on the Commodore 64 or Apple II? Now yea, verily, this is hardly the first such example and several others have done something of the sort, but I submit that 6o6 makes our take on it here unique, and as a bit of fun we'll discuss the Apple-1's hardware and look at all that prior 8-bit emulator art for comparison (for the C64 and Apple II and even more exotic systems like the SAM Coupé).

The Scriptovision Super Micro Script video titler is almost a home computer

Canadians, rejoice! Not only do you have curling, the Big Turk and Tim Hortons (and, when I was in BC last, Dr Pepper made with real cane sugar), you also have a number of interesting indigenous computers like the underappreciated Micro Computer Machines MCM/70 portable, the Tarot Electronics MIMIC (not to be confused with the more notorious Spartan Mimic), the Dynalogic Hyperion and of course the NABU Personal Computer. And, like your neighbours to the south, you have terminals too, most notably the Telidon and Alextel.

Terminals, however, are in many cases based on general purpose architectures, just lashed to restrictive firmware — a good example would be the DEC VT220 which is controlled by our old friend the Intel 8051 — and game consoles likewise fall naturally in this category. Plus, there's a third group of computer-adjacent devices that qualify as well: the video titlers.

Video titlers (also known as character generators) are exactly what they sound like: devices that stamp bitmap data, usually text, on top of a video signal, like this typical example from a 1992 demo video for the consumer-oriented Videonics Video Titler. Distinct from what you might do as part of an editing system, many of these machines operate in real-time and over live video input such as the classic Chyron systems. Today's titlers are usually add-on boards controlled by a standard desktop computer, but for much of their existence they came as standalone devices with their own CPUs and video hardware, and that means they can be potentially hardware-hacked like anything else.

Well, Canada, you have your own indigenous video titlers as well, and here's one designed and manufactured in beautiful Montréal: the Scriptovision Super Micro Script, circa 1985.

The Super Micro Script was one of several such machines this company made over its lifetime, a stylish self-contained box capable of emitting a 32x16 small or 10x4 large character layer with 64x32 block graphics in eight colours. It could even directly overlay its output over a composite video signal using a built-in genlock, one of the earliest such consumer units to do so. Crack this unit open, however, and you'll find the show controlled by an off-the-shelf Motorola 6800-family microcontroller and a Motorola 6847 VDG video chip, making it a relative of contemporary 1980s home computers that sometimes used nearly exactly the same architecture.

More important than that, though, it has socketed EPROMs we can theoretically pull and substitute with our own — though we'll have to figure out why the ROMs look like nonsense, and there's also the small matter of this unit failing to generate a picture. Nevertheless, when we're done, another homegrown Canadian computer will rise and shine. We'll even add a bitbanged serial port and write a MAME emulation driver for it so we can develop software quickly ... after we fix it first.

The Texas Instruments CC-40 invades Gopherspace (plus TI-74 BASICALC)

I've mentioned on the blog several times the continuum that exists between handheld computers and pocket computers, battery powered devices in rather small form factors that are nevertheless fully-fledged general purpose computers — arguably more so than the modern locked-down smartphone has become. Some of these diminutive systems are best considered "handhelds," with larger size, larger keyboards, more power and (often) less battery life, and some are definitely "pocket computers," with smaller size, smaller keys, less power and (usually) better battery life. For example, systems like the Tandy PC-4/Casio PB-100 or Tandy PC-3/Sharp PC-1250 would be considered "definitely a pocket computer," while the Epson HX-20 or Kyotronic 85 systems like the NEC PC-8201A or TRS-80 Model 100 would be considered "definitely a handheld computer," and you can probably think up some examples in between.

Well, here's a notable example of one single architecture that birthed both types of machine, and it came from a company not really noted for either one: Texas Instruments.

TI certainly made calculators and many of those were programmable by some means, but neither handheld computers nor pocket computers had categorically been in their repertoire to date. Nevertheless, here we have the 1983 Compact Computer 40 — using the AA battery for scale, at that size definitely a handheld — and above it the 1985 TI-74 BASICALC, notionally a "BASIC programmable calculator," but actually an evolved version of nearly the same hardware in less than half the size. Thanks to the ingenuity of the Hexbus interface, which due to TI's shortsightedness was never effectively exploited during that era, we can get a serial port running on both of these with hobbyist hardware. If we have a serial port, that means we can bring up a terminal program — which we'll write from scratch in assembly language for shell and Gopherspace access.

But how would a Unix shell work on a single line screen, or for that matter, a Gopher menu? We'll explore some concepts, but before we do that, for context and understanding of their capabilities we'll start with the history of these machines — and because their development is unavoidably tangled with TI's other consumer products and their home computer family, we'll necessarily rehash some of those highlights and nadirs as well.

Oblast: a better Blasto game for the Commodore 64

Way back (well, six months ago, anyway), when I was wiring up a Gremlin Blasto arcade board, we talked at length about this 1978 arcade game's history and its sole official home computer port by Milton Bradley to the Texas Instruments 99/4A. In the single player mode you run around in a maze and try to blow up all the mines, which can set off sometimes impressive chain reactions, all the while making sure you yourself don't go up in flames in the process.

The TI-99/4A version was the Blasto I originally remember playing as I never did play Blasto in the arcades. (Also, for the record, we're not talking about Sony's unrelated Blasto for the PlayStation which, other than having the voice talents of the late and lamented Phil Hartman, was apparently a traumatic slog both for its developers and the few people who actually played it.) To the credit of its three composite authors, it is a competent and accurate conversion that also adds configurable options, colour graphics and music; in fact, TI's Blasto is probably my favourite game on the /4A, more so than any other cartridge. On the other hand, because it's an accurate conversion, it also inherits all of the original's weaknesses, which admittedly hail from the limited CPU and ROM capacity of the arcade hardware.

So, in that article, I mentioned two future Blasto projects. One is to save my pennies for a custom arcade cabinet to put the board in, though I just spent a cool grand plus on tires which used up a lot of those pennies and I've also got Christmas presents to buy. But the second was to write my own take on TI Blasto and soup it up. This project is the second one from my bucket list that I've completed. It took a couple years of work on it off and on, but it's finally done, with faster action and animation, a massive number of procedurally generated screens, and fully configurable gameplay.

I've christened it Oblast, and it's free to play on your real Commodore 64 or emulator. Let's talk about what's the same and what's different.

Reverse-engineering Roadsearch Plus, or, roadgeeking with an 8-bit CPU

Sorry, Doc Brown: we still needed roads in 1985. That meant paper atlases and misfolded roadmaps and a lot of stereotypical male anxiety asking for directions. Fortunately, in 1985, this problem also had a solution.

Yes, if your car inverter could handle a 45-ish watt load — and your wife doesn't want her seat back right away — you could navigate major routes across America on your home computer like this portable Commodore SX-64. I particularly enjoyed writing this article because my other irredeemably nerdy habit is roadgeeking, exploring and mapping highways both old and new, and it turns out that 8-bit roadgeeking on ordinary home computers was absolutely possible.

For computers of this class, devising an optimal highway route becomes an exercise not only in how to encode sufficient map data to a floppy disk, but also performing efficient graph traversal with limited hardware. Today we'll explore Roadsearch-Plus, one of the (if not the) earliest such software — primarily on the Commodore 64, but originating on the Apple II — and at the end "drive" all the way from southern California to British Columbia along US Highway 395, my first long haul expedition, but as it was in 1985. Buckle up while we crack the program's runtime library, extract its database, and (working code included) dive deeply into the quickest ways to go from A to B using a contemporary home computer.

Harpoom: of course the Apple Network Server can be hacked into running Doom

Of course you can run Doom on a $10,000+ Apple server running IBM AIX. Of course you can. Well, you can now.

Now, let's go ahead and get the grumbling out of the way. No, the ANS is not running Linux or NetBSD. No, this is not a backport of NCommander's AIX Doom, because that runs on AIX 4.3. The Apple Network Server could run no version of AIX later than 4.1.5 and there are substantial technical differences. (As it happens, the very fact it won't run on an ANS was what prompted me to embark on this port in the first place.) And no, this is not merely an exercise in flogging a geriatric compiler into building Doom Generic, though we'll necessarily do that as part of the conversion. There's no AIX sound driver for ANS audio, so this port is mute, but at the end we'll have a Doom executable that runs well on the ANS console under CDE and has no other system prerequisites. We'll even test it on one of IBM's PowerPC AIX laptops as well. Because we should.

prior-art-dept.: The hierarchical hypermedia world of Hyper-G

It's time for another entry in the Prior Art Department and today we'll consider a forgotten yet still extant sidebar of the early 1990s Internet. If you had Internet access at home back then, it was almost certainly dialup modem (like I did); only the filthy rich had T1 lines or ISDN. Moreover, from a user perspective, the hosts you connected to were their own universe. Things may have originated elsewhere, but everything on the host you connected to was a local copy: the mail you received, the files you could access, the posts you could read. Exceptional circumstances like NFS notwithstanding, what you could see and access was local — it didn't point somewhere else.

Around this time, however, was when sites started referencing other sites, much like the expulsion from Eden. In 1990 both HYTELNET and Archie appeared, which were early search engines for Telnet and FTP resources. Since they relied on accurate information about sites they didn't control, both of them had to regularly update their databases. Gopher, when it emerged in 1991, consciously tried to be a friendlier FTP by presenting files and resources hung from a hierarchy of menus, which could even point to menus on other hosts. That meant you didn't have to locally mirror a service to point people at it, but if the referenced menu was relocated or removed, the link to it was broken and the reference's one-way nature meant there was no automated way to trace back and fix it. And then there was that new World Wide Web thing introduced to the public in 1993: a powerful soup of media and hypertext with links that could point to nearly anything, but they were unidirectional as well, and the sheer number even in modest documents could quickly overwhelm users in a rapidly expanding environment. Not for nothing was the term "linkrot" first attested around 1996, as well as how disoriented a user might get following even perfectly valid links down a seemingly infinite rabbithole.

Of course, other technically-minded folks had long been aware of the problem, and as early as 1989 an academic team in Austria was already trying to attack the problem of "access to all kinds of information one can think of." In this world, documents and media resources could be associated together into a defined hierarchy, the relationships between them were discoverable and bidirectional, and systems were searchable by design. Links could be in anything, not just text. Clients could log into servers or be anonymous, logged-in users could post content, and in the background servers could talk to other servers to let them know what changes had occurred so they could synchronize references. Along the way, as new information resources via WAIS, Gopher and the Web started to appear, their content could also be brought into these servers to form a unified whole. This system was Hyper-G, and we'll demonstrate it — on period-correct classic RISC hardware, as we do — and provide the software so you can too.

Let's give PRO/VENIX a barely adequate, pre-C89 TCP/IP stack (featuring Slirp-CK)

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.

MacLynx beta 6: back to the Power Mac

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!

The "35-cent" Commodore 64 softmodem

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!

Pretty pictures, bootable floppy disks, and the first Canon Cat demo?

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.

With PowerPC, Windows CE and the WiiN-PAD slate, everyone's a WiiN-er (except Data General)

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.

Virtualizing the 6502 on a 6502 with 6o6 (and The Incredible KIMplement goes 1.0)

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!

Refurb weekend: Data General/One (and the worst LCD in the world)

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.

After 41 years, my first assembly program on my first computer, the Tomy Tutor

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.

xa (xa65) 2.4.1

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.

CAP-X and COMP-X: how the Tandy Pocket Computers got a sucky Japanese assembler

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.

Reversing the Web-@nywhere Watch: browse fragments of the Web on your wrist

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 - finally

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.