When I restored my Apple II back in 2008, one of the things I did was to remove a modification I had made back in the late 1970s.

This was a change that I had made in order to work around a very annoying feature of the Apple II. The reset switch was located right next to the return key and was not gated by any other keys or logic. If you were typing on the keyboard and attempted to hit the return key and accidentally hit the reset key by mistake, you would reset your computer. My fix back in the day, was to put a toggle switch in series with the reset key that would disable or enable it. Here is a picture of the switch in 2008 after it was pulled and with the mounting hole filled with modeling putty.

Reset Switch Being Pulled

Over time, I realized that the reset mod was part of the history of the computer and should have been left in place. I came to this conclusion quite a number of years ago. This morning, I finally went ahead and put the toggle switch back in. This is same exact switch that I pulled out of the machine in 2008.

Sometimes being a pack rat, pays off. I was even able to find some of the same green wire that I had used to wire the switch back in the late 1970s.

Old Green Wire

The reinstallation wasn’t without difficultly, though. After reassembling the machine, I couldn’t get a reset to “take”, at all. Turns out that the reset key itself had decided it didn’t want to function. I disassembled the machine, and flooded the key with isopropyl alcohol. That did the trick and it came back to life. While I had the machine apart, I also flooded the control key, which has been giving me trouble for a number of years. Since the machine has been sitting for quite a while, a few other keys need some coaxing, but they all came back to life.

When I originally did the job, I didn’t label the switch, and often forgot which position was which. This time, I decided to label it. In retrospect, I should have used a normally open, momentary switch, which in effect, would have worked the same way as Apple’s control-reset solution. I didn’t think of that back in the day, so I decided to reinstall the same old switch with the addition of those descriptive labels.

Reset Enable Switch

I have made available Apple II rev 0 reproduction gerber and CAD files freely available for download. I actually put these files online a little while back, but didn’t make any announcement. I’m making this announcement, so that people will be more aware of the increased possibility of reproductions being passed off as original units. I.E. the possibility of fakes is increased.

Here is the link:http://www.willegal.net/appleii/A2rev0.zip

I believe that several people may already be making some new Apple II reproductions using these CAD files. If you are interested in having one, your best bet would be to make some queries in the more popular forums.

The CHM’s youtube channel has this video, which caught my attention.

https://www.youtube.com/watch?v=3Z8XrC3kLJM&index=8&list=PLQsxaNhYv8dZMhpT8-934UPMdtho7G2_W

I’ve always been an advocate for the behind the scenes “little guy” that do 90% of the work that really make new products possible. My mom taught me, when I was little, that “words are cheap”. The same can be said for the new ideas that lead to breakthroughs in technology. There is always a foundation for these new ideas and they usually aren’t giant leaps, by themselves, but almost always, incremental steps in understanding.

In my mind, the hard part, isn’t coming up with the idea, but implementing it. In fact, many products are described decades before they can be implemented.

The stories on Andy Hertzfeld’s folklore.org website, demonstrate the hard work that goes into implementation, as well as anything that I’ve ever seen. The thing to understand is that the effort that went into making Macintosh, isn’t unique, but rather the norm for almost all of the gadgets that we take for granted, these days. How do I know this, you may ask? Well, I’ve been involved in new product development for something like 38 years. Some of the products that I have worked on have been failures, but many of them, successful. In either case, it’s always a struggle for those involved. A rewarding struggle when it goes right, but still a struggle.

It seems Thomas Haigh understands this. I’ve ordered his book on Eniac and will write a review after I read it.

Thomas’ comments on Isaacson’s book “The Inovators”, made me pull out Isaacson’s book, “Jobs” and review the sections on Apple 1 and Apple II. I think I understand those products and what went into making them, very well. Thomas’ comments made me want to review the book for faults. I knew that Isaacson had Job’s and Wozniak soldering Apple 1’s, which was incorrect, but wondered what else I would find, if I reviewed those sections. Before I comment on what I found, I will say that I greatly respect anyone that can write such an engaging book, as I don’t have the patience or talent to do it.

Here are the mistakes I managed to find during a quick review of those sections.

Though there are no real mistakes with the Apple II section, there are, in my mind, serious omissions.

I understand why Isaacson, in his story, emphasized Job’s interaction with a number of significant personalities. It is a shame that the struggle to develop a new product by a team of talented engineers gets so little “ink”. I also wonder how accurate the depictions of the interactions between the significant personalities really is. It seems that, in terms of the technical stuff that I understand pretty well, Isaacson would grab a fact and elaborate upon it, kind of putting his spin on it, without doing serious fact checking.

In any case, it’s an entertaining read, that I recommend, in spite of the errors and omissions.

During the Apple/Homebrew reunion, having never met him before in person, I briefly introduced myself to Woz as the guy that makes those Apple 1 clones that he always signing. He said, “nice”. He was surrounded by a crowd of people, so I let it be at that, and moved on. At least I had introduced myself.

Later on, as I was talking to Daniel Kottke, whom I have known for several years, Woz came over and joined us. We talked about that small change that he thought could add a color to the Apple II. I mentioned that I tried to make that change, but couldn’t make it work, right. He said he knew that. I was a little surprised by this reply, since I don’t think I ever reported that I had spent time experimenting making that change, but failed to make it work well. Maybe, I had emailed him my results and then forgot about it, I don’t know.

Woz also talked about a change he thought he could have made on the Apple II, that would have saved a chip, but required more complicated software in order to implement video support. I’m not sure what that change would be, but I’m thinking that creating an incompatible Apple II to save a chip isn’t anything I’ll be working on, at least in the near future.

Woz talked about the video system on the Apple 1. He says he copied it from some terminal product, clearing up that point, once and for all. Part of this video system has a rather complicated state machine that implements the carriage return logic. Woz admitted to Daniel and I, that he never understood that logic. In return, I admitted that I never understood it either. Actually, I was probably being a bit humble, as I understand the concept of that circuit, but never completely understood the details of the implementation. I expect he was saying the same thing.

Woz finally mentioned that there was one part of the Apple II design that didn’t meet timing specs of the chips. He then said that he knew it, but never told anyone. He was counting on the conservative specs of the chips involved from turning this timing violation into a real problem. I think that he was right, as I have never heard of any timing issues on the Apple II, actually causing problems.

I wonder if Daniel and I were the first to ever hear this confession, as I don’t recall hearing about it, before. Anyway, this confession reveals some of the difficult decisions that design teams, even the best, have to deal with on a daily basis. Sometimes these sorts of decisions come back to haunt us, and sometimes they don’t. The reason that engineers sometimes hold back on reporting latent issues, is that openly reporting issues may cause endless debate within the design team and possible delays on the project. I’m sure that Woz would have reported it, if he thought it was going to be a real issue.

By the way, I don’t advocate holding back information from your boss, I’m just saying that it does happen and why.

Meeting Woz in person, was a real pleasure. He is a great guy, exactly the same in person as when on stage or virtually, via email.