Toward the end of 1982, Chiat-Day’s art director Brent Thomas, along with Steve Hayden, came up with the idea of doing an ad campaign based on the timely tagline “Why 1984 won’t be like 1984.” Chiat-Day shopped it around to a number of clients, including Apple, where it was proposed for a print ad in the Wall Street Journal promoting the Apple II. But Apple didn’t go for it, and the idea was filed away until the spring of 1983, when they met with the Mac marketing team to start working on the launch, which was scheduled for January 1984.
Steve Jobs wanted to launch the Macintosh with an inspiring commercial that was as revolutionary as the product itself. He loved the Orwellian tagline when it was presented, and he encouraged the Chiat-Day team to pursue it. Steve Hayden and Brent Thomas put together an intriguing storyboard, envisioning a visually striking, highly symbolic, miniature science fiction epic featuring a young female athlete who liberates the subjugated masses from totalitarian domination by throwing a sledgehammer and smashing a huge screen displaying Big Brother.
Macintosh marketing manager Mike Murray and Steve Jobs loved it, but they needed to get new CEO John Sculley’s approval for such a large expenditure. Sculley was a bit apprehensive (after all, the commercial hardly mentioned the Macintosh), but he gave his OK for an unprecedented production budget of over $750,000 to make the one-minute commercial.
Chiat-Day hired Ridley Scott, the best science fiction–oriented director they could find, whose previous movie, Blade Runner, possessed the visionary dystopian feel for which they were striving. Ridley was based in London, so they decided to shoot it there, at Shepperton Studios. Several Apple and Chiat-Day executives, as well as Mike Murray and Steve Jobs, traveled to London for the week of filming.
Ridley’s team had assembled a cast of almost 200 by the time the Apple folks arrived. To play the oppressed, downtrodden workers, his people recruited dozens of authentic British skinheads, paying them $125 dollars a day to participate. It was harder to cast the young heroine because most of the models who tried out had trouble spinning with the heavy sledgehammer. Luckily, a model named Anya Major was an accomplished discus thrower; she could do it faultlessly, so got the part.
When he arrived at the studio, Mike Murray went looking for Jay Chiat. He found him lurking off to one side behind some scenery. Apparently, some of the skinheads were in a nasty mood, and they were looking for trouble during breaks in the filming. Jay thought it was prudent to make sure he stayed out of their way.
While everyone was off in London, I got a call from someone at Chiat-Day asking if I could write an Apple II Basic program to flash impressive looking numbers and graphs on the screen. They wanted to overlay these on the image of Big Brother. I spent an afternoon cooking something up and sent it off to them, although I was never sure if it was used.
Lee Clow and Steve Hayden presented a rough cut of the commercial to the Apple team a few weeks later, and everyone was ecstatic. The commercial was classy, suspenseful, and enigmatic, and seemed certain to garner lots of attention. It was shown for the first time at Apple’s October 1983 annual sales conference in Honolulu. Steve preceded the showing with a clever talk positioning Apple as the industry’s last alternative to IBM (see “The Times They Are A-Changin’” on page 217). The commercial got a rapturous reception. In fact the response was so great that Apple booked two expensive slots, for 60 seconds and 30 seconds, costing over a million dollars, to show it during Super Bowl XVIII, which was just two days before the Mac introduction.
Mike Murray and Steve Jobs screened the commercial for Apple’s board of directors in December to get final approval for the huge Superbowl expenditure. To their surprise, every outside board member seemed to despise the commercial. Mike Markkula even suggested that Apple begin a hunt for a new ad agency. One board member remarked it was the worst commercial he had ever seen. Steve and Mike were devastated.
The chilling reception from the board compelled John Sculley to ask Chiat-Day to sell back both of the time slots they had purchased. But Jay Chiat was true to form and sold off only the 30-second slot, telling Apple that he wasn’t able to get rid of the longer one at so late a date. Apple considered using the slot for a more conventional commercial, but in the end decided to take a chance and air the 1984 spot.
We were told the commercial would air early in the third quarter, at the first commercial break after the second-half kickoff. Burrell and I wanted to see a real audience’s reaction to the commercial more than the commercial itself (since we had already seen it plenty of times), so we watched the Superbowl at a sports bar near Stanford called the Oasis, with some other Mac team friends. The game was boring, but the bar was packed, and the commercial looked great. We thought we heard a small murmur in the bar after the commercial aired, but it was hard to tell if it was really related.
That evening, the commercial ran again on all the evening news shows. Apparently, because it had made such a splash and rumor already had it that it would only air once, the ad became a news item itself. Of course this just increased expectations for the upcoming launch. Ironically, it ran dozens of times on news shows in the next couple of days, gathering Apple over five million dollars worth of free publicity.
A week after the Macintosh launch, Apple held its January board meeting. The Macintosh executive staff was invited to attend but didn’t know what to expect. When the Mac people entered the room, everyone on the board rose and gave them a standing ovation, acknowledging they had been wrong about the commercial and congratulating the team for pulling off a fantastic launch.
Chiat-Day wanted the commercial to qualify for upcoming advertising awards, so they ran it once at 1 A.M. at KMVT, a small television station in Twin Falls, Idaho, on December 15, 1983. And sure enough, it won just about every possible award, including best commercial of the decade. Twenty years later it’s still considered one of the most memorable television commercials ever made.
Monkey Lives
October 1983
The very first location in low memory
The original Macintosh had only 128K bytes of RAM (that’s one eighth of a megabyte), so dealing with memory management was usually the hardest part of writing both the system and applications. We allocated around 16K bytes for system use, and another 22K bytes for the 512 × 342 black-and-white screen, leaving applications with only 90K bytes or so. The bigger ones like MacWrite or MacPaint were bursting at the seams.
By the fall of 1983, MacWrite and MacPaint were pretty much feature-complete but still needed a lot of testing, especially in low-memory conditions. MacPaint needed to allocate three offscreen buffers, each the size of the entire screen. This meant it was always on the verge of running out of memory, especially when you brought up a desk accessory, but the specific sequences that led to crashes were difficult to reproduce.
Steve Capps had been working on a “journaling” feature for the “Guided Tour” tutorial disc that would allow the Macintosh to demo itself by replaying back events that were recorded in a prior session. He realized the so-called “journaling hooks” that were used to feed prerecorded events to the system could also be the basis of a testing tool he called “The Monkey.”
The Monkey was a small desk accessory that used the journaling hooks to feed random events to the current application, giving the impression that the Macintosh was being operated by an incredibly fast, somewhat angry monkey who was busy banging away at the mouse and keyboard, generating clicks and drags at random positions with wild abandon. It had great potential as a testing tool, so Capps refined it to generate more semantically rich events, with a certain percentage of the events as menu commands, a certain percentage as window drags, etc.
The Monkey proved to be an excellent testing tool, and a great amusement as well. Its manic activity was sort of hypnotic, and it was interesting to see what kind of MacPaint pictures the Monkey could draw, or if it would ever produce something intelligible in MacWrite. At first it crashed the system fairly easily, but soon we fixed the most obvio
us bugs. We thought it would be a good test to see if an application could survive the monkey all night, but they usually couldn’t run for more than 20 minutes. At that point, even if it didn’t crash, the Monkey would invariably select the Quit command.
Bill Atkinson came up with the idea of defining a system flag called “MonkeyLives” (pronounced with a short “i” but often mispronounced with a long one). The flag would indicate when the Monkey was running and allow other applications to test for the presence of the Monkey. If the application found the Monkey running, it could disable the Quit command, as well as other commands it wanted the Monkey to avoid. This allowed the Monkey to run all night, or even longer, driving the application through every possible situation.
We kept our system flags in an area of very low memory reserved for the system globals, starting at address 256 ($100 in hexadecimal), since the first 256 bytes were used as a scratch area. The very first slot in the system globals area, address 256, had just been freed up, so that’s where we put the MonkeyLives boolean. The Monkey itself eventually faded into relative obscurity as the 512K Macintosh eased the memory pressure, but it was memorialized by the curious name of the very first value defined in the system globals area.
The Monkey was a small desk accessory that used the journaling hooks to feed random events to the current application, giving the impression that the Macintosh was being operated by an incredibly fast, somewhat angry monkey ...
September 1983
The Puzzle desk accessory becomes controversial
The original Macintosh could run only one real application at a time, but it could also concurrently run little programs called “desk accessories” that shared memory with the main application. Like the system itself, most of the desk accessories were written in 68000 assembly language. But in the fall of 1982 I decided to write a small adaptor that allowed desk accessories to be written in Pascal, both as a proof of concept and as a way to show developers how to do it.
Desk accessories like the calculator or the alarm clock were usually utilities, but I thought we should also have a game or two to show that the Macintosh was fun as well. I decided to write a puzzle that had 15 numbered tiles in a 4 × 4 space. The object of the game was to arrange the numbers in sequential order. If you clicked on a tile next to the empty space, it slid into that space. It was a fun way to waste time and build up mouse coordination.
Since the number puzzle was written in Pascal, it had to link with the Pascal runtime, which dragged in lots of extra code that wasn’t used. This made the Puzzle desk accessory over 6K bytes, although most of its bulk was just the runtime.
By the fall of 1983, it was time to make decisions about what software to include in the shipping product. We had shown the Mac to a number of industry analysts and, while most were enthusiastic, some didn’t really get the graphical user interface and thought it was “game-like” and not suitable for serious computing. This made some of the Macintosh marketing folks a bit leery about the more whimsical aspects of the design, and the puzzle, being an actual game, became somewhat controversial.
Jerome Coonen, the software manager, came by my cubicle one morning to tell me that they had decided to not ship Puzzle, partially because of the game-like perception, but mostly because it was just too big. Applications were very tight on RAM, and Puzzle was one of the biggest desk accessories because it was written in Pascal. At over 6 Kbytes, it also ate into the available disk space.
I liked Puzzle and didn’t want to capitulate to the buttoned-down, all-business view of the customer, so I told Jerome, “You know, Puzzle doesn’t have to be so big. I bet I could rewrite it and get it to take up less than 1K bytes. Would you keep it if I got it that small, or is it really the other issue?”
Jerome thought about it, and then told me if I could get it down to 600 bytes or so it would be in the release. The only problem was I had to get it done over the weekend, because the documentation group had to send the manuals out to the printer. Besides, there was plenty of other stuff for me to work on.
Of course, I couldn’t resist a challenge like that. It took only a few hours on Saturday to recode the puzzle in assembly language and, because it no longer had to link with the bulky Pascal code, get it down to the required 600 bytes. I proudly showed it off to everyone on Monday, and it did make it into the first Mac release and remained as part of the standard system for many years.
We’re Not Hackers!
September 1983
We were always dealing with memory limitations
From the beginning, the Macintosh was conceived as a very low-cost, high-volume personal computer. It was important for the design team to keep manufacturing costs as low as possible. Since memory was relatively expensive, we were always dealing with memory limitations.
One of the most clever parts of Burrell Smith’s original, 68000-based digital board was the “bus transformer” logic that multiplexed the data bus, allowing him to hook up the 68000—which demanded a 16-bit data bus—to only 8 memory chips. He also included a single, byte-wide 64 kbit ROM chip, so that the first Macintosh, circa January 1981, had a total of 64K bytes of RAM and 8K bytes of ROM.
But as we started to get software running on the prototype, it became increasingly clear that we didn’t have enough RAM for the kind of graphic intensive applications we wanted to build; after all, just the frame buffer for the bitmap display took up almost one third of the available memory. And furthermore, Bill Atkinson’s graphics routines had recently exceeded the size of the 8K ROM. So, when the digital board was redesigned to incorporate the SCC chip in June 1981, Burrell added another row of 8 memory chips, doubling the RAM size to 128K, and then added another ROM chip as well, doubling the ROM size to 16K. We vowed we would fight hard to make this the last increase (in contrast with the Lisa, whose memory requirements were growing considerably faster than Moore’s Law).
Even though the ROM size doubled to 16K, it was barely enough to contain our prototype environment if we included the graphics routines. Burrell figured he could add a third ROM chip, bringing the total to 24K. Two of the ROM chips were hooked up directly to the 68000’s 16-bit bus, so code could run faster, while the third chip shared the “bus transformer” circuit with the RAMs.
We built 50 Mac prototypes in the fall of 1981, each containing 24K of ROM, burned into EPROM. Although the system fit readily in 24K, we were still worried that it would soon be an unbearably tight squeeze. On top of that, Burrell never liked the inelegance of three different ROMs.
One day a few months later, Burrell returned from a meeting with a semiconductor company’s sales representative. He was really excited and almost ran into my office. “OK, you say that you won’t be able to fit in 24K, right? Be honest. How much will we really need?”
“Hey, that’s not the right way to code. What are you guys, a bunch of hackers?”
We always seemed to need just a little more ROM than was available. “I think we’d definitely make it if we had 32K,” I responded.
Burrell laughed. “No, you won’t. It’s clear that won’t be enough, since the software isn’t close to being finished yet. But I just heard that the 256 Kbit ROMs are really close, and they’ll be ready if we ship in early 1983. So I can use two 256 Kbit chips, connected up to the 16-bit bus, and we’ll have 64K bytes of ROM. 64K! ROM is half the price per bit of RAM, so it makes sense to use as much as we can. I know you’ll be asking for even more someday, but that should keep you busy for a while.”
At first, 64K bytes seemed boundless. We were already trying to write the tightest code we could, and it seemed as though it would be plenty because we weren’t even using 32K yet. But sure enough, as the system came together in the spring of 1983, we were beginning to strain against the new size limit.
Fortunately, we had started to use the Resource Manager to load objects such as fonts and drivers, so we had some flexibility when it came to keeping data on disk instead of the ROM. Jerome and I designed the “PACK” mechanism, which
used the Resource Manager to load code for optional packages, such as the floating-point routines. But code on floppy disk is much slower to load and would reduce the effective size of each disk.
Even though we tried to make our code as small as possible initially, the lack of space in the ROM made us work even harder to reduce the footprint. We developed a number of unusual space-saving techniques, some of which were inspired by tricks Woz used in the Apple II ROM. For example, we’d often push parameters on the stack out of order, sometimes four times in a row, because we had a value in a register we would need later and that we didn’t want to fetch again. We knew this made the code harder to maintain, but we thought it was worth it.
As ROM freeze-time approached, the entire team started to focus on code compression. We had a few practice sessions where everyone explained their favorite space-saving techniques, and then we all plowed through the code, saving a dozen bytes here and there. Steve Capps came up with a simple way of compressing the four or five icons that were built into the ROM, saving hundreds of precious bytes in the process.
Bill Atkinson didn’t participate in the marathon code-crunching and, except in a few cases, wouldn’t allow QuickDraw to be subjected to it. He believed that all code should be as simple and clear as possible, and thought, probably correctly, that we’d be better off without the tricks in the long run. In September 1983, just before the ROM was frozen, he found a bug in the Memory Manager that we devised a simple fix for.
I went with Bill to Larry Kenyon’s cubicle where he was maintaining the Memory Manager sources. Bill looked over our shoulders as we added a little code to correct the bug. But he objected and became upset when he noticed we used one of our coding tricks.
Revolution in The Valley [Paperback] Page 18
