Comment from E-mail:
I am a huge Apple fan, favoring the old Apple //e. I'd really like to own an Apple computer, but due to the cost, I can't. Why do Apple's cost $3,400 or more, when I can pick up an IBM for around $400???
Woz:
We just give you more for the buck than PC clones, that's all.

Comment from E-mail:
My name is Michael C. Barnes. I read the first Popular Electronics Magazines about personal computers while I was in the Army. I never thought that this would lead to a career. It just looked like something that would be really cool. I used my GI Bill and signed up for a Digital Industrial Electronics Course and a CREI Microprocessor Technology course. I was consumed by my hobby.

I think that it was 1978 or so, I saw the Apple computer at the first Computer show that I went to in Washington, D.C. Almost every booth had an Apple or some CPM machine. At that time, I was astonished by the graphics. I remember thinking that they looked like cartoons.

I was reading articles that had your name and Steve Job's name. I felt that I was left behind. I even felt that I was an under achiever because you guys were building an industry and I was simply serving my country.

When I got out of the Army, I went into Government but left because I simply felt the call of computers.

I was out trying to find a way to make money in computers about 1980. At that time, the only computers were Atari, Apple, and a bunch of CPM machines. I worked in a store that sold audio, video and computers. At this time, everyone in the industry was doing it as a hobby. I think everyone was simply having fun.

I finally got into the industry professionally working for Burroughs. The person that hired me now runs all of the Americas for Sun. He told me that when he me me, he instantly realized that the indsustry was changing and there was a new generation of computers emerging. He said he never heard anyone talk about computers the way I did and hired me simply because he felt that not hiring me would cause him to fall behind.

Four years later, I was at Sun Microsystems. All this time, I felt that I was in the shadow of people like you. I never believed I could make it rich or make a name for myself simply working for someone else.

Over the years, the industry has changed. By simply working for Sun and buying their stock, I became a millionare. I wound up in Thailand. I started my own company based on a loudspeaker design I came up with. I am now creating amplifiers and audio equipment -- as a hobby. I get more recognition for this than anything I have ever done.

At 46, I am finally at piece. I think that I did okay and that I don't need to feel that I didn't meet my potential. My family is secure. I love my work. I have invented something.

Thank you for setting the bar high. I believe that my modest success is in due part to the early success that pioneers like you had. I think you made it easy for late comers such as myself.
Woz:
Your story probably means much more to many more people than my own. We, and the way we started Apple, were the rare exception, and not what people should be taught to expect. But your story is more real and an example of just plain wanting to be in the industry and making sound decisions that did well for you. The best thing is that you say you are at peace. Not everyone could do what we did with Apple, but everyone should see themselves capable of your sort of success.

Thanks for sharing this fine story with me.

Comment from E-mail:
Just saying thanks for the concerts that you held at Glen Helen Park in Devore. Really were enjoyable. Wishing you al the best, Frank Guidi
Woz:
I'm glad that almost as many people email me to say how they enjoyed the US Festivals as email me with thanks for starting Apple.

Comment from E-mail:
I have emailed you before, and i got so excited that a major player in the computer world awnsered me. So here goes my question. My friend and I want to make our own computer soft ware, We bought an old computer and scraped it, and made a new computer, but we want to make our own operarting system, You said you made basic for the Apple 1 and II. What did you us to make it? what type of soft ware, if any would we need to make it with, and is there any hard ware we might need?
Woz:
I don't know if these comments will apply, but here they are.

In high school I fell in love with minicomputers, which were basically small computers equivalent to the microprocessors once they came out. Well, I could never afford a minicomputer but I looked at the programming instructions for machine language and tried to write my own short routines. In college I started trying to figure out how compilers, like Fortran, were written. I knew that the compiler program had to read a line at a time and figure it out and convert it to code that the computer could run. So I started writing a routine in assembly language (machine language) that would analyze a line for correctness. But I never could afford a computer to try it on, nor an assembler to type it into. It was just a personal program that nobody else knew about.

After I'd designed a computer, before Apple was even conceived, I decided to write a BASIC for real. I'd never studied how to do this, but I had self trained myself a bit back in college as I described above. I'd never used BASIC but I knew that this was the popular language for games and that was too important to ignore. The first thing I did was get a BASIC manual at Hewlett Packard, where I was working. I read it and made notes and pretty much learned what commands it had. Of course this was Hewlett Packard BASIC. It differed from the Digital Equipment BASIC, that Bill Gates' first BASIC was based on, mostly in some string manipulation. This later turned out to be the greatest difference between my BASIC and theirs. I was tired of MID$, LEFT$, RIGHT$ type functions so I preferred the HP BASIC better (A$(5,7) meant the 5th through 7th characters of A$).

