Advent of Computing - Episode 123 - The Jupiter Ace

Episode Date: January 1, 2024

Released in 1982, the Jupiter Ace is a fascinating little computer. It's hardware isn't much to write home about. It's just an 8-bit microcomputer very much in line with other systems of the era. Where it shines is it's software. In a period when most home computer ran some version of BASIC the Ace was using Forth. On the surface that might sound like a trivial difference, but that one deviation from the norm made all the difference in the world.   Selected Sources:   https://www.theregister.com/2012/09/21/jupiter_cantab_jupiter_ace_is_30_years_old - The Register article on the Ace   https://jupiter-ace.co.uk/documents_index.html - Every other Ace resource you could ever want

The history of home computing is surprisingly turbulent. It's the kind of thing that you can't break into eras, at least not in any neat sort of way. The earliest batch of machines, we're talking 1974-1973, were pretty diverse. We get everything from the Altair 8800, itself something of an expansion card chameleon, to the dual-tape deck MC-70 with its single-line display and weird early 8-bit processor. Some histories will cut off this early period with the release of three computers in 1977, the Apple II, the Commodore PET, and the TRS-80. These all ran some form of BASIC, so it's tempting to say that this was the start of

a new era, of a new BASIC era. But things just aren't that clean. Even among these computers, we had different processors and very different implementations of BASIC. Things break down even more if we look further afield. This wasn't the age of BASIC alone. There were machines out there, some derived from the Altair 8800, that ran CPM, a totally different type of disk operating system. Some even used 8-inch floppy drives. There were wild new boards coming out from companies like RCA.

This just wasn't a uniformly BASIC time period. The next big milestone is, of course, the release of the IBM PC in 1981. This, I think, is the most clear example of a non-era. During the early 80s, we have PC-like things over in one corner doing their thing, and they'd spread, but that wasn't the whole field. corner doing their thing, and they'd spread, but that wasn't the whole field. In 1982, the Commodore 64, one of the best-selling home computer models of all time, was released. It was a basic machine, not anything like a PC. That's not to mention weird CPM computers that still stuck around, and the eventual Macintosh in 1984. The point is, there's never a time where there's a uniform home computer market. That doesn't really happen until years on. That said, we can pull out some big categories

here. In general, we have machines that run BASIC, machines that run CPM, and machines that run MS-DOS. And in a lot of cases, there is bleed over between those machines, but we can look at these as three big categories, three big players during the home computer revolution. Computers that fall in any one of those categories are usually pretty boring. If you've read about one basic machine, you know what another basic machine is going to do. Same for a machine that runs MS-DOS. They're all going to have some kind of Intel chips inside. To find really interesting machines, we need to look for systems that broke that mold,

that broke away from those three main categories. That, I think, is where all the fun really lies. Welcome back to Adren of Computing. I'm your host, Sean Haas, and this is episode 123, The Jupiter Ace. Today, we're jumping back into the microcomputer era to look at a very unique machine. But first, I gotta throw down some context. Think back about 34 episodes, or I guess, go have a listen if you want. In episode 89, I covered this programming language called Forth.

This is a completely unique language that entered the scene in around 1970. Forth is stack-based, something that I'm sure I'll explain more deeply in the episode today. The short story is that to program in Forth, you put items onto a stack of data. Then those items are popped off the top of that stack and operated on. In other words, Forth treats memory as a stack, as a pile of little chunks of data. This is in stark contrast to, well, all other languages that treat memory as addressable data, or in the case of Lisp-like things, a list. Forth is also an amazingly simple language. It's one of those languages that's been reduced down to the pure essence of programming.

I don't think you could simplify Forth anymore, even if you tried. This comes with a pile of benefits. Implementations of Forth are very compact. By that, I mean a Forth compiler takes up very little memory. I mean a Forth compiler takes up very little memory. That compiler will produce code that also takes up very little memory and is very processor efficient. Despite this simplicity, Forth packs in some wild features. Most impressive among those is multitasking. The language natively supports parallel operations. That's a feature set that's usually managed by an operating system or an extension library. When a language says it supports multitasking, that most often means that it can coordinate

with an operating system in order to run multiple processes. But Forth itself can multitask. That's very out of the ordinary, especially for such a simple-looking language. The bottom line is that Forth is a very unique and very powerful programming language. I think it's up there with Lisp in terms of beauty, simplicity, and raw computer science cool factor. Any hacker would love to know Forth. Now, by that logic, the Jupiter Ace should be the coolest computer ever produced. The Ace was released in 1982, and it ran Forth. That,

on its own, should raise a few eyebrows. But it gets weirder. This computer was made in the mold of a very small and cheap microcomputer. It cost only 89 pounds on release, which would translate and inflate to about $500 today. So we're dealing with a very cheap little computer. To top this off, I know next to nothing about the Ace. I'm jumping in blind here. Is this little computer as cool as it nothing about the Ace. I'm jumping in blind here. Is this little computer as cool as it sounds on the surface? Why would a company in the early 80s even think of producing a fourth machine? And just for my personal curiosity, how well does the Ace actually implement fourth? The story of the Jupiter Ace starts with a company called Sinclair Research Limited,

