Micro-Computer Design, Then and Now
(Thoughts About the Apple II Software Architecture)

Recently I pulled my old Apple II down out of the attic in order to build the " The Super D'Lux Shutter Tester ".  As I worked on the project,  it became quickly apparent how far micro-computer design has come over the years.   The microcomputer design philosophy has evolved tremendously over the years.   I figured I'd share some of my thoughts regarding the amount of this change with you on this page.

First of all, the Apple II, is surprisingly straight forward, really primitive if a better description.  These days, all proper software designs are implemented through API's, so that lower layer code can be changed and fixed without affecting the upper layers.  The Apple II firmware has no proper API at all.  Calls to ROM functions are made directly,  using well known addresses.  These days, this is called using magic numbers, a practice to be avoided at all costs.  In effect, the programming model of the Apple II is flat, with no hierarchy at all.    Even the routines within the BASIC interpreter can be called directly, if they perform some useful function that can be used elsewhere!

Secondly, the Apple II is amazingly efficient in utilizing memory.  My original machine contained a monitor,  debugger, basic interpreter, video ram,  I/O drivers and a small application in 8k of ROM and 4k of RAM. When more memory and a disk drive is added,  you are still left plenty of room for an application program.  This machine's software is really a masterpiece of space efficiency.   Another interesting affect of this design is the instant booting.  No waiting minutes for this machine to boot up, even to get an application loaded is well under a minute.

Programming in BASIC is painful for someone used to more advanced, modern, unix based tools.  When I was first learning mini-computer assembly and Fortran, I actually preferred using the Apple II and BASIC.  It took me quite a while to understand the modern concept of a driver, as the Apple II really had no such API.  Now I'm convinced that learning programming on the Apple II must have set back my career a few years!  After all, it took time to forget all of those bad Apple II habits before I could write some proper code for a real machine.  Perhaps that is why I spent the first years of my career working on firmware where those bad habits could be useful knowledge.

Though the system is primitive, it is relatively easy to write simple applications.  Hardware drivers are absolutely a piece of cake.   Since there is no concept of a driver or memory protection, you just do whatever you want or need to do.   There are a couple of gotcha's though.   Trying to use zero page memory, is a bit trying, since many locations are blocked off for use by BASIC or the monitor.   With research though, you should be able to find enough free locations to get the job done.  Mixing assembly with Applesoft took me a bit of time to get working, but I eventually got it.

Overall, it was fun to revisit the past and invent something new (the shutter tester), using this old technology.  In many ways I think it is not that much different than using modern single chip micro controllers like the PIC, 8051, or AVR machines.  One difference is that those machines don't include much support for human interface and storage devices.  A company called the Western Design Center is currently selling micro controllers with an embedded 65C02 microprocessor.  It makes me wonder if someone could license some technology from Apple and make some money by putting an Apple II on a chip with a fast 6502 and sell it as micro controller?






Back to Mike's Hobby Home Page