I'd never formally educated myself in the area of compilers and interpreters (compilers translate a program to machine code to run rapidly later, interpreters scan the program and figure it out as it's being run, which results in much slower execution--BASIC is an interpreted language). But I knew how Syntax charts defined the structure and words of a programming language, as you find these in programming manuals. I decided to write down a full Syntax description of my BASIC to begin. I'd never done such a thing, but it wasn't hard and was modeled after others that I could find.

I next decided that I'd actually put this syntax list into memory as part of my BASIC interpreter. It was stored character by character. I figured that I'd just scan the input line, after the user hit Return, character by character, tracing a path through the syntax table and backing and retrying things. If the line made it through the Syntax table then it was good, otherwise it was in error.

The unexplainable part is how I came up with the way my BASIC would actually do what it was supposed to. As BASIC elements were found in the Syntax Table, I generated tokens (codes) for these elements. For example, a left parenthesis might generate token #87. But in another usage, a left parenthesis might generate token #115. It depended on where it was encountered in my Syntax table in memory, the one I was traversing character by character and matching the input line. In an inefficient effort to make my BASIC very tiny and save every possible byte (even the minimal amount of memory for a computer language was very expensive in 1975) I actually counted how many BASIC symbols the 'matched' one was from the start of the syntax table, and used that count as it's token value.

After this step, I generated a line that didn't have to go through the Syntax evaluator again. The Syntax evaluator could be very tiny and run slowly, as it only ran once per line, which took only a fraction of a second for a typical line. When the program ran, it was already half in shape for speed.

Now comes a less explainable part. I had read and heard some things about compilers but I still don't know to this day if what I did was good or bad. As a line executed in a running program, it consisted of numbers (precompiled into constants I think) and variable names and grammar elements like a plus sign token or a left parenthesis token. When, during execution, the BASIC encountered a 'noun' (number or variable) it was pushed onto a noun stack, ready for retrieval. This was like our HP calculators where I worked.

When the BASIC encountered a 'verb' (a token that called for an operation) it would be evaluated in comparison to a verb stack. This was the way of reading a human-written expression from left to right, but doing the operations in a different order (2+3*4 does the multiplication first in most computer languages, even though the plus sign appears first). For each token I assigned 2 priorities. One was the priority to push preceding tokens off the stack for execution. For example, 3 + 7 * 5 would push 3 on the noun stack, + on the verb stack, then 7 on the noun stack (where it's ready to be the first element removed from this first-in last-out stack). When the * is encountered, it had a higher execution priority than + so it didn't pull the 7 and 3 off and add them yet. Instead it pushed the * onto the verb stack and then the 5 onto the noun stack. The end of line was a token with priority to push everything off.

So at this time the * is the 'topmost' token on the verb stack. It comes off and runs a prewritten multiply routine that pulls two items off the noun stack, adds them, and pushes the result back on that noun stack.

Any token that causes others to be executed immediately off the verb stack would keep looking at token priorities until it's own priority was such that it would merely be pushed onto the verb stack and await later execution.

Parentheses bring another factor into play. A left parenthesis is always pushed onto the top of a verb stack, hiding the execution priority of the preceding operator token until a right parenthesis, with extremely high execution priority, causes all tokens to be executed until the left parenthesis is encountered. At that time the right parenthesis has found it's mate and stops forcing ops (tokens) to execute. This is a sort of exception to the concept of a single priority. In addition, the left parenthesis forces no ops off the verb stack, acting as though it has extremely high priority. But no ops force it off, until the right parenthesis, as though it had an extremely low execution priority. So I actually had two priorities for each token, a 'push' tendency and a 'pull' tendency. A verb (token) would only push other verbs off the verb stack and execute them if it's push priority was greater than their pull priority.

I have no idea where these sorts of ideas came from. They just came to me as I needed an elegant solution.

A table held bites with 2 one of zixteen priorities for each token that might be in the interpreted BASIC program. Another table held an address pointer for each token, that pointed to the routine to run when that token was forced to execute. So for each of the dozens of tokens, I had to only write a short routine. This kept the program less complicated and easier to add new commands to.

I couldn't afford an assembler. I wrote the entire program on paper, assigning memory addresses for each program instruction. When I shortened a routine, it was too much trouble to re-write (by hand) a few K-Bytes of code just to shrink the space. So there were many cases of short empty spaces in my BASIC. When a routine needed to expand, I'd usually jump to a patch area where it's latter part was. None of this would have happened if I could have afforded an assembler, which would have packed things properly.