founded and operated by one Clive Sinclair. In the early 80s, Sinclair produced a series of amazingly cheap computers. This started with the ZX80 in 1980 and was followed up by the ZX81 in… guess the year… 1981, that was then followed on by the Spectrum in 82. So just how cheap were these computers? Let's take the ZX81 as the example here, since it falls into the middle of the pack. It retailed for just shy of 70 pounds. Now, if you're like me and live in dollar world, then you may not have a good feel for the value of a pound. So let me do some math and pull up some comparisons.

If you run an inflation calculation then convert to dollars, the ZX81 would come out to 360 US dollars. That's still cheap for a computer today. This becomes an even better value when compared to contemporary machines. The Commodore VIC-20, a somewhat comparable computer that was released in the same year, sold for $300, that's in 1981 dollars. It inflates up to $1,000 in 2023 money. While we're here, I should make a quick nod to the elephant in the 1981 room. A low-trim IBM PC sold for about $1,600, which is over $5,000 when adjusted for inflation. All these numbers just go to show that the ZX81 wasn't just a cheap computer. It's what I'd call a wildly cheap machine. So how was Sinclair able to produce such a budget computer? Well,

if you've ever seen a ZX81 or any Sinclair computer, then I'm sure you know how. These computers were very small machines, in pretty much every sense of the word. Now, these are all wedge form factor computers. We're talking a single unit that contains a keyboard in front and outputs for the TV on the back. The ZX81 weighed less than a pound, and it could comfortably fit on your hand. Its integrated keyboard was a simple membrane. And I don't mean something like sliders over a membrane. I mean membrane, like the little blister buttons on a cheap microwave front panel. brain, like the little blister buttons on a cheap microwave front panel. Inside is, well, mixed. The ZX81 ran off a Zilog Z80 processor. That was a pretty standard-ish chip in the era, although this is a bit of a weird era to land in. The Z80 is an 8-bit processor,

and it's about 5 years old when this Sinclair computer hits the shelves. Many other home computers were still using 8-bit processors, but 16-bit chips were right around the corner. The IBM PC, 1981's breakout success, ran off of a 16-bit chip. There's also a little matter of clock rate, something that I don't really like to get into very often. So all computers march to the beat of some little clock. In the case of microcomputers, those clocks are quartz crystals that oscillate at a set regular frequency. Many microprocessors can actually run at different clock rates.

The Zilog chip can pull such a trick. I usually refrain from discussing clock rates because it's confusing and, ultimately, kind of a moot point. Comparing clock rates between different processors doesn't tell you anything. Some chips are more efficient at some operations, so may actually perform better than another processor that's technically running at a faster clock rate. are more efficient at some operations, so may actually perform better than another processor that's technically running at a faster clock rate. That said, clock rate does matter if we're talking about the same processor. As I said, the Z80 can run at multiple clock rates. The ZX81

runs its chip at 3.25 MHz. Where does that fall in comparison to contemporary systems? Well, it actually falls short. The Osborne 1 is a computer that was also released in 1981 and also uses a Z80. That chip was clocked at 4.0 MHz. So, in a 1-to-1 face-off, the ZX81 would underperform compared to the Osborne 1. So why would Sinclair put out a hamstrung machine? Well, that all came down to cost. But here's where you might get a little confused. There wasn't some engineer at Sinclair wringing their hands over selling you too many CPU cycles. Lowering the clock rate doesn't instantly save you on manufacturing costs. I think a quartz crystal running at any speed in the megahertz range costs about the same. Instead, this was done as a

balancing act between the processor and its support chips. The ZX81 was designed to output to a TV, specifically one that understood the PAL standard. Now, I'm not a big analog TV nerd, so please forgive me if I trip over myself here. From what I understand, the 3.25 MHz clock rate meant that the ZX81 could interface directly with a PAL TV without the need for any type of fancy TV driver chip. That saved manufacturing costs, but it meant that the ZX81 ran slower than contemporary similar computers. The overall point here is that we're looking at a machine, really, a series of machines, built to a very low cost. This results in some underperformers, some very, very little machines indeed. But those little computers are able to

capitalize on the new home market. Sinclair computers would do very well, mainly in the UK, but some of their computers would even splash over to America. Our two main characters for today's episode came out of this era of Sinclair. The first of these characters is one Richard Altbasser. He started his career at Sinclair in 1980, during the development phase of the ZX81. Altbasser was an engineer contributing to the ZX81's motherboard and eventually moving up to become one of the main designers for the ZX Spectrum. The second player was Steve Vickers, a programmer who worked for Sinclair in a roundabout kind of way. Vickers worked for a contractor that wrote ROM code for the ZX80. Eventually, that transitioned to kind of just a standing contract to work with Sinclair proper, where he wrote software for the ZX81 and Spectrum.

