I sat down with one of the patent lawyers, Ed Taylor, and went through all the clever things in my design that other people definitely wouldn’t have done before. How I did the color, for instance, and how I did the timing for the DRAM.
We ended up with five separate parts of a patent. It was a good, secure patent that was going to wind up being one of those patents in history that become very, veiy valuable. It was going to be the heart of lawsuits to come. For instance, it would come in handy when people tried to copy, or clone, the Apple II and other products after that.
Back then, there were no ideas of how software could be patented. This was such new stuff. We found out that copyrights were a better way to deal with people copying our technology. Copyrights were an easier, quicker, and less costly way than patents to stop people who tried to copy our computer outright.
• o •
Soon after the West Coast Computer Faire, where we introduced the Apple II, a couple of other ready-to-use personal computers came out. One was the Radio Shack TRS-80, and the other was Commodore’s PET. These would become our direct competitors.
But it was the Apple II that ended up kicking off the whole personal computer revolution. It had lots of firsts. Color was the big one.
I designed the Apple II so it would work with the color TV you already owned. And it had game control paddles you could attach to it, and sound built in. That made it the first computer people wanted to design arcade-style games for, the first computer with sound and paddles ready to go. The Apple II even had a high-resolution mode where a game programmer could draw special little shapes really quickly. You could program every single pixel on the screen—whether it was on or off or what color it was— and that was something you could never do before with a low-cost computer.
At first that mode didn’t mean a lot, but eventually it was a huge step toward the kinds of computer gaming you see today, where everything is high-res. Where the graphics can be truly realistic.
The fact that it worked with your home TV made the total cost a lot lower than any competitors could do. It came with a real keyboard to type on—a normal keyboard—and that was a big deal. And the instant you turned it on, it was running BASIC in ROM.
As I said, Commodore and Radio Shack within a few months came out with computers that also ran BASIC out of the box. But the Apple II was far superior to them. The Radio Shack TRS-80 and Commodore PET did have DRAM like the Apple II, but they were limited to only 4K bytes of it. The Apple II could expand up to 48K bytes on the motherboard, and even more in the slots.
The TRS-80 and PET only came in 4K or 8K models, and they weren’t expandable. The Apple II had eight slots for expansion; the other two had none. Finally, the PET and TRS-80 screens were black-and-white. No color like ours. And they had rickety keyboards with small keys.
The Apple II could grow into the future and had so much versatility built in. That’s why it became the leader.
• O •
The Apple II was also an ideal computer for anybody who wanted to design a computer game.
We provided documentation and tools, making it really easy for programmers to create games in BASIC (at a hundred commands a second), or machine language (at a million commands a second), or both. The only way you could create a game for computers like the PET and TRS-80 was strictly in BASIC, and only with text characters onscreen. Unlike the Apple II, these machines didn’t have graphics. It was inconceivable that anyone could’ve created a compelling arcade game on any of those computers.
Within months dozens of companies started up and they were putting games on cassette tape for the Apple II. These were all start-up companies, but thanks to our design and documentation, we made it easy to develop stuff that worked on our platform. Generally these little companies amounted to little more than a single guy in his house who figured out how to write a neat game, wrote it, and copied it onto a bunch of cassette tapes that he then sold through specialty computer stores.
And back then, there wasn’t software rip-off happening like there is today. The stores weren’t, for example, taking one cassette tape and making a bunch of copies and not paying the original guy. None of that was going on because there wasn’t much money in the business yet. Ethics could still be high. It wasn’t as if there was that much more money to be made by stealing.
So all the tapes the stores sold were legitimate, and the stores
were taking a cut on the games they sold. Within a year a whole Apple II industry sprang up with dozens and dozens of companies of little guys—just onesy-twosy companies, really—at home writing software for the Apple II.
And then little companies started building circuit boards that fit into the Apple II slots. Boards were easy to design for the Apple II because we gave complete documentation on how our boards worked. Also, I had included some great tools: the Apple II had a little operating system developers could access, as well as a set of easy-to-use software debugging tools I had written myself.
So how do you design a printer board that will attach a printer to the Apple II? How do you design a scanner or a plotter board? It was all so well documented that within a year of the Apple II shipping that June, all of a sudden there were all these Apple II add-on products being sold by people.
People who wanted to do an add-on board not only had to design that board, but they had to write a little program—a device driver program that translates between computer programs and the actual hardware. The predecoded addresses I had for all eight slots would be connected to a ROM or PROM chip on the board containing this program. The program could be 256 bytes long with just a single PROM chip, but each slot had another 2K bytes of predecoded address space for a larger amount of code. You had to be aware that this second address space went to every board, so in order to use it, there had to be some other circuits that knew which board was in control.
Otherwise, when one of these 2K bytes of addresses came along, a bunch of boards would put data to the processor, and the boards would conflict. Each board also had 16 predecoded addresses intended to trigger hardware—to control and sense the hardware devices.
There were so many options available to a board designer that
it led to a lot of very creative designs. The best designs made the most of the least, just as I like to do.
The computer magazines had tons of Apple II product ads for software and hardware. Suddenly the Apple II name was everywhere. We didn’t have to buy an advertisement or do anything ourselves to get the name out. Our name was suddenly all over the place. We were just out there, thanks to this industry of software programs and hardware devices that sprang up around the Apple II.
We became the hot fad of the age, and all the magazines (even in the mainstream press) started writing great things about us. Everywhere you looked. I mean, we couldn’t buy that kind of publicity. We didn’t have to.
• o •
Like I said, the Apple II used a cassette tape for data storage. I had never been around or even used a floppy disk in my life. They did exist, though. I’d heard of floppy disks you could buy for Altair-style kit computers, and, of course, the expensive minicomputers of the time used them. Now, all these were in the big, eight-inch floppy format. That means they were spinning magnetic disks that measured eight inches in diameter. And you could only hold about 100K bytes of data on each floppy disk. That’s not very much by today’s standards. Totally, it’s only about 100,000 typed characters.
But Mike Markkula told me at a meeting that we really should have a floppy disk on the Apple II. He was annoyed at the way it took forever to get his little checkbook program to load from cassette. A floppy disk, because it spins so much faster and stores data more densely, would load the checkbook program much more quickly.
For instance, a computer could read 1,000 bits per second off a tape, but it would go 100,000 bits per second off a floppy.
I knew that the Consumer Electronics Show (CES) in Las
Vegas was coming up. It would b
e the first CES where companies could demonstrate computers, and only marketing people from Apple were going.
I asked Mike, if I finished the disk drive in time, could I go to Vegas for the show, too? He said yes.
That gave me only two weeks to build a floppy drive for the Apple II, a device I had never seen working before or ever used in any way, but I now had this artificial motivation (artificial, because of course I could’ve gone to the CES if I wanted to) to try to astound people at Apple again.
I worked all day, all night, through Christmas and New Year’s trying to get it done. Randy Wiggington, who was actually attending Homestead High by now, the school Steve and I had graduated from, helped me a lot on that project.
• o •
To help me get started, Steve told me he’d heard that a company named Shugart, which was the main floppy drive manufacturer at the time, was coming up with a 5-inch format. (Alan Shugart had invented the floppy years before when he was at IBM.) Steve was always looking for new technologies that had an advantage and were likely to be the trend, and this was definitely a case like that.
He got one of the new Shugart 5-inch drives for me so I could see if I could make it work with the Apple II. What I had to do was design a controller board—a card that would plug into the Apple II—that would let you read and write data from the floppy. The first thing I did was examine the drive and its controller board and how they worked. I scanned the manual. Finally I studied the schematics of their circuitry, and I analyzed Shugart’s floppy disk circuit too. It had a connector and a protocol for how signals would be applied to write data. In the end, I decided that of the twenty-two or so chips, about twenty of them weren’t needed. To make the floppy disk work required a combination of a circuit I
had to design and the existing circuit on the Shugart drive. I stripped out twenty of their chips, so that reduced twenty of my total end product. That’s the way I always think about things. I could run data right from my own floppy controller to the read/write head and implement any start/stop protocols of my own in code on the computer. To tell you the truth, it was less work on the computer than generating the funny protocol Shugart wanted. Then I sat down and came up with a very simple circuit that would write data at floppy disk rates and read it. This turned out to be a real challenge.
• o •
In the case of the cassette tape interface I’d designed, I had a signal that constantly varied from high to low and low to high and so on. The signal could never stop as long as the tape was running. The circuit handling signals to a cassette recorder weren’t designed to let a signal stop changing.
And the tape wasn’t able to store a signal that stayed the same for too long. So I had the microprocessor time the low-high-low transitions according to the Is and Os of the data being written. I chose the rates of this cassette data to be between 1,000 and 2,000 hertz. Those were typical voice frequencies that a cassette tape was designed to record and play. That’s approximately one millisecond (a thousandth of a second) between transitions from high to low to high and so on signals.
But the signals to a floppy disk needed transition times that were much shorter—only four to eight microseconds (or millionths of a second). There was no way to get my microprocessor to generate these timings directly from the Is and 0s. It was just too fast. After all, the 6502 microprocessor inside the Apple II ran at a clock speed of approximately 1 MHz. The fastest instruction took two microseconds and would take many instructions to generate the timing for Is and 0s. This was a problem.
I came up with an answer, thankfully.
The Apple II was designed to read and write bytes of data to cards plugged into the eight free slots, and it could do that really efficiently. So I came up with a scheme to output 8 bits (that’s one byte) of data to the floppy controller, which would output those bits every four microseconds on its own, one bit at a time.
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 read
ing 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.
iWoz Page 20