Apple IIe and IIc Design Manager Peter Quinn Interviewed by BYTE's Gregg Williams
A behind-the-scenes look at the development of the Apple IIe and IIc.
I’m fascinated by early Apple history. So, here is another interview covering one of their earliest systems.
[Editor's note: On March 16 and May 2, 1984, I interviewed Peter Quinn— first about the Apple IIe and later about the IIc. The Apple IIc had its roots firmly embedded in the IIe project, and parts of both machines were designed simultaneously. Here are some excerpts from these interviews. . . . G.W.]
An interview with Apple IIe and IIc design manager Peter Quinn
BYTE: Were you in on the Apple IIe design from the beginning?
Quinn: From the very beginning. I was originally hired [November 1980] to redesign the Apple III. to customize it—I'm an IC [integrated circuit] designer also. I worked on that for about six months. Then Apple approached me to manage. . . . I was the hardware design manager of the IIe and worked with the design team, including the industrial designer, the firmware people, and such. I brought that out and rolled right into this product—the IIc—where I was more like the engineering director in charge of hardware, firmware, product design, and disk drives.
BYTE: I was particularly pleased by one of the first Apple IIe ads that showed both the II+ and the IIe and had the headline "Success/Successor." When you started out, in what ways were you attempting to make the IIe the successor? What were your design goals?
Quinn: Well, you really have to go back to the history of the machine. Steve Wozniak started to design a custom, integrated Apple II—the project was called the Apple Annie—and the engineer he worked with at Synertek to do the custom IC was Walt Broedner. Walt was so impressed with Apple that, even after the project was cancelled, he tried to get a job here and subsequently did.
Walt always had it in the back of his mind to do a customization of the II. Management fought it for a year at least because they weren't into custom ICs. So he'd keep on proposing it and getting knocked down. Finally, there was this reorganization. With me being an IC designer and so forth, I backed him.
Walt partitioned out the machine (the IIe) and came back with the original plan, which was fairly close to what we have now. We all knew that we had to enhance the keyboard and give it 80 columns.
To do 80-column text, Walt mirrored the text page, which is at [hexadecimal address] 400. And that's all he did. It was a 1K mirror of the text page that, every other character, you bank switched. But then he was driving home one night and he said, "Hell, if I've got the flags to switch that memory area, why don't I switch the entire 64K area?" So the idea of getting 128K in the Apple II was an inspiration that fell out of that.
The video slot—the auxiliary slot, we call it now—grew out of Walt's wanting to get 80 columns and his interest in video—[high-quality] RGB color. (Broedner later left Apple and founded Video 7, a company that manufactures RGB cards.) Another reason for the slot was because the test engineering people wanted the signals available on the IIe motherboard. The whole idea was to make the IIe as open a machine as possible by bringing out all the major signals to either the peripheral slots or that auxiliary slot.
BYTE: How did the IIc get started?
Quinn: The history of the two products was so intertwined. While Walt was designing the custom ICs on the IIe, marketing was. . .starting slowly to create [the IIc] . . .adding in the disk controller, the serial port for a printer [on the main board].
[Marketing] wanted to take some of the slots out and put in some built-in peripheral handling. And engineering was quite upset about that. They felt . . .we'd have to make it [Apple's next product] as much like a II as possible only better.
So Walt talked with Steve lobs. And Steve said, "Yes, I think you should do the IIe the way you had planned"—with the open architecture—"but if you want to do a focused product, then this is the one." And he painted out basically what you see now in the IIc, except it didn't have the built-in disk drive. It had its built-in mouse port and one serial port and a few goodies like that. At that time the computer was called VLC for "Very low-cost." It was basically a computer and a keyboard.
Walt came back and did some more work on the customs [ICs] and he said, "What if I wanted to do both the machines in one?" Basically, he put the logic for the mouse-handling stuff [into the custom chips] by using the space occupied by things that aren't in the IIe—like annunciators, the particular I/O mapping, and such. By grounding a pin when you assembled the die, you changed the complexion of the chip.
BYTE: Are you talking about the IOU [the Input/Output Unit Apple IIe custom chip] in particular?
Quinn: And the MMU [the Memory-Management Unit custom chip]. The reason I tell this story is to show you how we had a head start on the IIc right from the beginning. I then went to marketing and said, "The chip count is minimal on the IIe. We do it this way. You let us slap out the IIe in six months or so. Then we'll turn around and divert all our energy to this more focused built-in product." And they bought it. So we finally finished up on the IIe.
BYTE: What kinds of hardware and software compatibility problems did you have? After all you wanted to keep the Apple IIe compatible with the II+.
Quinn: As for firmware. I had to struggle like hell to get anybody because everybody was working on the Apple III at that time I was able to finagle Rick Auricchio. He was one of the original Apple fanatics and hackers— he knew the history. You cannot get someone to write firmware for this machine unless he's been around for three or four years. You have to know how to weave through the mine field [of unofficial but commonly used entry points]. He was extremely good. He added in all the 80-column and Escape-key stuff, and I thought it was really clever. That was a struggle—firmware was right down to the wire on this.
BYTE: What was the hardest hardware compatibility problem?
Quinn: We had trouble getting the slots working, particularly with the Microsoft [Z80] card because the timing in this machine was slightly different. The guy who designed the Z80 card, although I liked him, did a schlock job of it, so we had to tune the machine [the IIe] slightly off such that it would be like the Apple II and the card would work.
BYTE: When did you start working on the IIc?
Quinn: Strictly speaking, work on the custom-chip design started around 1981. Then, we diverted all our energy to bringing the IIe out, which was obviously successful. A month before the IIe was introduced [in January 1983], my engineering team was winding down.
So, right after Christmas [1982], we started the Apple IIe project. Although we had already done a great deal of the circuit design, the IIc was much more massive a project. Basically what Steve asked was to build an Apple IIe with an 80-column card, another 64 K of memory two serial cards, a disk controller card, and a mouse card—all that to go in an 11- by 12-inch package.
The goal was for it to fit inside the standard size briefcase you buy at Sears. The things we worried about were heat, how to get the power supply in that small an area, and just how to get all that circuitry in that amount of area. I brought my handy-dandy take-apart IIe. [Peter pops open the Apple IIe: inside are a keyboard module a disk drive, a power-supply module, and one circuit board with connectors on its rear edge.]
BYTE: What does the power-supply box on the floor supply to the main unit?
Quinn: The box just takes AC current and puts out semiregulated 15 volts DC. What this means is that the computer takes an input here [he points to the power-supply connector on the IIc], either from the power-supply box or from any 9- to 20-volt source. We made the range so wide because— well, you know what a car battery does in the winter in Canada. It [the power-supply circuitry internal to the IIe unit] takes any voltage in that range, does a DC-to-DC conversion, and puts out +12, -12, and + 5 volts— I think we generate - 5 [elsewhere] on the board because we don't use much of it.
The keyboard, we reengineered: it's our own switch. It's a low-cost but extremely reliable switch technology: a thin metal sheet with a spiral cut in it on the top and a contact at the bottom—when you push it in, it spirals in and makes contact with the bottom. We also added another spring that gives the keys a tactile feel....
We've got the 65C02 [microprocessor] in there which gives us 27 additional op codes. This allowed us to crunch the [additional] firmware into 16K, which is all we had available. Not only did we have to handle the monitor, the 80-column firmware, Applesoft, and all the IIe stuff, we had to handle the two serial ports, the mouse, and all that other good stuff.
BYTE: The firmware on the Apple IIe mouse interface card takes up 2K of code. You must have done a lot of crunching to get mouse-related code into the space you had in the IIc.
Quinn: Well we had something they didn't—the custom ICs have built-in handling of the mouse. The Apple II with peripheral cards has to have a certain protocol just to go through the I/0 space—this we can map direct [which also decreases the amount of code needed]. We could play a lot of tricks that way.
We made the IIc internationally configurable. This chip here [indicating the model] contains the keyboard map, which, for the international market, will give you French and German and dynamically change the layout. In the international version of the IIc, this switch [just above the "3" key] switches you from, say, a UK to a German layout. An interesting story—we had this switch on the international version and the hole in the case. Rather than tooling up two cases [an additional case without the hole for the American version], we thought about putting in a Dvorak layout for the IIc (the IIe already has it inside, but you have to change the circuit board to get it). At first, marketing wasn't very receptive, but they did some research and it is gaining ground. So, at no extra cost whatsoever, we had Dvorak for the American market.
These two chips, the AClAs [asynchronous communications interface adapters], handle the two serial ports. We were able to crunch the circuitry down not only with a lot of [custom] integration but also with PALs [programmable array logic chips]. Right now, these are PALs. which are expensive; eventually they will be customs—the GLU is an up-and-coming custom gate array that you place here, which allows you to take these two 74LS161s out and save some cost. [Because of the miscellaneous functions it performs, GLU stands for "glue."] Eventually, you can
pass that along to the user— that's what we did with the IIe.
Another way we got space out was to go to hybrids [clusters of resistors, transistors, and other components housed in one IC-like package]. For example, here we took a collection of discrete circuitry—in this case, the video circuitry—and crunched it into one of these. Again, with the audio, we went to the hybrid.
We'll also have a custom TMG [timing] chip here. And we have a third custom that we did in collaboration with the Macintosh group, the IWIM [integrated Woz machine], which integrates the full state machine of the disk-controller card.
BYTE: What were the biggest problems you faced in getting a board this compact to work?
Quinn: The two major challenges were heat and radiation. There is a lot packed into this area, and we at Apple have to adhere to the corporate spec of having all equipment work up to 40°C ambient. We originally had a lot of CMOS in the computer. We experimented with lower power disk drives that would have been a lot more expensive—we tried all sorts of things. The solution we finally ended up with was to go to some very intricate venting schemes. If you look at the board, it looks like a hunk of Swiss cheese. See all the holes we have for no apparent reason? That's so we get the proper convection when it's laid in [assembled]. We get convection in the disk drive, which is, of course, the biggest offender, and it's vented in very specific ways.
It was funny, the way we decided on where the holes should be. We got out the old Black and Decker, drilled holes and tested it in the oven, taped some holes up and drilled some more—empirical. But we kept on using the low-power drive because we were still over the spec. Finally we did some control experiments and used the normal high-power drive and that got us under the limit!
BYTE: It generated less heat than the low-power drives?
Quinn: The overall unit generated less heat. I took four years of physics, but it's somewhat confusing to me why a higher power drive would cause less heat. Our only explanation is that it caused enough heat such that you got a heat rise, which pulled in a vacuum—and that got us the convection we needed.
BYTE: How did you manage to meet the RU (radio frequency interference) specifications?
Quinn: We were really careful. On the top, we power-gridded the power lines very carefully and created a virtual ground plane. We were very careful with the layout of the components—for example, the oscillator, which generates 14 MHz. The higher in frequency you get, the scarier it gets, so we only ran 14 MHz to chips that were right in this immediate area.
On the bottom, where the noisier power signals are, we took this metal sheet, which is tied at about 12 points via screws so we keep the whole grounded. Unfortunately, EMI [electromagnetic interference] is something of a black art. We went through many revisions of the board until we finally got it. I'm pretty proud of that. [Peter reassembles the IIc, which takes less than 15 seconds.]
BYTE: How does the keyboard connect to the main unit?
Quinn: Flat cable.
BYTE: So with the exception of some cables that you didn't put in. you're actually assembling a unit.
Quinn: That's correct. Except for the two cables and the screws, that's it— that's my second born.
BYTE: You once said the IIc was called a very low-cost machine.
Quinn: The Apple IIe's first code name was LCA, for "low-cost Apple." Then this [the IIc], because everything was going to be built-in and crunched, was "very low-cost."
BYTE: But the price really ended up not being that low.
Quinn: Well, VLC at the time did not include a disk drive (which is a big cost factor), it was only 64K, it didn't have all the I/O the IIc has. It originally had one serial port, but marketing came back and said. "Uh-uh. everyone's going to want a modem, ultimately, in the home and in industry. Everyone is going to want a printer—and, specifically, they're not going to want to unplug one to get the other." That's how we came to put in two serial ports, and of course that adds to the cost. Also, as we use more custom parts, get the manufacturing more automated, and lower our overhead in general, that'll bring the price down. Look at the trend of the IIe; we introduced the basic unit at $1395—that was with no disk drive, no anything. Now the same box with a disk driver and controller is going for $995.
BYTE: There are a lot of parallel-oriented peripherals out there. How did the Apple designers decide to go with serial ports instead of parallel ports?
Quinn: A number of reasons, not the least of which is the amount of space you need to bring out all the major signals for an 8-bit data bus—we didn't have a whole lot of space.
BYTE: You mean you didn't have enough space on the rear panel.
Quinn: Right—a parallel port would normally be as wide as a DB2 5 [connector]. The main thrust in our peripherals—the Imagewriter and our modem—is serial. So it fell out from there.
BYTE: Another important connector on the rear panel is for [high-quality] RGB color.
Quinn: Actually it's called the video expansion port. All the major signals are brought out there where hardware designers can get their mitts on them. In fact, we bring out sound here—when you connect a TV set through an RF modulator, you can go to the TV and turn the sound down. [Sound comes out of a small speaker beneath the keyboard on the Apple IIe and earlier computers and cannot be turned down.] So that was one feature we wanted. We knew we wanted RGB ultimately: we wanted a lot of video modes. With another box, we can convert the [American] NTSC [National Television Standard Committee] signal to PAL [Phase Alternate Live], the British standard.
And one of the guys at Apple, Rick Geiger, was saying that flat-panel technology was right around the corner. And we said, "Yeah, sure" [he laughs]. But we were smart enough to think that maybe we didn't know everything, so we bought out basically all varieties of video signals. And that allowed us to get the flat-panel capability when it came out—it came out a lot sooner than I thought.
I have a model here: we have five working prototypes, but 1 couldn't get one for today The first one we got working, we made this cable that goes from here into a cigarette lighter I took it out of the car and sat there and played Lode Runner. This is a state-of-the-art LCD [liquid-crystal display]- it's got 560 by 192 pixels, which will give you full double high-resolution pixels as well as the 80-column by 24-line display.
BYTE: What are some of the ROM changes that were made to the IIc? I've heard that some bugs in the IIe ROM have been fixed, and there are 32 graphics characters.
Quinn: The 32 graphics characters are what's called Mousetext. They are icons—hands, open and closed apples—embedded in the character set. They [software developers] were running into problems doing very fast, very quick word processors, for example in high-resolution graphics. You're handling a chunk of data and scrolling becomes noticeably slow, but that's the only way you can get icons because your character set has nothing but ASCII characters.
The older Apple IIs have inverse and flashing characters in the character set. They [the Apple IIc design team] took some of these characters out and put in the icons. There are some plusses and minuses to doing that—it causes some incompatibilities with software already out. But the developers gave it an overwhelming "Please do it!"
BYTE: What about Apple IIe bugs?
Quinn: One of them doesn't affect the user, but it affects Apple Do you know what "screen holes" are? [They are bytes within the text-page area of memory that do not show on the screen.] Obviously we have those in our main 64K bank of memory but you also have corresponding screen holes in both versions of the Apple He 80-column card. It turns out that if some Pascal routine looks at a certain screen hole and the firmware is pointing to its alternate—all this depends on how the RAM powered up, whether a certain location was 1 or 0—the computer would reset on scrolling. It turns out that the 64K[-bit] RAM chips [used on the extended 80-column card] come up in the right state. But the static RAMs for the regular 80-column card can come up either way—it depends on sunspots or what day of the week it is. I don't know. Anyway we had to trash a certain percentage of our RAM chips [because of this].
There's some problem if you're using it [the Apple IIe] with a modem and [an Apple] Super Serial type [interface] card [running] at 1200 baud—I don't have the details.
BYTE: Some problems with different kinds of modems or just one?
Quinn: Basically all kinds, I think. It actually worked, but you'd load your buffer and get garble on the screen. So it was loading in the text or whatever fine but it would upset the user a bit.
[Editor's note: Once the IIc had been out for a while, some users found that it worked with a modem at 300 bps but not at 1200 bps. Apple traced the problem to a hardware design flaw. According to Peter Quinn, new IIcs will have the flaw fixed and existing IIc owners can get both a software patch and a hardware modification from their dealers. . . .G.W.]
BYTE: Tell me something more about how you used the 65C02 to crunch the code down to a smaller size.
Quinn: The 65C02 gives you 27 additional op codes. Not only were they able to write more crunched code for the peripheral-handling stuff, they also went back and crunched some of the existing video-handling routines. They were fixing bugs while they were at it. The developers can use this code, too, but they have to make a choice of whether or not they want to make their software backward compatible [with Apple II+ and IIe].
Later in the year or early next year, we'll probably offer an upgrade kit [with a 65C02 and a character generator ROM] that will fix the [IIe] bugs, but it will give you Mousetext. That causes some incompatibilities [with existing software].
BYTE: I take it there have been no changes to the Applesoft ROM?
Quinn: There have been. We decided to make lowercase [BASIC keywords] work.
BYTE: Are you going to get any increased performance on Applesoft because of the 27 additional [65C02] op codes?
Quinn: I didn't have the guts, when we brought out the IIe, even to touch that ROM space But [with the IIc] I had the best three firmware writers in the world—Dick Huston, Ernie Beernink, and Rich Williams—working for me and we made the choice [to add lowercase BASIC keywords]. But as far as going in and using different op codes, I wasn't that gutsy.
[Editor's note: An interesting aside—the firmware writers embedded their names in the IIc. To see them, do an IN#5, then INPUT AS, then PRINT AS. Slot 5 has no use in a IIc, so the designers designed in a "ghost" peripheral that gives their names in a string as its input to the Apple G.W.]
BYTE: But there's a difference between, say, a speech-synthesis board, which needs a couple of bytes every few milliseconds, and a coprocessor board, which supposedly takes over the whole box. Wouldn't that be impossible for your serial
port [on the IIc]?
Quinn: Well, we don't have just the serial port; we also have the disk-drive port, which runs at more than 400K baud. Depending on how much intelligence you put on that outer box, nothing is impossible for an Apple II. Look at the Rana [8088 coprocessor] box—its co-processor does MS-DOS and all that and hooks into an Apple II. Of course it goes through the [peripheral] slot.
BYTE: That's what I'm saying. Without slots [which the Apple IIc doesn't have], how can you get the throughput you need for a coprocessor?
Quinn: Several ways. One you use a more or less high-level language [for] swapping between this processor and that processor. So the crunching happens over there and then comes back and is delivered through this I/O [the IIc serial ports]. You don't need that tremendous throughput. And there are other ways. Of course these serial ports go up to 19,200 baud, and I believe with some tricks should do better than that. As you know, the Apple third-party developers are the first to find the tricks usually. So the door is not closed by any means.
BYTE: I guess the only question to end with is a general one: where do you see the Apple II product family going?
Quinn: Two years from now, you know the technology is going to progress even farther. Flat-panel displays will be a dime a dozen, VLSI will be more than feasible, so we'll be able to crunch more. So we'll do what we've always done in the past—take the same machine, maintain its greatness and its compatibility, and add value for the same price. Building in modems, building in RGB, you just take a shopping list and add to it. We may extend it lower—we're working on that. It depends on what makes sense—when you've got it bread-boarded and wire-wrapped, does it look right? Does it feel right? Do you want one? We are unwilling to create anything we wouldn't want ourselves.
What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.
Great article. Thanks
When the //c came out it was unable to run CP/M. So… we started a company and developed a box called the Applix Plus80 that was basically an external box with Z80 and 64k of RAM and two serial ports. One serial port plugged into the //c, the other to your printer.
When the box powered up it was in printer buffer mode, but when you booted CP/M it actually ran CP/M on the box and used the //c basically as a terminal and for disk I/O. All this was possible because the serial chip in the //c could run in this weird x10 mode, so 192k baud which was actually quick enough for decent disk I/O.
Applix the company went on to do ‘great’ things, but the Plus80 started it all!
I grew up with the Apple IIe! It was our family computer and also a common computer in some of the old school computer labs. Thanks for sharing!