Crucially, Vickers wrote the implementation of BASIC that ran on all those machines. BASIC was the beating heart of many home computers in this era. Most microcomputers booted directly into a BASIC interpreter as its user interface. A user was expected to work with the computer by writing out little BASIC programs. Now, these weren't super standardized versions of BASIC. Rather, we're looking at something that would be called by BASIC's creators, Street BASIC. Each computer had its own wonky off-spec features and quirks. This ranged from support for color graphics and sound to commands for controlling the hardware. The Sinclair machines,

for instance, had special basic functions for reading data from cassette tape interfaces. In 1982, Altwasser and Vickers decided they were done with Sinclair research. Here, I'm using a contemporary article from the magazine Sinclair User and a somewhat more recent piece from The Register. It seems that one of the major motivations for leaving Sinclair was money. To quote Vickers via The Register, The thought was, Clive Sinclair was making all this money out of us. Why shouldn't we just make our own computer and make the money for ourselves? End quote.

I can't think of a more pure motivation under capitalism. Altwasser and Vickers were, in large part, the creators of the ZX Spectrum. They only made salary, while the bigwigs, or rather, the bigwig, brought home a lot more money. Why not cut out the middleman and get a bigger slice of the profits? It appears that this line of thinking took root just as the spectrum was out the door. From Altwasser, once again via the register, quote, There was a time after the product design was finished, when the spectrum went into manufacturing, where our work was less intensive than it had been. This is a very relatable beginning for a new company, and it owes itself to a quirk of these

types of project-based jobs. Timelines never line up very tightly. You always wind up with these ebb times between big pushes. It seems that one of those ebbs gave Altwasser and Vickers a little time to think, and they figured it was time for them to build their own computer. And why not? Between the two of them, they had all the hardware and software knowledge required for the job. In 1982, the two would leave and form Rainbow Computing Company, but that name wouldn't stick around for long. Within the year, the new venture was renamed Jupiter Cantab. Coverage in Sinclair User puts forward this air of mystery.

The duo was reluctant to share exactly what they were working on, or exactly what the new company would produce. I'd imagine part of that hesitation came from possible legal fears. It may have been that Altwasser was designing a new computer while he was on Sinclair Company time. That could lead to some issues. Or it's also likely they just didn't have concrete plans yet. Or, it's also likely they just didn't have concrete plans yet. Either way, Jupiter Cantab didn't hold their cards close to their chest for all that long. The mystery ran its course. Once again, before the end of 1982, the Jupiter Ace was announced. And this is where things get interesting.

The Ace is, by and large, similar to the ZX Spectrum and ZX81. I mean, that makes good sense, right? That's what Altwasser and Vickers knew best, and to be honest, it was probably all they knew. Both had gotten involved with Sinclair pretty soon after college. They were still in their mid-twenties. I don't think they had much experience outside making Sinclair computers, which is kind of wild and funny to think about. Spec-wise, the Ace ran off a Z80 processor clocked at 3.25 MHz. It had 1KB of RAM and a weird rubber keyboard. This actually makes for a mix between the ZX81 and the Spectrum. The Ace had the same processor as both

machines at the same clock rate, the small 1K RAM of the ZX80, and the rubber keys of a Spectrum. Put another way, there was no differentiating factor in the hardware. This could have just been a recreation of Sinclair hardware. I'd hesitate to call it a knockoff since it was designed by the actual designers of a lot of Sinclair's computers, but it's very close. That said, there was one huge differentiating factor. The Jupiter Ace didn't use BASIC at all. Rather, it used FORTH as its language of choice, as its interface. Vickers proudly claimed that that difference alone made the ACE run 10 times faster than the competition. But was that claim actually true? And why would you want to bet on FORTH

over BASIC? To understand why Forth would be an attractive option, we must first understand a few things about the contemporary landscape. Most home machines, with really few and very notable exceptions, ran some type of BASIC, even if it was just as a token option. The IBM PC, as a fun example here, shipped with BASIC burnt into its silicon. It was totally ubiquitous, even if most PC users were expected to not really use BASIC at the end of the day. The rationale for this ubiquity is, I think, pretty easy to understand. BASIC was designed in the early 60s at Dartmouth as a language for

non-programmers. It was meant as a way to let beginning users use a computer. So it makes good sense as a language interface for home computers. Most home users would be neophytes, so BASIC would offer a hopefully accessible language and an accessible interface. BASIC would offer a hopefully accessible language and an accessible interface. But there's an issue with BASIC, or rather, with how BASIC was approached on home computers. In the original context, BASIC was a compiled language, meant to run on big, time-shared mainframes. Its creators, John Kemeny and Thomas Kurtz, kept an eye out for performance. Since BASIC was going to be used on a shared system, its performance actually mattered a whole lot. If one program was hogging computer resources, that would hurt every other user.

