iWoz (28 page)

The 8-bit data code came from 4 bits of real computer data. I used a lookup table to do this efficiently.

Even so, it was barely possible for a perfect program, a program I had to write to myself, to keep up with this rate. And I had to count the exact number of clock cycles, in microseconds, for every step. That way, when I output 8 bits of code data to the controller, exactly every thirty-two microseconds, it matched the rate it had to be written onto the transfer rate. No matter what paths my program took, how many instructions, how many branches, how many loops, it always happened exactly every thirty-two seconds, when the next batch had to be written.

This sort of precision timing is a software job only a hardware person could deal with. Software programmers don't have to deal with precise timing ever.

• o •

This is as tricky as code gets. Even a minor change in the microprocessor could have killed it. For example, if they came out with a version of the 6502 that took three microseconds for a particular instruction instead of four, it would have screwed up all my calculated timing and the floppy controller for the drive would no longer work.

The floppy controller card had to accept 8 bits and merely shift it out to the floppy disk, through a magnetic write head, similar to writing to a cassette tape. That was how you saved data to the floppy, and that part was easy. An 8-bit shift register (registers hold data) could be loaded off the bus and do the four- microsecond shifting of the data.

Coming back from the other direction, reading data from the floppy was more of a challenge. I came up with the idea of creating a tiny processor—a tiny microprocessor, actually—I had to implement as what is called a state machine.

I did this using two chips, which was a remarkable achievement. One chip was a register and one was a PROM. I think I used a 6-bit register. Some of its bits were like maybe six of the Is and Os in this register, corresponding to a particular "state" the machine might be in. They functioned as address bits to a PROM.

The PROM would take as address inputs the bits indicating the current state—from the register—and also the bits of data from the floppy disk. Every microsecond, this PROM would output as data the next state number (which might be the same) and also a couple of bits that controlled the 8-bit shift register. That would shift the Os and Is to it in the appropriate time—when the time came to make decisions. That next state number would be reloaded into the register that held the state number.

Basically this little state machine was analyzing what was coming from the floppy disk every microsecond, and saving it in the master 8-bit chip register. Don't confuse this 8-bit shift register with the register that held the state number for the state machine.

I had to fill the state machine PROM with Is and Os that caused the right actions in my machine. This was much more difficult than writing a program on a microprocessor, because every 1 and 0 had a specific, important meaning on that PROM.

I completed the state machine and was sure it would work. It was elegant—in fact the whole design was elegant, and I was proud of it.

Now, all this data (Is and Os) was coming from the floppy disk, but I had to be able to determine which 0 or 1 would be the start of a byte. (Remember, 8 bits together form a byte.) Also, when this four- and eight-microsecond timing between transitions

came from the floppy disk to my controller, I didn't know which of the Os and Is was the start of a byte.

I was scared for a week or so as I built my controller that I wouldn't be able to solve this. But I did come up with some abnormal patterns that could be written onto the floppy disk but didn't translate back to data.

I would write about sixteen of these patterns in a row, and when they read back into my state machine, they automatically kept shifting it in time until it lined up with where the bytes would actually be. Then my read program, in the computer, continually looked for a couple of start bytes, called "mark bytes," which I'd write to indicate the start of a small section of data, called a "sector." Along with the data for each sector, I'd write the sector number of data on the floppy so that the reading program would be sure it was writing the correct sector. (If the reading sector ever determined the data was wrong, it would try again.)

• o •

For the floppy, I did the hardware design and the state machine coding. I also wrote the very tightly timed code to read and write specially coded data to and from the floppy disk. This was my forte.

Randy Wiggington wrote a higher-level routine, more useful to application programmers and operating system programmers.

After I was able to read and write data, I wrote routines to step the head to any of the thirty-six tracks on the floppy disk. It would step for a long time to position itself on track 0, the innermost track. Then I'd give a sequence of pulses to a stepper-motor to step the head to track 1, then track 2, and so on, to get to the point where the data it needed was. I had to wait a certain time between this track-stepping, as specified by Shugart.

At one point it occurred to me that moving the magnetic read/write head was like moving a heavy car. It has inertia. It's slow to get started, but once you get it moving it rolls on its own

inertia and you can push it to make it faster, and then faster yet. I decided I could probably safely accelerate the head as it crossed multiple tracks and then decelerate it to get it going slow enough not to overshoot the last track. Even if it overshot, it would read the track number it got to and then back up.

I experimented and came up with a table of acceleration/deceleration numbers for timing that worked fine. Now, instead of a click-click-click sound like the burst of a machine gun, as the head moved around it made a nice-sounding whoosh. We had the fastest floppy disk access times in the industry because of this.

This sounds very complicated, I know. But it had very few parts. Making it work was incredibly hairy. It was one of those things you don't even know is possible. You can get an idea of just how much I sweated in those two weeks.

I know all this got really technical, but I had to explain because to this day, engineers are always walking up to me and saying how great that floppy controller I did was. And in just two weeks. Now you know how I did it.

• o •

The code was just about to the point where we could type "R Checkbook" to run the checkbook program or "R Color Math" to run the math program. I didn't actually have a floppy disk operating system in two weeks, but we had a table on the disk that tracked and sectored each program occupied. Normally an operating system would read an index to the whole disk and when you requested "Color Math" it would look up in the index the list of tracks and sectors it occupied. We didn't have this quite working the day we had to fly to Las Vegas, but Randy and I were sure we'd have it done in a few hours after we got there.

