A behind-the-scenes look at the development of Apple’s Lisa.
Reprinted from Byte, issue 2/1983, pp. 90-114.
Of the more than 90 members of the Apple engineering staff who participated
in the Lisa project, Wayne Rosing, Bruce Daniels, and Larry Tesler are three
of those who were most responsible for its final form. Rosing, formerly of
the Digital Equipment Company, oversaw hardware development until Lisa went into
pilot manufacture and then assumed responsibility for technical management of
the entire Lisa project. Daniels and Tesler were responsible for Lisa’s systems
software and applications software, respectively. Chris Morgan, senior editor
Gregg Williams, and West Coast editor Phil Lemmons interviewed the three at
Apple’s headquarters in Cupertino, California, last October.
BYTE: Tell us how you staffed the Lisa project.
Tesler: In software, we drew mostly experienced people from other companies and
very few people straight out of school. Even the ones we took
out of school generally had lots of job experience. In fact, one time I surveyed
the applications group and found an average of nine years’ work experience
in software. When we looked at resumes, we tried to find people with several
years of experience in development. We made exceptions if someone had specialized
in something we were interested in or was a top student who also had good summer
experience. We wanted an experienced team because what we’ve been doing is
a very major software effort. It’s very complex, and there’s such a
large body of software to crank out and make reliable that it takes experienced
BYTE: When did you do the hiring?
Tesler: The project went through phases. There was some design and some
implementation when the project first started two and a half years ago, but
we hired most of our software people about two years ago. In three months,
we hired most of the software staff, and then they spent several months learning about the
machine and designing their particular parts of the software. The bulk of the
programming started about a year and a half ago.
We had to spend quite a long time just building a team – people who had a common
view and could work together. We drew people from different companies with
completely different backgrounds and tried to do, something that nobody in this group
had ever done. Some of us had done parts of it before. We were developing everything
in parallel: the hardware, the operating system, the applications, the manuals,
the details of the user interface. We did have a sort of fundamental philosophy,
but having to do everything at once means you’re never sure when you’re going
to get what you need from the person who does whatever you need next.
Daniels: I think communication is the key there. If you have that many things
going in parallel, you spend a lot of time communicating so each of you knows what
the other’s doing and can depend on each other.
Tesler: It took a while to work out those channels. It was rough at the
beginning, but it’s pretty easy now. Our progress was gradual. I think I’d
call it team-building. Some of the things were hard to do in an organization that’s
thrown together like this. But once you’ve got a team built, it’s a
valuable asset. Of course, we were doing technical work all along, but in a sense
we spent a year building the team and a year building the product. Now when we
build something else, we can do it without the team building step.
BYTE: What about project security?
Rosing: We tried to be as secure as we could without creating a discouraging
atmosphere for people to work in. Within the group there has always been total
information transfer, and we’ve kept lots of machines available. People have been
able to tab machines home with them. There was always the risk of losing a Lisa
in a burglary, but we had a rule that floppy disk had to be kept separate from
the machine. We felt it was worth risking a theft to gain the increased productivity
of people working at home. We’ve been very fortunate; we haven’t lost
BYTE: How did you schedule the project?
Tesler: People made estimates, but it was difficult. All the estimates were
conditional – “If the hardware is here by a certain date and
the operating system is frozen and I have the user-interface definition and I
can get some assistance from people who have the right sort of experience,
then I can do it in this many months.” But none of the ifs were ever
really possible. People were really hesitant to make a firm date because there
were so many contingencies. We did come up with schedules all the time, but they were myths.
Daniels: Getting Lisa to market has been a dream, a goal that we all have,
Although we’re willing to make compromises to get Lisa out expeditiously, the
dream of what we’re trying to achieve is the major thing.
Rosing: We had this dream of what we wanted to do, and I think over
time we recognized that we couldn’t achieve some of the goals. We’ll have
to take care of them later. We’ve taken the attitude that Lisa is going
to be good and we’re not going to sacrifice the integrity of the product
for scheduling. We wanted to make a very balanced set of decisions, and so
everything, as I say, just started to come together. The floppy disk works
well, the mouse works well, the hardware works well, the software is beginning to
come, and now we’re cranking to get this first release out. But we won’t
let it be compromised because of scheduling.
Daniels: Part of the difficulty was that both the user interface and the
internals – the architecture – of the software are revolutionary.
Getting that architecture designed and built was a big scheduling problem. Once
we’d done that, we’d built the foundation. Now building the applications
is much smoother and has been much easier for us to predict.
Tesler: We didn’t know if some of the things we started would work
at all, like the way the dot-matrix printer is used and even the way the
letter-quality printer is used to print the graphics.
Daniels: No one had ever done that before.
Tesler: Theoretically, it ought to be possible, but it had never been done,
and the manufacturer of the printer didn’t believe it could be done. It
had to be possible in order for this product to do what we wanted, but no
one could predict how long it was going to take. When we hired the printer people
we told them to do it in two months. It took them a year and a half, but they
did it. And then the high-density disk drives are new technology to Apple.
A lot of the concepts in there had never been tried before. That was one of the
biggest risks. And Apple not only built disk drives for the first time but built
revolutionary disk drives.
BYTE: What makes them revolutionary?
Rosing: One of the major things we did was to vary the speed of the disk
as you change the track position, so the drives keep constant area density and
that gives them a greater capacity. Second, we used microstepping algorithms
on the stepper motor so that if a head gets off track because of changes in
humidity and temperature, the intelligent controller can hunt and find the track.
So we have much better interchangeability, with much higher density, and we’re
getting approximately 50 to 60 percent more data on that disk by good systems
engineering. Some of the competitive units have a greater capacity, but
we think the error rate ultimately suffers. We wouldn’t tolerate a serious
BYTE: How does the error rate com pare with double-sided double density disks?
Rosing: As for hard-error rates, we’re talking about 10-12,
and that occurs after so many bits that it’s hard to measure. But we’re
quite delighted that the measurements are impossible to take. Basically that means
the errors are low.
BYTE: Did you work more than 40-hour weeks?
Tesler: Each engineer set his or her own schedule. Some engineers work something
like Monday through Friday from nine to five. Others work all day at the office,
then go home and work all night there. And what an individual engineer does may
vary from time to time.
Daniels: These people have pride. They set their own milestones ant they
want to meet them, so they’ll put in extra work to do that.
Tesler: We decided a long time ago that since the project would obviously go
on for more than a few months – a couple of years – we couldn’t
have this constant pressure on everybody, because people would just crack.
BYTE: As individual designers, do you feel that your signature is on that machine?
Tesler: I think that’s true of everybody in the group. Even people
who have been with us for only a few months have something in the Lisa that they can
look at and say, “That was my idea; that’s my code.” It’s
really a group effort. Even marketing got involved in the design effort in
various ways, particularly in user-interface issues, product design, packaging,
and the style of the manuals. The whole division really got involved.
BYTE: When did you decide to incorporate all the fundamental applications into the
Daniels: At the very beginning. Some applications weren’t decided until
later, but the integration, the way it all fit together, was a goal from the very beginning.
Rosing: As a matter of fact, we cut out a few more things because we just
didn’t feel we could manage a project that large. Then we added a couple
things back in as we became more comfortable with the development cycle. But we’ve
basically been operating on the same goal for the past two years, with very
little change of direction.
BYTE: What was the sequence in the early days? Did you decide what the project
had to look like to the end user, and then what software was required, and then...
Daniels: Then hardware. In fact, we spent the first six months hammering out
the user-interface docket. We had that completely specified before we really
started the applications. I think the key to success here is to know where
you’re going before you start.
Tesler: The hardware, the operating system, and the applications were
all developed somewhat in parallel, but there was a definite cause and effect.
The people who designed the hardware had to make decisions, for example, about
whether the disk drive should have a door that you flip open or a button to
push, that kind of thing. The designers focused on that aspect of the user interface
even before the rest of the user interface. They didn’t want the user to
be able to accidentally pull out a disk when it was being written on or something.
So some decisions were made even
before the hardware was designed. There have also been hardware revisions. The first
Lisa hardware was here when I came, over two years ago. It’s gone through
several... how many revisions since then?
Rosing: About four. Each one’s been an iteration. We discovered a
few things in the early hardware that wouldn’t work well. We just took them
out because we couldn’t do them properly. The rest has mostly been a
matter of fine-tuning Lisa so that it’s very manufacturable and very reliable.
Tesler: Each time they go through a cycle, the people working on user
interface get another crack at it – “Since you’re going to revise
the hardware anyway, why don’t you...?” Or the people doing the operating
system say, “The memory-management unit needs to be more general, and
since you’re redesigning the hardware anyway...” So we were able to
get in some hardware revisions. Also, that keyboard you saw yesterday is not
the final one. After user testing, and because of needing to support the
European market, we determined that we really needed a couple more keys on the keyboard,
so we made a major change in the keyboard layout.
Rosing: One of the things about this project that’s different is that,
more than any other I’ve been associated with, there’s a continuous loop for dealing
with user issues. We’ve gone to the software and that has implied a hardware
change. We synthesized a lot of different disciplines. The power-off button used to be
a traditional button on the back of the machine, but we didn’t want to
encourage users to turn off their machines that way because if they left a
document open, they would lose it.
BYTE: Do you expect to find a little initial resistance to the fact that
the machine doesn’t actually turn off when you push a button?
Do you think people are going to say, “Well, I know I can leave it alone
now, but I want to make sure it turns off”?
Rosing: Right. It does feel a little funny at first, but after a few times you
begin to have confidence that the thing does turn itself off.
BYTE: When you finally got the user-interface specified, did you have a
brief description of it that everybody knew by heart?
Daniels: It was about a 35-page document.
BYTE: Thirty-five pages of specifications?
Tesler: We have something called the
User-Interface Standard, and it consisted of those things which would be common
to all applications. Also, the year after that document was published some revisions and
some changes were made, and as we built applications we found that they had even
more in common than we envisioned. Then we would adopt those things as part
of the standard.
Daniels: Another thing we’ve done is
user tests – taking our ideas and bringing in naive users and sitting them down
and seeing what their impressions are. That has caused some changes, and I
think that’s all shown in the quality.
BYTE: Where did you get your naive users?
Tesler: Various places – the bulk of them were new Apple employees.
We had a screening process. New Apple employees go through an orientation the
first Monday morning they’re here. We handed out a questionnaire to the
new employees about their previous experience with computers word processors, video
games, and that sort of thing, and then what kind of work they did. Someone in
our training department screened all those vitae. I’d go in and say I needed
three user test subjects this week who have no word-processing experience but
who are secretaries or accounting people to test out our Lisa Calc. She’d go
through and pick out some candidates and I’d pick the ones wanted, based
on their experience for whatever test I was trying to run. We had about 50
tests this year in engineering to test out the software.
BYTE: The fact that you responded to the tests speaks well for the end product.
The changes in the keyboard, for instance. How recently did you decide to change
the keyboard for the final time?
Tesler: There were several changes. Those from the user tests had to do with
changing the numeric pad so it had the arrow keys on it so you could move around
in the Lisa Calc table. Those tests were run around January , I think.
Rosing: January, and in March we decided to make the change.
Tesler: That was just key-cap legends that had changed. The other change
has to do with the number of keys on the keyboard and was primarily for the
benefit of international sales, although it did improve the user interface in
terms of the positioning of the Enter key and the Extended Character option key,
which gives you extended character sets. Those were all done around the same time.
Rosing: The interesting thing is that we were at the stage in the program
where the decision to make even what sounds like a simple change takes six months
to percolate through because it’s not a simple engineering change – it’s
manufacturing, tooling, documentation.
Daniels: We made one legend change in June or July – the Apple key. When was that?
Tesler: July, and it’s just now showing up.
BYTE: A legend change?
Tesler: You saw two keys that said Command on them. The new version has only
one, and instead of saying Command it has a picture of an apple on it. The reason
is that the key’s used as a shortcut to choose a menu command. If you
look at a menu, on the right you’ll see this little apple symbol
and a letter. If you hold down the Apple key and the letter, you get the command.
We couldn’t find any way to symbolize the Command key that would fit nicely
in a menu and be recognizable to people. We tried and tried. Finally we decided that
the apple looked nice and had a nice sound to it – “Apple X,” “Apple
R” – and it keeps Apple in the mind of the user instead of
“control” something else. It’s a symbol that everybody using this
machine will recognize instantly, so we decided to put it on the key as well as
on the screen. To finish the artwork in time to get the machines to test users
in time to get responses, and so on, the change had to be in by a certain date.
The decision was made only hours before the deadline.
BYTE: Are there going to be two Command keys without legends on them?
Tesler: No, only one. We studied IBM and DEC and other keyboards and found
that they all have just a single Command or Control key on the left-hand side.
We also really wanted to put an Enter key on the main keyboard because we would like
to be able to offer a configuration in which an alphabetic keyboard and a numeric
keyboard are independent – for, say, a company that does only word processing.
Word processors don’t need the Clear function, but they do need the Enter
function, so we wanted to be able to have the Enter key on the main keyboard;
that way, even people without numeric keypad can hit Enter. Again, on IBM and DEC
keyboards the Enter key is standard; on many of those keyboards, that’s the
standard position for the Enter key. So we decided to be more like other
companies. The Enter key also gives us the option of removing the numeric
keypad without losing an important function. And then the option keys were put
on the side of those, and there we decided we did need two option keys, left
and right, because they’re used very much like shift keys for typing, and
in Europe it would be very important to be able to touch-type foreign alphabets
for international correspondence, mathematical symbols, and other special
characters. So there were some trade-offs. We didn’t want to just keep
jamming two of every key on the keyboard, so we decided what the priorities were
and ended up being fairly close to the industry standard. We have one Apple key,
one Enter key, and two Option keys.
BYTE: The user-interface design seems to have been difficult.
Tesler: That was the hard thing that affected the most people. A lot of
software and hardware engineering issues were very difficult, but they affected
only a few people. Interface issues affected half the division because Training,
Publications, Marketing, and the software person implementing the application all
had an opinion. People like us who were overviewing all the applications had
opinions, in-between managers had opinions, kibitzers on the side had
opinions, too. Not everybody can
talk about what gate to use in some circuit or what routine to use in some
program, but everybody can talk about the user interface. So we had to
accommodate all of these things. And it turned out that good ideas and good
criticisms came from everywhere. We had to come up with some objective way
to decide. That’s why we established the methodology which involved user
testing. We had a procedure for proposing changes, reviewing the changes,
narrowing it down to a few choices, with certain criteria like consistency and
parsimony. And then we actually implemented two or three of the various ways and tested
them on users, and that’s how we made the decisions. Sometimes we found
that everybody was wrong. We had a couple of real beauties where the users
couldn’t use any of the versions that were given to them and they would
immediately say, “Why don’t you just do it this way?” and that was obviously the
way to do it. So sometimes we got the ideas from our user tests, and as soon
as we heard the idea we all thought “Why didn’t we think of that?” Then
we did it that way.
BYTE: Bruce, could you say something about the software architecture?
Daniels: There’s an operating system underneath that we built ourselves
because we felt that the ones that were out there didn’t quite meet our
BYTE: What does yours do that others don’t?
Daniels: It’s not just what it does, what it doesn’t do.
Some other operating systems are basically timesharing systems like Unix
that have a lot of features that we don’t need, and why take
up extra space for that? We wanted a system that the user didn’t
have to be experienced to understand, and it had to be very reliable.
It had to maintain the user’s data and keep it there. It also had
to support things like graphics, the windows that we have on the screen, the
mouse, and so forth. We didn’t really find an operating system that met
our needs, so we felt we had to go build our own. We built the other features
on top of this – the support for the windows, the support for graphics,
the support for multiple fonts, the support for printing. It’s really quite
a rich architecture. At least half of the software is in this foundation software.
BYTE: How large is that in bytes? How much code is in that foundation software?
Daniels: Well, source code is something like 10 megabytes.
Tesler: Object code is about half a megabyte.
BYTE: That’s what’s there before you put the application programs
in – half a megabyte?
BYTE: After you specified the user interface, what list of hardware
requirements did you come up with?
Rosing: Well, the main list that was specifically user interface would
be the bit-mapped graphics display and the resolution of approximately 700
pixels across in the horizontal dimension, the mouse, and the doorless
disk drives with the eject button rather than an eject handle. They determined
a lot of the hardware design. We had other user-interface considerations, though.
We wanted to make the system very easy for its users to service – I presume
you’ve seen it break apart. Servicing really is simple. It took a
moderate amount of extra product cost to get that feature in there. And that’s
a part of the even more global user interface, how people perceive the whole
BYTE: Why did you choose the 68000 microprocessor and what alternatives did you consider?
Daniels: We thought its architecture was very broad and strong and would
take us through the ‘80s, and we wanted that. We wanted something to
support the graphics, and we thought that processor gave us what we needed
then. The 68000 was a bit of a gamble because it was very
young when we got on it. We were getting one sample at a time from the local
Motorola engineer here.
BYTE: Do you think the 68000 will be the dominant processor in the next
few years? Is it going to overcome the 8088, the 8086?
Rosing: I would speculate that high-end applications with very
computer-intensive, graphics-intensive needs, the 68000 will become dominant.
Daniels: But the 8086 has such an installed base going already, I think
that alone would carry it...
Tesler: You mean numbers of actual units with the 68000 in it, or
number of different products?
BYTE: Both of those questions.
Tesler: Well, we’re putting 68000s in the units we’ll sell, so that
will mean more units with 68000s. We expect to sell a lot of machines.
BYTE: You’ve got a 68000 machine with a lot of memory in there, and
not too much special-purpose hardware. Why did you decide to do it that way
instead of using some versatile hardware chips, like the NEC 7220, for video display?
Daniels: We’re very much boosters of bit-mapped graphics, and in fact
hardware support for bit-mapped graphics is pretty small. All you need is
sort of a shift register. We thought the flexibility that would give us in
graphics and the things we could do in user interface with bit-mapped graphics was
well worth the price.
BYTE: But doesn’t the 7220 have bit-mapped graphics itself?
Rosing: Well, there were a couple of practical considerations. The NEC 7220 didn’t
exist when we designed Lisa, although we knew it was planned. The second
consideration was that the 7220 cost more than the TTL [transistor-transistor
logic] hardware needed to implement the equivalent functions. And the third
consideration was this: because we were able to interleave the memory and
display cycles, we were able to essentially get data out of the memory at very
little penalty. Using a 7220 would actually cost considerably more in terms of system
performance. And there was one more consideration: with the 7220, you can’t access
the display memory bank when the chip is refreshing the CRT, and that limits the
time you can access it to about 10 percent of what we have, which would drastically
affect performance. We can access memory any time. For equivalent performance,
we would have to use two 7220s, and that would push the cost and the “real estate”
beyond what we have.
BYTE: On the other hand, software doesn’t get written overnight... there’s
a certain cost to that. You know, this is very software-intensive.
Rosing: Most of the software that supports the graphics took three years to write,
but no hardware in the world can duplicate what that software does.
BYTE: Really? The software is faster than the hardware?
Rosing: No, not always faster.
BYTE: Its functionality is greater?
Tesler: Yes. The graphics package lets us draw circles, rectangles, ovals,
and rectangles with rounded corners. It also automatically handles clipping on
nonrectangular boundaries. If you have one object over another, you can draw
the one behind without splashing the pixels on top of the one that’s in front.
BYTE: A software revolution?
Tesler: A very unusual capability, which no one else has in that general
form. The other implementations are all either very, very expensive
hardware – the $100,000 class – or in software, which isn’t really
that general and performs much much worse. There’s nothing in the same
class as our software as far as capability and speed. Of course, there is graphics
software that’s faster and hardware that’s faster, but it doesn’t have
anywhere near this capability.
BYTE: Do you have a Xerox Star here that you work with?
Tesler: No, we didn’t have one here. We went to the NCC when the Star was
announced and looked at it. And in fact it did have an immediate impact. A
few months after looking at it we made some changes to our user interface based
on ideas that we got from it. For example, the desktop manager we had before
was completely different; it didn’t use icons at all, and we never liked it
very much. We decided to change ours to the icon base. That was probably the only
thing we got from the Star, I think. Most of our Xerox inspiration was Smalltalk
rather than Star.
BYTE: What does Lisa have that the Star doesn’t have?
Tesler: We’re talking about graphics capability. You originally asked
why we didn’t use graphics hardware. Our graphics primitives in software
are more general than the Star’s, so they perform better. We have a faster
and more general ability to draw on the screen a picture of multiple graphical
objects in different shapes, to have one window that uncovers another, and
to repaint just the parts that are uncovered.
Daniels: Look at the desktop managers of the Star and Lisa. With the
Star, you can only put them at fixed places on the screen so you know they
don’t ever overlap. On ours, you can put them any place you want.
It’s that generality that allows I us to have arbitrarily shaped things
I and covering each other up and...
BYTE: Documents or forms, shapes, or anything...
Tesler: Right. We have curves in it. Everything in the Star, you’ll
notice, is really rectangular, and our things can have curved edges and that sort of thing.
BYTE: Another hardware question: How many microprocessors are in the machine,
what are they, and what do they do?
Rosing: Let’s see. One to scan the keyboard, in the keyboard housing
proper; a second one that receives the keyboard commands and keys up mouse events;
the 6504 that controls two floppy disks; a Z8 microprocessor in the hard-disk
controller – it’s an intelligent controller; and then, of course,
the 68000. That’s five.
Tesler: Almost every major chip manufacturer except for one.
Rosing: And with only one exception all our I/O (input/output) cards have microprocessors.
BYTE: You say that the magnetic read/write head in the disk drive is
microprocessor-controlled in order to let it be more sensitive to variations
in the alignment. Is that the 6504?
BYTE: What is the microprocessor that handles the keyboard and the mouse?
Rosing: That’s a National COPS. We tried to pick the processor that we
felt was best for each particular job.
BYTE: The memory is 64K-byte chips?
Rosing: Yes, 64K chips.
Tesler: On the memory we have parity and...
BYTE: What part of the memory is video memory?
Daniels: Some area in the main memory can be the video.
Tesler: Any area at all. In fact, if you noticed yesterday in the
demonstration, when we’re developing software, we need debugging information
to be displayed for the programmer, but we don’t want it to come out on
the same screen that the user is seeing, so we had this magic toggle we were
hitting that flipped between two screens. There are really two different areas
of memory with a bit map in each. The software can switch between the two
to display each in turn.
BYTE: But they’re within the main memory?
Tesler: Yes, absolutely. Anywhere in memory. Take any number of
consecutive bytes and say that’s the bit map.
BYTE: Is anything else in main memory, or is the rest of it all available
to the user? Is anything else mapped to the memory?
Tesler: Oh, I see what you’re saying – the shared memory. Shared
memory with I/O is not main memory. The I/O memory is in the I/O cards.
Rosing: It’s not in the memory, but it’s accessed like
main memory, from the 68000 bus.
Tesler: It’s in the address space, but it’s not in those
BYTE: A certain address is really at I/O port, is that right?
Rosing: Yes; it’s the top physical address of the 68000.
BYTE: Did you consider voice as part of the user interface?
Rosing: Yes. We looked at it pretty hard and at one time in the early system
we actually had a CVSD-based voice subsystem in the computer, and we took
it out because we didn’t feel it achieved the quality we wanted to have
associated with this system.
BYTE: What does CVSD mean?
Rosing: Continuously Variable Slope Delta modulation. It’s much
easier to say alphabet soup. We’ve thought about voice; it’s part
of our network architecture and will appear in the future, but only when
we feel the technology’s right so we can be proud of what we offer.
BYTE: That’s both input and output!
Rosing: Right. We look at voice as being three problems. There’s store
and forward, which is just moving voice messages around, like a glorified
answering machine. Second is text to voice; and third, of course, fit
voice recognition, or voice to text. The last one’s the hardest of all,
but we look at voice technology as something we have to approach in a unified way.
BYTE: What about the programmable serial ports? What chip is used there?
Rosing: They use the Zilog SIO. That was one of the last major changes we
made in the hardware design. We did it because we had two high-speed ports
with less board space, and the Zilog SIO chip supports asynchronous as well
as byte-sync and bit-sync protocols. We felt that made a heck of a lot more
sense for the customer as the world evolves toward X25-type packet transmission.
We didn’t want to make the customer buy an I/O card to upgrade from
async to bit-sync. We have only three I/O slots, so we’re careful not to
waste them on things we can put in the main machine.
BYTE: Both serial ports can be bisynchronous?
Rosing: Yes; they can be programmed any way.
BYTE: And can this SIO function as a UART?
Rosing: Yes. A UART/USART combination.
BYTE: When did you know that you were going to have half a megabyte as
standard memory? When did you know how much you were going to need?
Daniels: It’s always been a backward sort of thing. We had the
capability for a full megabyte in the machine, and it was more a case
of how much memory we needed to achieve our goal.
Tesler: The sales force wanted it to be 128K; the programmers wanted
a megabyte. We negotiated.
Rosing: Since we were writing the code we got the megabyte.
Tesler: So the hardware people made it as big as they could in
the address space, and then after some testing of the system we determined
that half a megabyte was a reasonable compromise of cost and performance.
BYTE: Do you expect the standard memory on other manufacturers’ machines
to jump dramatically after the appearance of Lisa?
Tesler: Well, apart from its impact on cost, I don’t think the amount of
memory is a critical factor in deciding what machine you want to buy.
If you’re an end user, you should be buying a machine based on what it
does for you, how easy it is for you to learn, how easy it is to use. Whether
it has 12 bytes or it has 12 megabytes doesn’t really matter to the end user,
which is our marketplace. We’re not selling the machine primarily to programmers
who might care about that. End users have no idea which systems have more memory or
less memory or one megabyte or one hundred thousand bytes. If other manufacturers
are trying to match Apple, they should try to match us on ease of use and
functionality and things like that. If they can do it in a small amount of
memory, more power to them.
BYTE: Doesn’t it matter when you’re doing something like dictionary
software or when you want to read a dictionary into memory fast and proofread
a document very fast?
Tesler: Yes, there are certain functions where it definitely makes a difference.
We have that in our Lisa Calc. In order to do rapid recalculation, the whole
matrix really should be in resident memory, so we spent a lot of time coming
up with a data structure that packed that data as tight as possible so that
it would get as many cells as possible into memory, no matter what size memory there
BYTE: Your version of BASIC will use more than 64K?
Daniels: Oh, yes. We could have put less memory in it, but the performance
would have been unacceptable. Unfortunately, some companies advertise machines that
have less memory than anyone would ever reasonably buy. We haven’t tried to do that here.
BYTE: You didn’t use less memory and fewer disk drives than would really
be effective, and so on?
Daniels: Yes, and I think when you look at the typical configurations that
people buy of other machines, the cost is really not that different from
the kind of costs we’re talking about for Lisa. If the other machines
get loaded up with disks and memory and the other kinds of things you want
to run, then their prices will be comparable.
BYTE: When you decided you had to have hard-copy graphic output that accurately
represented the quality of the screen graphics, what choices did you consider
before you did this amazing adaptation of a $600-$700 printer?
Rosing: A wide range of options were being discussed, all the way from
thermal printers to laser printers. We tried to identify what’s critical
in the marketplace. We thought there were two printers of first priority:
a personal printer and one with letter quality. At the same time our sister
division, the Apple II-III division, was evaluating the same two sets of
printers. So we teamed up and did a survey of virtually all the printers that
were available from every manufacturer who would have the volume capability to
serve our needs. We did an extensive test and put about eight dot-matrix printers
through their paces with really tough software. Quite a few of them just
fell right off the table – it was clear that the quality wasn’t there.
Certain vendors were also much more responsive to fixing problems. So it
really boiled down to two printers. Then, as we developed our printer software,
the one we’re using now – the C. Itoh – just far and away
stood out as having the best mechanical design. You could put the dots
where you wanted them repeatedly, and that’s what we needed more than
anything else in the world – good mechanical design.
Rosing: And a good price. Same for the letter-quality printer.
BYTE: The printer you are using is from C. Itoh, but it’s your own ROM
and your own systems software that drives the printer through the ROM.
BYTE: What else can you tell us about the printer, especially the dot-matrix?
Daniels: Mechanically it’s just a raster device.
Tesler: A character generator is built into it; it has some capabilities.
It has a single type style that can be stretched horizontally and vertically
as it’s printed, and it has what they call a graphics mode. They
thought that would be used lightly, but it’s what we use almost exclusively.
And even within the graphics mode, there are two resolutions, low and
high. High resolution is a lot slower. We wanted to offer the user all these choices.
BYTE: So this is a custom design for you... custom changes?
Tesler: Custom changes I would say, yes.
BYTE: Did you say it sometimes prints out in character mode? I thought all
of its printing when you were controlling it was using the highest
Daniels: I think all the stuff you saw was done at high resolution.
BYTE: For speed you can go to a different mode?
Tesler: Yes; we’re planning to offer the customer a way to get a
quick draft using the character generator. Characters won’t look quite the
way they will in the final version, but you can get output in a hurry.
Rosing: The printer will have three different speeds and three
different quality levels.
BYTE: Do you have an idea where you’re going next?
Rosing: We have what feels like ten years’ worth of backlog. We
have a pretty good idea what we’re going to do for the next few years.
BYTE: What’s that?
Rosing: The thrust is to expand the level of integration within the
applications and to add facilities to make it easier for more applications
to be written outside of Apple.
BYTE: Those facilities are development toolkit?
Rosing: Yes. The development toolkit is a key thing. And for a
large part of the marketplace, adding network applications and data communications
is very important. Last but not least is adding really serious database
functionality to the system. If you add all that up, it’s as big a task
or bigger than what we’ve just done.
Daniels: In fact, almost as important as the team building that
we’ve gone through is building up this foundation that we’ve used
to create the six applications we’ve now built. The foundation is
an amazing application machine. We and others outside Apple can build applications
that are just amazing now, because no one has to rebuild the foundation. It’s
already there, in place, and we really hope to leverage off that in the future.
by Chris Morgan, Gregg Williams (Senior Editor) & Phil Lemmons (West Coast Editor)