Their solution was to design a really slick compiler. When a user ran a program or a single line of BASIC, that code was first compiled and then executed. That ended up performing better, especially for programs that were rerun multiple times. The trick here, the real slickness, is the interface. In all BASICs, at least in this era, there were two modes of operation. A user could type out a single line and hit enter. That line would then be executed alone. Or a user could write out code prefixed with line numbers. That let you enter in a big program which you could list, edit, and then execute in full at your leisure. In Dartmouth BASIC, all code was compiled before execution.

Microcomputers tended to go another route. Those versions of BASIC were interpreters. Instead of producing machine code, an interpreter just kind of does what you tell it. There's no actual conversion. The program is just parsed and executed. Just for instance, let's take something like the expression 1 plus 1. A compiler would turn that into machine code, probably just something that loads 1 into a register, adds 1 to that register, and then stores that result somewhere in memory. The compiler spits out that machine code, it doesn't

execute it for you. Then you have this completed program that you can use and reuse whenever you want to. An interpreter doesn't ever produce an executable. It would see 1 plus 1 and parse that down to make sense of it. The interpreter figures out it's an addition, finds the two operations, then immediately carries out the addition. The result is that the interpreter spits out two. In general, this tends to be slower than a compiler. That's especially the case when you're rerunning code. The compiled program is done and reusable. It will always be pretty darn fast. But if you're using an interpreter, you need to reinterpret your code every single time you run it. So why would anyone ever want

to write an interpreter? They're just kind of worse, right? Well, the name of the game here is compromise. Interpreters are often easier to implement. It's just faster to write one, Interpreters are often easier to implement. It's just faster to write one and it takes less effort. Performance doesn't matter as much because home users aren't exactly professional programmers. Plus, compilers usually require some type of disk space. Most often, you write up a program as a text file and the compiler gives you an executable file. Home micros didn't always have disks. They didn't necessarily have any type

of storage. But this point is more a side thing. You can't do a compiler without files, technically. There's also a weird quirk of BASIC that we need to consider here. Interpreters are often more interactive. They're just walking through your code, so interpreters can often be stopped and fussed with. You can send in a single line or a full program for interpretation. BASIC, compiled Dartmouth BASIC, was weird. It did the whole interactive thing. It could do one line at a time or a full program. So to the outside world, it looked like Dartmouth BASIC could have actually just been an interpreter. In fact, as BASIC spread, many new implementations dropped all the compiled aspects of the language.

In their book, Back to BASIC, Kimony and Kurtz called these divergent versions Street BASIC. And when it comes to home computers, they all ran Street BASIC. This led to slow systems with all kinds of overhead. This led to hardware that just wasn't properly leveraged. BASIC was also attractive because of its line-by-line nature. The syntax isn't complicated. There's no grouping of lines of code into chunks or segments. It's perfectly valid to just execute a single line one at a time, and that line will function the same either alone or in a larger program, sans some contextual things.

That makes an interpreter even more simple to implement. All the stars really align to make basic look like a great option on smaller computers, despite the compromises made in these street BASICs. But there were other options out there. This is, I think, one of the interesting little avenues in this period. Microcomputer BASIC was serving a pretty broad purpose. It was meant to provide users with an interface and manage the computer's hardware. It was a simple form of an operating system that just happened to be mixed up with a language. Another option was to go with a fully-fledged operating system.

In this specific context, we're talking about a disk operating system. Nomenclature here gives us a certain insight into the two sides of this divide. Disk operating systems were shipped from microcomputers that had floppy disk drives. These were usually upgrades, so you run into these machines that ran both basic and some type of disk operating system. The most famous of these machines is the IBM PC yet again. A base model came without disk drives and booted into Microsoft Basic. A model with disk drives could be booted into Microsoft DOS. These disk operating systems weren't built around a language. Instead, they were built around a very simplified file management system. The point is, when approaching a new microcomputer, one of the most crucial options was its software.

In theory, there was a lot of flexibility here, but the market had been dominated on one side with BASIC and on the other side with disk operating systems. By simply looking at the Jupiter Ace, it's plain to see which side of the divide it falls on. It's a simple machine, a cheap computer without any disk drives, so it should run basic, right? The decision to use Forth as an interface language is a huge divergence from the norm. There were two big reasons for this divergence. On the one hand was performance, and on the other was a possible new market. These reasons actually blend together pretty nicely. Forth is a compiled language, and it's a very simple language. Developing a Forth compiler,

for a few technical reasons, is very simple. That means that, in theory, it's fast to develop. It's also a very efficient language, so it could better leverage meager home computer hardware. The second reason for ditching BASIC was to court a new market. Altbosser and Vickers wanted to make a home computer for more advanced users, for non-beginners. As is explained in the pamphlet The Fourth Bridge, published by Jupiter Cantab themselves, The question of which language to choose for personal computer applications may seem to be a more complex one, but in fact it is not. There is one language which stands out as being a model of simplicity, clarity, and the means through which to acquire the technique of elegant programming.