So we got on the plane in San Jose and flew to Las Vegas.

• o •

That was a night Randy and I will never forget. It was our first time seeing the lights of Las Vegas. We were stunned by it. It was a much different and smaller strip than today, with much smaller hotels. There weren't even as many of them as there are now, and many were old and tiny. But it was impressive. We'd never seen anything so lit up, that is for sure!

Our motel was the cheapest place in town, the Villa Roma. It was near Circus Circus and we learned the route from there to the Las Vegas Convention Center. Randy and I did a lot of walking that night. I showed Randy, who was seventeen at the time, how to play craps and he won something like $35. At the convention center, we watched the late-night setup of all the booths. We set up in our booth and worked until about 6 a.m., finally getting everything working.

At that point I did one very smart thing. I was so tired and wanted some sleep but knew it was worth backing up our one good floppy disk, with all the right data.

I had some short programs that allowed me to read and write entire tracks. The floppy disk had thirty-six tracks. I decided to make a copy of this one floppy disk we had worked so long and hard to prepare. I only had two floppy disks with me so I decided to copy the good one to the blank. I inserted the good floppy and entered some data into memory to cause it to read track 0. Then I put in the blank floppy and used that data to write "track 0" on it. I did the same sequence for all thirty-six tracks. Backing up is smart, I always say.

But when I finished this backup, I looked at the two unlabeled floppy disks and got a sinking feeling that I'd followed a rote pattern but accidentally copied the bad floppy to the good one, erasing all the good data. A quick test determined that this is what happened. You do things like that when you are extremely tired. So my smart idea had led to a dumb and unfortunate result.

It meant that we would not, due to our tired state, have the floppy ready to show when the CES started in a few hours. What a bummer.

We went back to the Villa Roma motel and slept. At about 10 a.m. I woke up and got to work. I wanted to try to rebuild the whole thing. The code was all in my head, anyway. I managed to get the good program reestablished by noon and took it to our booth. There we attached the floppy and started showing it.

I can't tell you how successful and noted it was at this show, particularly in comparison to the Commodore PET and Radio Shack TRS-80, which were at the CES as well.

• o •

The floppy disk made the computer fast, but it was a program named VisiCalc that made it powerful.

Two guys in Boston, Bob Frankston and Dan Bricklin, worked closely with Mike Markkula to design it. And boy, was this the right product at the right time! And it was definitely the right program for the right machine.

VisiCalc was a software product for business forecasting—it was designed to answer "what-if" scenarios. For instance, if we sell $100,000 worth of product X, how much revenue will we get? What if we sell half that? It was the earliest software program for doing spreadsheets on a personal computer, so that regular people working in business really had a high-tech tool.

And VisiCalc was so powerful it could only run on the Apple II. Only our computer had enough RAM to run it. The Radio Shack TRS-80 and the Commodore PET definitely weren't powerful enough. But we had the RAM, we had graphics on-screen and a two-dimensional display, and we were easy to use out of the box. And VisiCalc came out not on cassette, but on floppy disk. What a match.

Our business just exploded when VisiCalc came out. And the Apple II market suddenly moved from hobbyist people playing games who didn't mind waiting a few minutes for the program to load from tape, to business-type people who could load VisiCalc instantly.

After a couple of months, the businesspeople were something like 90 percent of the market. We had totally missed this audience, we never thought of it. But it took Apple in a whole new direction.

From 1,000 units a month, suddenly we went to 10,000 a month. Good god, it happened so fast. Through 1978 and 1979 we just got more and more successful.

By 1980 we were the first company to sell a million computers. We were the biggest initial public offering since Ford. And we made the most millionaires in a single day in history up to that point.

I believe the whole reason for this was the combination of the Apple II, VisiCalc, and the floppy disk.

• O •

Remember when I told you Mike had us copyright the software? Well, what a good move.

After the CES, we found out about a new computer from a company called Franklin. It supposedly looked a lot like ours. It arrived at our building, and it looked so much like the Apple III was very interested.

I thought, Hey, great. They copied my design. I wonder how much of it they copied. I didn't expect they would've copied much of it. I figured engineers are trained to invent and design their own things. An engineer would never look at another person's design and copy it, would they? No, that's what they go to school for. They go to learn how to design their own things.

I walked over to the main building to look at it. There it was, and I was shocked. The printed circuit board inside was exactly the same size as ours. And every single trace and wire was the same as ours. It was like they'd taken our Apple II board and Xeroxed it. It was like they'd just Xeroxed a blank Apple II board and put in the exact same chips. This company had done something no honorable engineer would've done in their effort to make their own computer.

I couldn't believe it.

Well, at the next computer show I attended, I immediately went up to their booth and told the president, who was in the booth, "Hey, this is just a copy of ours." I was all upset.

"This is ridiculous," I told him. "You copied our board. You just copied it. Which means I am your chief engineer, and you don't even give me credit for being your chief engineer."

The president looked at me and said, "Okay. You're our chief engineer."

And I was happy and walked away, but now that I think of it, I should've asked him for a salary!

We did sue them later, and I found out their argument for doing it. They claimed there were legal reasons that gave them the right to copy the Apple II. They were arguing that because there was such a huge software base of programs for the Apple II, it was unfair to exclude them. They claimed they had a right to build a computer that could run that software base, but that argument sure didn't make sense to me.