Wednesday, October 19, 2011
Memories of my working with Steve Jobs
Vignette's of my working with Steve Jobs circa 1980 to 1982
Number Crunching Apple II hardware
I started at Apple as an Apple II peripheral designer. One of my first projects was to design the Super Serial Card for the Apple IIe, which was on the official Apple price list for around 1 decade, one of the longest Apple products ever in continuous production. During this time, all of Apple's engineering (for Apple II, III, Lisa, R&D, etc.) fit into one building. For my R&D portion of the job, I designed and built several prototype Apple I peripherals. One of the weirdest was a way to connect an Intel 8087 math coprocessor to share memory with an Apple II.
I thought it was great to show off that an Apple II could floating-point number crunch with the performance of a minicomputer. Steve walked over to my engineering lab bench, asked what I was doing. I told him. He then challenged "why would anyone want to need a personal computer to do that fast numerical computation"? I paused, a bit lost for words. He gave me one of those looks that I was just wasting Apple's time, and stalked off. Even if I was designing something destined to be a standard part of the future of personal computing, Steve wanted me to be able to clearly show why.
Joining the Mac Team
Burl Smith was the original Mac Hardware designer; but he first joined the Apple II lab as a hardware technician, with an engineering lab bench very near mine. During this time, we helped each other out by doing design reviews of each other's hardware schematics. Probably because I had worked with Burl, I later became the 6th or 7th hardware engineer to join the Mac team. Burl was the lead digital logic designer, Dan Kottke was wire wrapping prototypes, Ed Riddle had temporarily joined the team to do the keyboard controller, Hap Horn and George Crow were doing analog design. (And Brian Howard was officially supposed to be doing documentation, but might have actually spent more time helping Dan Kottke with building and testing the prototype Mac hardware.)
I originally was brought onto the Mac team to help Ed Riddle with the keyboard controller, but as soon as I moved over to Texaco Towers (Apple's skunk words location across the road from their main campus), I was assigned to help Wendell Sanders with a possible re-design of Woz's disk controller, later named the "Integrated Woz Machine" or IWM. The IWM chip, when finished, went into both the Mac and the Apple IIe.
Steve often came by Texaco Towers. I don't recall him saying too much about the hardware. I do remember his attention to detail regarding the case and keyboard design and the precise sizing of its chamfers.
I also recall him talking about a bet he made with the head of the Lisa project, circa early 1982, with him betting that the Mac would sell something like 10,000 units before the Lisa did.
Buying dinner at FJLs (Frankie, Johnnie, and Luigi too) Pizza
One night Steve came by the lab, saw that most people were working late and decided to take us all out for dinner. We drove over to a favorite late-night pizza restaurant in Mountain View, "Frankie, Johnnie, and Luigi too", better known as just FJLs. At the end of the meal, Steve threw down his credit card to pay. The server came back a few minutes later and told Steve his card had expired. To save Steve the embarrassment, I quickly gave my credit card to the waiter. So I ended up buying Steve dinner. Don't remember whether I ever tried to file an expense report for this bill.
Apple "leaked from the top".
The team occasionally had friends and other Apple coworkers visit us over at the Mac skunkworks site. I had my then girlfriend bring her Apple II into the Mac lab so that I could fix some problem with it. Soon thereafter, there was a management edict that the project was too secret to allow visitors. But within days of this edict, we found Steve showing off a Mac prototype to Joan Baez and her son. Later rumors were that they were dating. Steve even brought Joan to the office Holiday party later that year (where the San Francisco symphony was our musical entertainment for the night).
Color connecter on an early Mac prototype
After the Mac team had grown too big for the Texaco Towers skunkworks site, it moved back to a building in the main Bandley complex. On a lab bench there, next to mine, Dan Kottke was busy assembling and testing more Mac prototypes. On one Mac prototype Dan was adding a video test connector. Steve walked in one day and asked what Dan was doing. Dan told Steve that this test connector that could also be used to experiment with possible color video output. I overhead Steve say something like "Stop doing that. The Mac will not have a color option."
Atari-Apple-Amiga historical connection
Prior to Apple, Steve had worked at Atari. Also working at Atari at the same time as Steve was Jay Minor. According to Jay, Nolan Bushnell, who was strapped for cash flow at the time, had offered Jay 5 cents a chip, instead of a salari, to design the ASIC for what later became the Atari 2600 game console. Jay didn't think it would sell that well, but joined Atari taking a salari instead. The 2600 game console ended up selling millions of units. After the 2600, Jay also designed the chips for the Atari 400 and 800 personal computers. Jay later left Atari to help form Zymos, a custom semiconductor vendor. But Jay still wanted to design his own computers.
Early in the Mac project, when Burrell and the team were deciding that the Mac needed more than 64k of RAM, they decided that the Mac would need a CMOS clock chip that would keep time even when the Mac was unplugged. At that time, none of the existing solutions were suitable. So Steve introduced me to Jay, saying Jay was someone he knew from his Atari days, and one of the best chip designers around. He wanted us to explore whether Zymos could do the custom design and manufacturing for a CMOS clock chip, and later the integrated disk controller chip as well.
Jay later managed to talk the investors in Zymos into letting him leave Zymos to start a new computer game company, and Jay talked my into to leaving Apple to be the system architect and co-founder of Amiga game console. The Amiga product would be a game console and have a color output, therefore being very different from the Mac (with which I was extremely doubtful that any startup could compete). Later, Jay decided that the game console should really be a personal computer and have an optional monochrome display.
So that's one of the ways in which Atari, Apple and Amiga history is intertwined.
My signatures in the Original Mac 128K case
As part of the original Mac design team, I was at the signing party for signatures that were to become part of the texture moldings inside the back of the prototypes for the Mac case.
But I left Apple slightly over a year before the Mac was officially introduced, so I wasn't sure that my signature would get left in, even if Apple let the signatures actually go into the finished product. However, I attended the official Mac product announcement at the 1984 Apple shareholder's meeting; and Steve surprisingly came up to me and personally thanked me and told me that my name was inside the Mac. I think that was the last time I talked with Steve.
Sunday, July 24, 2011
Estimating iPhone App Store Sales From Rankings - update
Here's what the average daily sales graph might look like for the Top 1% to 10% in popularity of all paid iOS app (out of 270,000 paid apps in the App store).
See my April Musingpaw blog post for details on the power law equation used to estimate these sales. Note that any top 100 app is in the top 0.03% of all apps, which is thus way off the top left of the scale.
Wednesday, April 27, 2011
Estimating iPhone App Store Sales From Rankings
Estimated average daily sales versus popularity ranking for paid apps between the Top 10% and the Top 50% in App store popularity (out of 265k paid apps).
Everybody talks about the top apps in the iOS app store. But there's still a story to be told about the other 90%+ of apps. The story is that Apple is likely paying 100's of millions of dollars per year to these developers, but with that revenue spread incredibly thinly though a very long tail.
Ajnaware’s Weblog posted an interesting hypothesis about App store unit sales. The hypothesis is that sales, plotted against popularity rankings, follows a power law curve. This curve can then be integrated to get total app sales. Phenomena with long tails often seem to follow power law curves. So, given the long tail of around a quarter million paid apps in the iOS app store, a power law seems to be a quite reasonable starting hypothesis.
I used a tiny number of data points for paid apps, ones I've randomly heard about, spread across the entire App store, instead of just the top, and tried to fit my own power law curve to those points. I ended up with a vaguely reasonable fit using this equation:
Power law curves are very different from bell curves. There is no central tendency average. So asking other developers about the average number of sales to expect is fairly useless, because the mean is so far from the median. There seem to be no average apps, only a few winners and a huge number of losers, maybe with odds and payoffs more similar to a game of roulette than a predictable business opportunity for developing new apps.
(Graph and some commentary added on 2011-July-24)
Added 2012-July-26:
Here are some results from an iOS game developers survey, which show a similar revenue distribution curve: http://www.streamingcolour.com/blog/2011/09/28/results-ios-game-revenue-survey/
Everybody talks about the top apps in the iOS app store. But there's still a story to be told about the other 90%+ of apps. The story is that Apple is likely paying 100's of millions of dollars per year to these developers, but with that revenue spread incredibly thinly though a very long tail.
Ajnaware’s Weblog posted an interesting hypothesis about App store unit sales. The hypothesis is that sales, plotted against popularity rankings, follows a power law curve. This curve can then be integrated to get total app sales. Phenomena with long tails often seem to follow power law curves. So, given the long tail of around a quarter million paid apps in the iOS app store, a power law seems to be a quite reasonable starting hypothesis.
I used a tiny number of data points for paid apps, ones I've randomly heard about, spread across the entire App store, instead of just the top, and tried to fit my own power law curve to those points. I ended up with a vaguely reasonable fit using this equation:
unitSales = totalPaidApps * ((1 + rank) ^ -1.0) - 1.5with a steeper exponent of -1.0 instead of Ajnaware’s estimate of -0.75. (The carat symbol is old fashioned Basic syntax for the infix exponentiation operator.) I also ignore negative sales due to the small bias subtracted from the curve. The curve fits thousands of sales per day for a top 100 app, 100's of sales per day for a top 1000 app, but less than 10$ per day for apps below the top 15%, and less than 1 sale per day for the median or 50th-percentile popularity app. Given 265,000 total paid apps, this curve integrates to almost 3 million paid app sales per day, or over $140M in app sales per month if the average app price is $1.65. So my guess is that this equation is at least correct within an order of magnitude.
Power law curves are very different from bell curves. There is no central tendency average. So asking other developers about the average number of sales to expect is fairly useless, because the mean is so far from the median. There seem to be no average apps, only a few winners and a huge number of losers, maybe with odds and payoffs more similar to a game of roulette than a predictable business opportunity for developing new apps.
(Graph and some commentary added on 2011-July-24)
Added 2012-July-26:
Here are some results from an iOS game developers survey, which show a similar revenue distribution curve: http://www.streamingcolour.com/blog/2011/09/28/results-ios-game-revenue-survey/
Tuesday, April 26, 2011
iPhone programming - How to play a tone at a given frequency
Many novice developers expect some sort of way to play a simple tone of a chosen frequency, maybe using an API similar to playTone(someFrequency, someDuration). However, nothing like this is available in the stock iOS SDK frameworks.
It's easy to generate sine waves if one understands sampled sound. The most common sample format is 44100 samples per second, with each sample being a signed integer between -32767 and 32767. If one could push samples to the iOS audio system, it would look like this:
However, iOS and Cocoa Touch use the event driven design pattern. An app can't push samples to the audio system. Instead, the audio systems asks you for some number of samples when it is good and ready. Your app just sets up the audio and waits to get called. Here is an example RemoteIO audio buffer callback:
Note that the above code snippet doesn't show where variable a, the phase, is initialized. The phase angle a should be saved between callbacks so that there is no discontinuity in the sinewave phase between each audio buffer. I'll leave that here as an exercise for the student.
I used to question including the call to the transcendental function sin() inside a audio inner loop as something far too slow for an audio callback. But a little benchmarking on an actual iPhone showed that calling the single precision sinf() for every audio sample actually uses less than 1% of the CPU time, and really isn't that much slower than something like an interpolated wave table lookup.
If you don't know how to set up the RemoteIO Audio Unit to call your app, here's a blog article on Using the RemoteIO Audio Unit (by Michael Tyson at Tasty Pixel), and here is Apple's Documentation on the RemoteIO Audio Unit. Don't forget to set up a suitable audio session for your app as well, using the iOS Audio Session APIs.
It's easy to generate sine waves if one understands sampled sound. The most common sample format is 44100 samples per second, with each sample being a signed integer between -32767 and 32767. If one could push samples to the iOS audio system, it would look like this:
len = secondsDuration / sampleRate; for (int i=0; i<len; i++) { sample = volume * sinf(2.0*M_PI * i * myFrequency/sampleRate); sendToAudio(sample); }
However, iOS and Cocoa Touch use the event driven design pattern. An app can't push samples to the audio system. Instead, the audio systems asks you for some number of samples when it is good and ready. Your app just sets up the audio and waits to get called. Here is an example RemoteIO audio buffer callback:
float f = myDesiredFrequency;
float v = myVolume; // in the range 0.0 to 32767.0
float sr = sampleRate;
float a, da;
int b, n;
short int *p;
a = ...
da = 2.0 * M_PI * f / sr; // delta phase per sample
for (b = 0; b < ioData->mNumberBuffers; b++) {
// number of 16 bit packets in each buffer
n = ioData->mBuffers[b].mDataByteSize / 2;
// pointer to sample buffer
p = (short int *)ioData->mBuffers[b].mData;
for (int i = 0; i < n; i++) {
p[i] = v * sinf(a); // single precision
a = a + da; // update phase
if (a > 2.0 * M_PI) {
a -= 2.0 * M_PI; // and range reduce
}
}
}
Note that the above code snippet doesn't show where variable a, the phase, is initialized. The phase angle a should be saved between callbacks so that there is no discontinuity in the sinewave phase between each audio buffer. I'll leave that here as an exercise for the student.
I used to question including the call to the transcendental function sin() inside a audio inner loop as something far too slow for an audio callback. But a little benchmarking on an actual iPhone showed that calling the single precision sinf() for every audio sample actually uses less than 1% of the CPU time, and really isn't that much slower than something like an interpolated wave table lookup.
If you don't know how to set up the RemoteIO Audio Unit to call your app, here's a blog article on Using the RemoteIO Audio Unit (by Michael Tyson at Tasty Pixel), and here is Apple's Documentation on the RemoteIO Audio Unit. Don't forget to set up a suitable audio session for your app as well, using the iOS Audio Session APIs.
Thursday, April 21, 2011
HotPaw Productions Announces Music Spectrograph for iOS
Santa Clara, CA - HotPaw Productions announces Music Spectrograph 1.0, now available from Apple's iTunes App store. The Music Spectrograph piano-roll-style music visualization will help anyone learn more about the music they hear, using their sense of vision as well. This iOS app uses real-time signal processing on audio from the microphone input to display a scrolling 12th-octave spectrogram, with each band centered on a musical note. Visualize speech and singing. See musical notes (plus all their overtones) graphed like a piano roll to assist with music transcription.
The app can be used for speech therapy, music education, vocal training, learning to sing on pitch and in key, finding which notes are hidden inside chords, or just watching the rise and fall and the pitch and overtones within the sounds around you.
Mrs. Nicholson says: "Wow, that's a really cool looking app. What's it do?". The developer's cats just looked at the app and went back to napping (as it obviously wasn't a mouse or a bird).
Ron Nicholson founded HotPaw Productions in 1999, first developing mobile apps for PalmOS devices, and has been developing iOS apps since the App store first opened. There are over 20 iPhone and iPad apps developed by HotPaw Productions the iOS App store, including the inTuna Strobe Guitar Tuner, Sing-inTuna, and HotPaw Basic. Copyright (C) 2011 HotPaw Productions. All Rights Reserved. Apple, iTunes, iPhone and iPad are registered trademarks of Apple Inc. in the U.S. and/or other countries.
###
Ron Nicholson
Developer
rhn@hotpaw.com
The app can be used for speech therapy, music education, vocal training, learning to sing on pitch and in key, finding which notes are hidden inside chords, or just watching the rise and fall and the pitch and overtones within the sounds around you.
Mrs. Nicholson says: "Wow, that's a really cool looking app. What's it do?". The developer's cats just looked at the app and went back to napping (as it obviously wasn't a mouse or a bird).
Ron Nicholson founded HotPaw Productions in 1999, first developing mobile apps for PalmOS devices, and has been developing iOS apps since the App store first opened. There are over 20 iPhone and iPad apps developed by HotPaw Productions the iOS App store, including the inTuna Strobe Guitar Tuner, Sing-inTuna, and HotPaw Basic. Copyright (C) 2011 HotPaw Productions. All Rights Reserved. Apple, iTunes, iPhone and iPad are registered trademarks of Apple Inc. in the U.S. and/or other countries.
###
Ron Nicholson
Developer
rhn@hotpaw.com
Wednesday, April 13, 2011
HotPaw Website Major Update
The HotPaw website has been completely updated, with new css, and a new 3-column look. Many thanks to lizdesign for the web site design and many of the icons, including:
Subscribe to:
Posts (Atom)