It is also very fast, memory efficient, and immensely suitable for microcomputers. That language is fourth. End quote. This gives us a really interesting value proposition. It also drops us into the weirdness that is specification vs. implementation. So, let's get weird for a few minutes and ask ourselves, what actually is a programming language? This is a bizarre question to consider, and it's something that's tied up with Street Basic and Forth and Dartmouth and home computers. A language usually comes in two forms that are wrapped together.

One part is the specification, this divine document that's supposed to fully describe the language. This is the cornerstone of the language in its most pure form. Sometimes it's a very formal document, sometimes not. It can even be a dream in the heads of the language's creators. Whatever the case, a spec can only go so far. You can't execute a specification on a computer. So the second piece is the implementation. This is the spec translated into code. It can be a compiler, an interpreter, something in between, something different. You actually just need some sort of implementation that can understand and run the language. In theory, that implementation will follow the spec as closely as possible.

That allows multiple implementations to speak the same language, and it also helps with the division of labor. Not all programmers have a knack for designing a new language, and not all language designers are actually good programmers or compiler builders. All sorts of issues can arise from this divide. There's the confusion over what constitutes a language, for example. Some languages are very explicit in their specification, so much so that their spec will contain how to implement the language. In that case, it can be very hard to separate the written specification from the written code of the compiler or the interpreter.

This includes languages like Lisp and, the topic today, Forth. written specification from the written code of the compiler or the interpreter. This includes languages like Lisp and, the topic today, Forth. Those both specify how data needs to be represented and processed by the language on a very low level. There's not much ambiguity. So their documentation tells you, in a way, how to implement the language. For some languages, however, implementations can get pretty loose. That's exactly what happened with BASIC during the home computing boom. Kimony and Kurtz

even call this phenomenon a CORRUPTION of the language. In other words, we could look at all these street BASICs as pale imitations of the actual language. And this does get back to the whole what is a language confusion. There's Dartmouth Basic, but there's also Apple Basic, which doesn't have a spec, or Microsoft Basic, which doesn't necessarily have a spec either. But earlier versions of Basic do have a spec and an implementation. So it just gets confusing. There's all this warping, distortion, and, to use Kurtz and Kimney's term, corruption that goes on. But let's forget all that for now. What about Jupiter's fourth? What about their implementation? It was actually a lot closer to the true spec. Altwasser and Vickers were actually able to cram a compiler into their tiny machine,

a feat that would make the computer much faster than the competition. How was such a feat accomplished? Well, it's essentially a form of magic. I'm serious here. There are some very spooky shenanigans going on inside the Jupiter Ace. In general, the Ace compiled everything. There were some exceptions, but those are less interesting. That's not where the magic is. When you wrote a program, it was compiled

into machine code. When you saved a program to a cassette tape, you were actually saving compiled machine code. That's in stark contrast to basic machines that saved raw text to tapes. This had a huge impact on performance. There's the obvious speed-up from running machine code. This approach also made tapes more efficient. Machine code is more compact than the text of a program, so less data had to be read and written. Tape drives, really, just cassette recorders, were notoriously slow, so this was a bit of a big deal. Those gains were possible thanks to how Forth was designed.

Most implementations of Forth used this technique called threaded code. I discussed this at some length in my episode on Forth, so I'm going to be a little brief here. In Forth, everything is a word. That's just a chunk of text that represents some operation to carry out on the stack. There is a basic set of words that everything can be constructed from. Those words are defined as machine code somewhere very deep in the compiler. During compilation, each word is replaced with a callout to some chunk of that machine code. More complex words are built up of many calls to less complex words, so you have this kind of cascading effect. But in general, each operation says call x, call y, call z. The result is that every word, everything you can do in the language, is compiled to a function

call. Put another way, there's a one-to-one mapping between fourth, the written text of the language, and the machine code that the compiler produces. This is the heart of the spookiness. The ACE stores everything as machine code, so how can it list out a program's text? How can you ever edit the source code? The trick is decompilation. This is a process where the compilation process is reversed. Machine code is turned back into source code. For most languages, that doesn't really work. But for Forth, the process is actually trivial. The ACE relies on the fact that each word in Forth has a one-to-one equivalent in machine code. If you write ADD in your text, that could get compiled to just CALL ADDRESS 1357.

So you can just go from CALL ADDRESS 1357 back to the text to the word add. It's honestly a little bit mind-blowing how this all shakes out. I don't think I can really easily explain how strange this is and how, frankly, a little bit uncomfortable it makes me feel. I've decompiled code before, and let me tell you, it sucks. It usually doesn't work quite right, or it just doesn't work at all. You lose variable names and you lose comments, so the code is barely human-readable. It's a quick way to have a bad time. But thanks to how Forth was designed and some savvy code, the Jupiter Ace was able to constantly decompile code. It was just part of how it worked.

It's honestly a little baffling to me. This all makes it seem like Forth was a very natural choice for microcomputing, at least as JupyterCantab implemented it. But we must ask, did the ACE actually hit its performance goals? Was it 10 times faster than BASIC like every Jupiter ad says? Well, maybe. I haven't actually been able to find contemporary benchmarks between the Ace and the Spectrum. What we do have are contemporary reports of folk going, golly gosh, that sure is fast. One review in Electronics and Computing Magazine ran with this line, quote, the speed has to be seen to be believed. I've used Forth before, yet even I was surprised. A diagonal line plotted pixel by pixel using a loop in graphics mode

