As one of the half-dozen or so Apple /// fans out there, I am often quizzed by skeptical Apple II users about the computer that has sometimes been compared to the Ford Edsel. Usually, these grillings immediately follow a post (or occasional KansasFest presentation) in which I point out some of the obvious improvements and superior features of the /// as compared to the earlier home computer from Cupertino, and the queries inevitably include this one:
“Is the Apple /// really *that* much faster than the II?”
And the answer is simple: Yes. Sort of. Sometimes. Maybe.
Early reviews in trade magazines dated around the NCC ’80 introduction often mentioned that the Synertek 6502A (or later B) was advertised by Apple as “peak 2 MHz” and that more realistically, the /// tops out between 1.4 MHz and 1.8 MHz, depending on a number of factors, including the task you’re asking it to perform, how many device drivers are active, the version of SOS you’re running, etc.
(Note: SOS 1.1, which was used in the BYTE article referenced below and its predecessor, 1.0 were notorious resource hogs and ate away at precious CPU cycles and bytes of RAM even while sitting idle. Most of the bugs, as well as the bloat, were squashed with SOS 1.3 and if you’re using a real /// at home, you really shouldn’t be messing about with those older releases… your /// tip of the day folks. For the discussion below, SOS’s performance doesn’t factor in much until the disk tests.)
The common wisdom from the era is that in early ///’s, you could reasonably expect 1.2 MHz – 1.4 MHz and in later models with improved hardware and leaner software, around 1.6 MHz. The reviewers are also careful to state that unlike the II, the /// was designed so that the 6502 had a handful of supporting ICs to which it could hand off tasks so even in 1980, true MHz numbers could be deceiving. Additionally, engineers came up with a clever trick to squeeze an extra .2 MHz out of the aging CPU: if you didn’t need to interact with the /// or see what was going on (e.g., during a big sort or heavy number crunching), you could tap CTRL-5 to shut off the video signal generation circuitry. Even cooler was the fact that certain programs such as VisiCalc were smart enough to notice this and automatically re-enable the video as soon as the operation was finished. Neat!
One of the reasons I miss BYTE magazine (the old BYTE, like pre-1992-ish) is their extensive reviews that got way down to the metal and dug around for all the good stuff (and the bad stuff too that the companies didn’t want you to see).
When Apple launched the re-introduction PR blitz for the /// in late 1981/early 1982, BYTE took another look at the “newly revised” business computer. Apple had been touting the improved horsepower beneath the 26 lb. pressed-aluminum RFI chassis and how much better it was at number crunching, sorts and other functions the pinstripe Wall Street crowd would love, even two years after its release. As part of the review in the September 1982 issue of BYTE, author Robin Moore decided to run the numbers and see how much spin was really coming from Apple.
Remember that when the /// was initially released in 1980, the IBM PC was still months away from retail shelves, so there wasn’t an interesting comparison to be done. Revisiting the /// in-depth like this was really beneficial because Apple considered the PC its primary competition on the business desktop. And Moore helpfully included Apple II numbers for us fanboys too!
Something else to keep in mind before we dive in: by the time this review was published, the /// was approaching its third birthday and had come down in price somewhat, but was still much more expensive than a II stuffed with expansion cards to approximate functionality. Apple listed a 128K /// at $3,495; 256K /// at $4,295; and a monochrome Apple Monitor /// at $320.
The /// used in these tests was a 128K model with the Synertek 6502B, a single external Disk /// Drive, and Business BASIC. Total price: $4,115.
The IBM PC was a 4.77 MHz Intel 8088-based system with 48K base memory, a disk adapter card and one 160K internal floppy drive, a 16K memory / game adapter expansion card, a single additional floppy drive (the PC could only handle one external drive at the time), a RS-232C interface card, another 64K memory expansion card, a color graphics adapter card, and IBM Advanced BASIC. All of these add-ons brought the PC approximately up to what was available in-built to the ///.
Even with the extras you’d have to buy to match specs, the PC was still slightly cheaper, at $3,980. On the other hand, this configuration maxed out all the expansion possibilities in the IBM; the Apple still had four free slots available to the user, plus the interface ports on the rear of the computer.
A fourth machine, a 4 MHz Z80 whose brand Moore doesn’t mention, is also given a lane in this digital derby. This machine was tested with Microsoft MBASIC 4.51.
Moore takes a moment to note the difference in sales philosophy between the two companies. Apple’s approach was to build in all the “good stuff” a business user might need and then charge accordingly, whereas IBM sold you a basic machine at a lower cost and let you fill it up with whatever you felt you’d need to get the job done. Interesting that IBM’s thinking was much closer to how the Apple II was developed and marketed than Apple’s own offering.
Moore doesn’t list what he put in the II (and in fact, he may have run the tests in the ///’s Apple II Emulation mode, which obviously invalidates those results as anything but a curiosity), but he does pause to mention how differently Apple viewed its potential /// customers from the II buyers, and he does it by pointing out the documentation that ships (or rather, doesn’t) with the ///:
“Much of the technical information included in the Apple II is absent in the Apple /// package. There is no discussion of bus structure, I/O addressing, memory usage, or screen-memory mapping. There are no listings published for any of the system software, either in the Apple /// ROMs or on disk. Apple does not even tell you about the monitor program in the ROMs…”
Moore goes on to check out the hardware (he really seems to like it – a man of impeccable taste, obviously…), features unique to SOS, graphics modes, INVOKABLES and other points of interest before he gets down to business and pits the machines against each other in a brutal performance deathmatch. Well, maybe not quite that dramatic… (I’ll have a link to a PDF scan of the original review at the end of this post, if you want to read the whole thing.)
Let’s take a look…
All of the benchmarks are done in the machines’ respective versions of BASIC and Moore lets us know that the ///’s 6502B is crippled right out of the gate by its own language:
He also notes that Business BASIC will likely see bigger performance gains over Applesoft with larger programs, and that the tests didn’t include the video blanking trick in the ///, costing it seconds in the final numbers.
Moore’s routines include a number of simple instruction sets, all of which seem likely to be functions commonly used by BASIC programmers: IF… THEN statements, REM execution, basic maths and variable handling, prime numbers, loops, etc.; as well as disk access times for floppies and fixed-media systems.
And… drum roll please… dah duh-duh daaaaaaah!
It’s clear that while the ///’s Business BASIC enjoys a slight-to-medium advantage in some (but not most) program execution areas when tested against the II running Applesoft, it’s really no contest when it faces the IBM PC and the Z80. As expected, the II drops far back when tasked with complex math functions, but the /// still isn’t close to the other competitors. The results are undeniable: across the board, the /// just can’t keep up.
At least in Business BASIC.
Unfortunately, Moore’s benchmarks are rather narrow in scope (in fact, it appears he didn’t test the PC or the Z80 himself, but pulled the numbers from another BYTE article). It would have been nice to see how the /// stacks up when flexing some serious spreadsheet calculation muscle in Advanced VisiCalc (to be fair, the PC’s killer app, Lotus 1-2-3 wouldn’t be released until the year following Moore’s review), or Pascal program execution, or in a mixed BASIC and assembly environment. Other critical testing areas such as graphics performance are absent as well.
So what’s the lesson here?
It’s something you still hear today, that “megahertz don’t matter”. And that’s true in the general sense (due to their efficient RISC architecture, both DEC’s Alpha and Motorola’s 680×0 chips for years easily outperformed similarly clocked Intel processors, for example), but a battery of focused benchmarks can give you a good overall view of where one machine is going to shine… or stumble.
Also remember that Moore’s tests don’t take into account the ~ 30% speed increase gained from disabling the ///’s video circuitry, so the gaps may be narrower than they first appear.
And finally, considering all the complex memory bank switching and other voodoo the /// system has to do behind the scenes to trick the 6502 into seamlessly accessing as much as 512K, the fact that it didn’t fall hopelessly behind the simpler, more elegant Apple II is a testament to the brilliant engineering that really is present in the ///.
On the other hand, given those same very thin apparent margins over the II (again, assuming that the Applesoft tests weren’t run in emulation) and the significant price disparity and divergent design philosophies behind the machines, it’s easy to see why the /// had a such a hard time finding a place of its own in an increasingly crowded and cut-throat marketplace.
Tomorrow, we’ll go over the rest of the article, where Moore looks at the all important disk seek/access times…