does not grow towards the corner. It appears in its entirety. Now, this isn't the best benchmark, I will be clear here. There are a lot of hanging details about graphics and whatnot, but it's a very effective demo. There are a number of similar anecdotes and reviews. It seems that the Ace was, in fact, a very fast computer. And that makes good sense. Altwasser and Vickers went with pretty normal hardware, but made a major change to the software stack. That change, the adoption of Forth, was meant to speed up the machine.

The radical shift from the status quo was working. We're about to get out of the software trenches, but I do have one other thing that I want us to consider, and that's multitasking. Most implementations of Forth support some type of multitasking. Jupyter's Forth, however, does not. At least, not really. So here's the deal. Forth uses a method called cooperative multitasking. In this system, a process starts up, does some of its work, then eventually lets the process manager know it's ready to take a break. This is usually called a yield, or in Forth terms, a pause. You quite literally write pause in your program in all caps to tell Forth it's okay to switch to another task for a minute.

Jupyter's implementation of Forth doesn't support any kind of pause feature. There's a red herring in the manual for the ACE, but it's actually just an example of how to implement a word that pauses the machine and waits a number of seconds. That's nothing to do with multitasking. But, and here's the weird caveat that kind of threw me off guard, multitasking could be implemented on the Ace. On its own, that's not super surprising. You can totally write a multitasking system for an 8-bit microcomputer. What's neat is that it's hiding in a utility disk. There's this pile of printer utilities that were sold for the Jupiter Ace. One of those programs, called PrintScan, has a multitasking mode. In this mode,

you can keep working in 4th while PrintScan sends data to a printer in the background. Now I don't know how PrintScan is doing multitasking and this is really the million-dollar question or I guess the stakes are pretty low maybe a five dollar question. I tracked down the program and tried coaxing an ACE emulator into decompiling it for me but no dice. It may just be a machine code program that hamfists some multitasking, in which case that's not very exciting, or it may be some not-so-documented feature of the ACE. Either way, the ACE was physically able to multitask, but it didn't really provide a Forthian way to do it. Despite this horrifying

and shocking omission, the Ace is still a very capable machine. At the price point, I think this may have been the best use of a Z80 processor possible. So then it stormed the market, right? Well, not really. We still need to talk about the ugly side of this bizarre duckling. The first thing we need to discuss is the whole premise behind the Jupiter Ace. The new computer was targeted at a very specific niche. To quote Altwasser, again from the Register, We felt there was an opportunity, a gap in the market for a more programmer-oriented kind of machine,

a more technical niche product. The Ace was meant as a cheap little machine for programmers, for experienced computer users. This is the foundation of the machine, and it introduces a bit of an issue. Or at least, I think it makes the Ace an awkward machine. Despite the power of Forth, despite the fact that this was a much more programmer language, the Ace was still a very weak machine. Now, in the grand scheme of things, is it even possible to sell programmers on tiny computers? That's a big question, but I think it's at the root of this story. If the ACE is meant to be a programmer-oriented machine, then it has to be a machine that a programmer could love.

Something a programmer would actually want to use to produce software. I think that, in many cases, actually want to use to produce software. I think that, in many cases, that runs counter to the cost cutting efforts that shape the ACE. Here, I'm pulling from my experience as both a hobby and a professional programmer. I've worked on modern computers and even on old machines. I actually cut my teeth on, I'm sure you've heard the story too many times, an old IBM AT. So while I don't have a whole lot of contemporary perspective, I think I can spot the issues here pretty well. The most glaring problem, at least the most petty one, comes down to the ACES interface. And I don't mean that in any technical sense. I mean the physical interface, the tiny rubber keyboard. This was a well-known problem at the time. Sinclair machines

had been rocking all measure of awful inhuman keyboards since the ZX80. The Aces board was very close in construction to the ZX Spectrums. It's a rubber button directly over PCB kind of thing. Think of something like a TV remote. This was a cheap way to construct a keyboard, but it resulted in something awful. For one, these keyboards are just plain small. The Ace is around 7 inches across. For some perspective, just the alphanumeric part of my laptop's keyboard is 11 inches wide, and that, for me, is already pretty cramped. I can't imagine trying to type on such a small keyboard. These rubber boards also just kind of suck to use in general. Keys like to bind if you press them wrong, or they can get fouled

up in the Ace's plastic case and never come up again. It's just not a pleasant experience, especially if you're trying to hammer out some code. There were actually third-party replacement keyboards that you could get to solve this issue. These boards had actual switches, were physically larger, and connected up to the Ace using a cable. And while that is nice, that still means that Jupiter Cantab was shipping a subpar product. While this may be a nitpick, I do think it's very relevant if the Ace was meant as a programmer's machine. Forth is a really good language, but the whole keyboard thing detracts from that. This reminds me of something a scrum coach once told me, and you'll have to excuse me here, I'm gonna hit peak industry ghoul for a minute.

So, I was working with this coach at one point that was obsessed with this idea of the flow state. It's this semi-mythical idea that when a programmer works on a task, they can reach this level of hyper-focus. They enter into a different mental state that allows them to be more productive and gives them deeper insight and connection with their code. The way the coach described it to me always seemed kind of fake. Kind of up there with the Balmer peak. But anyway, there is a core idea here that I like and that I think is very valid. A programmer requires a level of focus to work effectively. I know I've experienced something similar myself.

I can recall working on a program so intensely that I missed meals. That coach would sometimes say that his job was to find a way to keep us programmers in that flow state for longer. Through arcane practices and ceremonies, he tried to weed out and remove distractions, to smooth overriddenness trivia, and keep us all in that flow. To him, something as mundane as an email or a useless meeting or even an errant phone call could bring us programmers out of this hard-earned state, dropping us back down to earth. Now, like I said, I'm a bit skeptical of all of that stuff,

but I think there is a core to the idea. Programming is, in large part, about focus. All the tools and hardware created for programmers are aimed at making the computer blend in with the code. A good compiler, a good keyboard, and a good editor are all supposed to just disappear into the background. These all allow a programmer to focus on their code, not on their tools. How can you enter the flow state if you have to think about your keyboard binding up? How can you focus if your hands are cr have to think about your keyboard binding up? How can you focus if your hands are cramping since your board's too small? I also have to question the validity of this niche at all. Now, I'm kind of of two minds about this. I'm not sure the programmers would necessarily

be looking for super cheap computers. I get that the price point made the Ace more accessible. I've definitely scrounged for the cheapest hardware I can lay my hands on. I've even pulled computers out of e-waste bins when I didn't have a system that I liked. But that doesn't really make the Ace good hardware for a programmer. Contemporary reviews make this a lot more muddy, actually. Many reviews that I've seen put the Ace in a slightly different niche than was intended. It's seen as more of an educational computer, a machine for fledgling programmers, or a cheap way for existing programmers to get up to speed and try out Forth. I think it makes more sense in this capacity.

The selling point is, after all, Forth. It's not necessarily a super serious machine. I don't think any offices would be handing out Aces, but it could be a great bridge to get programmers into more serious software. Really, Forth is kind of the only selling point here. It's what differentiates the Ace from its Sinclair competition. This becomes all the more clear when we look at, well, the other features of Jupiter's little machine. The Ace can only output black and white graphics. That on its own, in this time period, is a bit of an issue.

Color graphics in the home market were a big deal at the time. The ZX Spectrum, Sinclair's newest machine that Altbosser and Vickers worked on, was the first of the Sinclair machines to offer color graphics. Let's not kid ourselves here. A large part of the home market came down to games. So color graphics mattered a whole lot. With Sinclair's switch to color, almost all of the home computing field was, well, in living color. Apple, Commodore, Tandy RadioShack, even Atari all had contemporary offerings with color outputs. And just as a quick check, the PC had an expansion card for color graphics. This put the Ace well behind the competition.

And while color isn't hugely important as a technical feature, it's a feature that's hugely visible. By not supporting color, the Ace could be made cheaper and it could be developed more quickly, but that really hamstrung the computer in the market. Once you get past the graphics, there is another issue, and that's RAM. The Ace came stock with 1 kilobyte of RAM. That may have been acceptable in the mid-70s, but this is 1982. In comparison to the rest of the market, 1K was a bit of a joke. The Spectrum, for instance, shipped with 16 kilobytes. It's true that 4th was very memory efficient, but that can only go so far, and speaking as a programmer, one of the big

things we usually need is a lot of RAM. When you're programming in a serious capacity, you need to have tools running. You need to be able to load up your program and a debugger, or load up your program and a compiler, or some other type of tool to help you work with your code. That means that you need more language than the usual user. Now, JupyterCADtab's solution to the memory issue was to offer an expansion card. This was a standard practice on Sinclair hardware. The ZX80 and 81 both supported such add-ons. There's basically just an expansion socket on the back of all

these computers that you could slam more RAM into. On one hand, this allows the base computer to be a lot cheaper, and if users want more RAM, they can buy into that. It gives an expansion pathway. But on the other hand, this can cause something of an ecosystem problem. By that, I mean it can trip up third-party developers. Most third parties, people who develop and sell purely software for computers, end up developing programs for the stock model of a machine, as in how it rolls off the factory floor. The reason for this is pretty simple. Most computers in the wild will be stock unless something really weird is going on. That means that to reach the largest audience, a software vendor is going to target the lowest common hardware denominator. But somehow, it seems that the ecosystem around

the ACE got really weird. The Jupyter ACE archive at jupyter-ace.co.uk is a great resource here. That site has a huge listing of ACE software. Something to note is that their tables show the memory requirements of each program. Most are more than 1K. In other words, to actually use an ACE, to actually run third-party software, you had to buy a RAM expansion pack. You had to splurge. So, okay, whatever. That just means that the Ace costs a little more, but it's still a very cheap setup. But here's the thing. Here's a further complication. Jupyter Cantab didn't offer their RAM pack on release day. When the RAM pack was finally released, there were production delays. This was such a problem

that third-party hardware vendors were able to swoop in with their own RAM packs. And while a vibrant third-party scene is crucial to a healthy platform, it does undercut the manufacturer's profits, which, when you're such a small company, that can be a big problem. The point is that shipping the Ace with so little RAM had cascading effects. Imagine you save up and you get your Ace in even early 1983. Well, you better be prepared for some disappointment. By that time, most programs and most games required at least 3 kilobytes of RAM, so you would have to get a RAM pack. According to Contemporary Reporting, that could take weeks. This was such a well-known problem that there are actually multiple newspaper

columns bemoaning that shipping delays on Jupyter Cantab RAM packs were sometimes more than two weeks. So you'd either have to wait or just know that you had to go out and find a third-party RAM pack. Third-party software was also, at least reportedly, a bit of a problem. According to the Jupyter ACE archives, there were 21 publishers producing software for the ACE. That sounds like a lot, until you compare it to the ZX Spectrum. That machine had over 24,000 third-party programs,

produced by thousands of third parties. It's a totally different scale. The Ace got by, but it never really flourished. I think the most fitting summary comes from a 1982 review in Electronics and Computing. To quote, comes from a 1982 review in Electronics and Computing. To quote, The Ace is a great little machine. It'll become better still with the advent of the 16K RAM pack, the color card in the printer interface planned for next year.

Steven and Richard also have various software packages in the pipeline. These include floating-point trig functions, turtle graphics, Z80 assembler, and games. Even without these enhancements, It was a machine that could have been revolutionary. Forth was a very solid choice for the hardware. It could have cracked open a new market, but the base machine was very lacking. Altwasser and Vickers were trying to quickly build a cheap machine and bring it to market. That emphasis on cost and speed was a problem. It was very detrimental. They launched an underpowered machine and then tried to patch

it up with expansions that either never materialized or came a little too late. The color card mentioned in the review was actually never created. Jupiter Cantab filed for bankruptcy in November of 1983. The company had survived for just 14 months. In that time, it's estimated that 5,800 ACEs were produced over the original model and a slightly improved version. But despite the short lifespan and all the issues, the ACE has retained a bizarrely loyal user base. Take this, for example, pulled from a personal computer

article simply titled Cantab Crashes. Quote, John Noyce said the user group, which has 300 members, will continue in order to help owners of the ACE. He thought that ACE users should not suffer too much by lack of support for the machine. To quote, The circuit board of the ACE is well-made and not likely to fail. The main problem is the rubber keys wearing out, but many people are already switching over to full-travel keyboards. The Jupyter Ace Archive has user group newsletters

and documents dated as late as 1990. People really love this little computer. And why not? It's a fascinating machine, even with its weird quirks and its issues. So in the end, maybe Cantab did create a programmer-oriented machine. They were, after all, able to capture the imaginations of enthusiasts. That continues into the modern day. Alright, that brings us to the end of today's episode. The Jupiter Ace was a very mixed machine. The break from basic was enough to differentiate the platform. It made the Ace, in theory, a much better choice for programmers and just a much more powerful computer.

Practice, however, was a different matter. The hardware of the Ace was cheap, but to get to that price point, corners had to be cut. Forth was efficient enough to make good use of limited hardware, but that hardware was still a major limit. Ultimately, the Ace ended up becoming an interesting blip in the larger wave of home micros. But as I mentioned, enthusiasm for the platform has remained. There are certain old computers that have this almost cult-like following, but I don't really know how systems get to that status. It seems like it's just special machines, things that capture the imagination or fascinate programmers. For instance, I don't think I've ever seen a fan site dedicated to the IBM System 23 Datamaster,

but there are a number of sites dedicated to the Jupiter Ace. There's still new software being released for the Ace today, written by dedicated fans. There are still new expansion cards. I think the pinnacle of this is this machine called the Minstrel Fourth. It's a fully modern recreation of the Ace. You can actually buy a kit and build your own minstrel by hand. In this way, I think the Ace does live on in the hands of the kinds of programmers it was designed for. Thanks for listening to Advent of Computing. I'll be back in two weeks' time with another piece of computing's past. And hey, if you like the show, there are a few ways you can support it. If you know anyone else who'd be interested in the history of computing, then please take a minute to share the show with them. You can also

rate and review the podcast on Apple Podcasts. If you want to be a superfan and support the show directly, you can do so through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and bonus content. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet or just email me. comments, or suggestions for a future episode, then go ahead and shoot me a tweet or just email me. I'm at adrenofconf on Twitter, and you can find my email, once again, over on my website. And as always, have a great rest of your day.