folklore.org
Home | About Folklore
The Original Macintosh:    22 of 31 
3rd Party Developers and Macintosh Development
Author: David Craig
Date: January 1984
Characters: Steve Jobs, Andy Hertzfeld, Steve Capps, Bill Atkinson, Bruce Horn, Tom Malloy
Topics: 3rd party developers, Lisa, Software Design, Technical
Summary: Some Comments about Developing Applications for the Apple Macintosh 128 Computer from a 20 Year Perspective

Some Comments about Developing Applications for the Apple Macintosh 128 Computer from a 20 Year Perspective



OVERVIEW

This commentary contains my recollections about developing 3rd party software for the Apple Macintosh computer during the years 1984 to 1986. This paper was written as my contribution to the Macintosh's 20th anniversary celebrations in February 2004.

During this time I worked for a small company in Wichita Kansas called PPP Inc. (PPP or P3 = Programs for Professional People) which developed a new Macintosh application for the stock market named The Investor. This application was written in Lisa Pascal and contained around 50,000 lines. I and another individual designed the program, I implemented it.

The original Macintosh (called the "Macintosh 128" since it had 128K bytes of memory) provided a fascinating development and application environment which I enjoyed immensely. The Macintosh's rich ROM-based software toolbox in a 64K byte ROM along with the machine's small footprint and superbly clear screen display made the Macintosh a wonderful application platform.

SOFTWARE DEVELOPMENT USING THE LISA WORKSHOP ENVIRONMENT

Macintosh development in the early days (circa 1983-1985) was done using the Apple Lisa computer and its Lisa Workshop development environment. I originally used a Lisa 2/5 model which contained 1M byte of RAM, an internal 400K 3.5" Sony floppy drive, and an external 5M byte ProFile hard drive (yes, 5M as in mega bytes was considered a rather large drive in those days). I later used a Lisa 2/10 model which had an additional 10M byte internal Widget hard drive which gave me a total of 15M bytes of hard drive storage.

The Lisa Workshop hosted a command line interface which accessed a wonderful mouse based editor, a Pascal compiler, a 68000 macro assembler, an object file Linker, the RMaker resource compiler utility program, and the MacCom Lisa-to-Macintosh utility communications program.

The Lisa Pascal language was very powerful and compiled Pascal source files to Motorola 68000 object code files. I never found a need to use the Workshop's 68000 assembler since everything I needed for my application could be written in the higher level Lisa Pascal language. Macintosh application resource information was created as text files which were then compiled to a binary format using the RMaker resource compiler. Transferring a Macintosh object program from the Lisa to the Macintosh required the Lisa utility program MacCom which copied Lisa files to a Macintosh formatted disk in the Lisa's 400K internal disk drive. MacCom combined separate Lisa data and resource fork files which were stored on the Lisa's hard drive and stored them as single documents on the Macintosh floppy.

Macintosh programming was based on a collection of programming libraries called "units" in Pascal parlance. These resided on the Lisa and implemented the Macintosh application programming interface (API) called the Toolbox and Operating System by Apple. These libraries came on Lisa formatted disks called the Lisa Macintosh Supplement. I recall receiving around 3 or 4 supplements each with around a half dozen disks with these libraries. These disks also contained Macintosh utility and sample applications such as the Uriah Heap desk accessory by Andy Hertzfeld (called desk ornaments in the early days), the Edit text editor, and the File application by Cary Clark which showed detailed examples of Macintosh programming.

Macintosh development using a Lisa 1 model was also possible though I never worked with the Lisa 1. For this computer, which did not contain an internal Macintosh compatible 400K byte floppy drive, you transmitted your Macintosh program from the Lisa to the Macintosh via the Lisa's serial using a special Lisa utility. A special Macintosh utility received the transmitted file.

Macintosh development was also done using the Lisa Monitor development environment, but I never used this (I actually did play with the Monitor one time but thought the Workshop was a better environment). The Monitor was the Workshop's predecessor and was also command line based though its command structure was more UCSD p-system based then the later Workshop command structure. I was told that some people at Apple preferred the Monitor to the Workshop since the Monitor compilation and assembly was faster (specifically, Bill Atkinson and MacPaint and the Macintosh Finder team, Bruce Horn and Steve Capps). I've also seen Workshop references in Apple Macintosh source code to the "porkshop" but think this was somewhat unfair.

Around later 1984 or 1985 Apple provided the Macintosh Development System (MDS) which ran on the Macintosh 512K model I recall (I believe the Macintosh 128 couldn't run MDS but may be wrong). This allowed you to develop 68000 assembly language programs on the Macintosh. I never used it since I didn't write in assembly language (too tedious) and I had a Lisa with the Workshop and its wonderful Lisa Pascal language.

Concerning the Macintosh Plus computer which debuted in 1986, this computer was the last Macintosh whose system software was developed by Apple using the Lisa computer and its Workshop environment and the Lisa TLA 68000 assembler. Future Macintoshes were developed using Apple's MPW environment.

Note that the Lisa Workshop also supported a C compiler around 1985, but very little Macintosh development used Lisa C.

SOFTWARE DEVELOPMENT USING THE MACINTOSH MPW ENVIRONMENT

I used a beta version of the MPW (Macintosh Programmer's Workshop) programming environment around late 1985 early 1986 for Macintosh development. This was Apple's successor to the Lisa Workshop which was being discontinued since the Lisa hardware had been discontinued in 1985.

MPW ran on the then new Macintosh Plus computer which contained 1M byte of RAM and an internal 800K byte 3.5" floppy drive. I recall using an external floppy drive for my MPW development of The Investor application which worked fine, but compiles were much slower than the Lisa Workshop compiles.

MPW was a very good development environment which I still use today (it now is up to version 3.4 or 3.5 I believe).

MACINTOSH TOOLBOX AND OPERATING SYSTEM API

Macintosh programming was based on the Macintosh application programming interface (API) called at that time the Macintosh Toolbox and Operating System routines. There were around 500 of these routines in the original Macintosh. As a comparison, I just counted the number of routines in the Macintosh API MPW 3.2 Pascal interfaces from 1990 and there were around 2,300 routines (almost 5 times as many).

The Macintosh API introduced (at least to me) new programming topics such as event based programming, resources, and internationalization of text, numbers, and dates.

One idea that the Macintosh API attempted to teach developers was that the Macintosh was really a software system and not a hardware system. Prior Apple systems (the Lisa excluded) such as the Apple II and III families were more hardware oriented and minimal API information existed. Instead of writing data to a memory location for screen displaying, you instead used the QuickDraw graphics library. Apple wanted Macintosh developers to use the Macintosh API extensively since it already provided most of the core features of applications, ran fast, and was well documented. API usage also tended to promote a standardized user interface which really did not exist for Apple's earlier Apple II and III computers.

The Macintosh Print Manager was a joy to use. It provided a device independent architecture for printing really nice looking text and graphics. The old days of sending printer specific control codes to a printer and hoping for the best were at an end.

The Macintosh Memory Manager and its use of double indirect memory references called handles was an eye opener. This handle architecture provided a simple way to maximize the use of the Macintosh's limited memory size when memory blocks needed resizing; the Macintosh team has to thank Tom Malloy of the LisaWrite word processor team for this (see Hungarian).

INSIDE MACINTOSH

The Macintosh API was documented in a wonderful collection of notes called collectively "Inside Macintosh". Originally distributed on a chapter basis these eventually were collected in several volumes. Each chapter documented a specific Macintosh API "manager" such as the Menu Manager. Volumes 1 to 3 from 1984-1985 documented the original Macintosh API information. Volume 4 from 1986 documented the Macintosh Plus and the API changes made for this machine (such as the new SCSI disk manager). Volume 5 from 1988 documented the Macintosh II and its extensive API additions (such as Color QuickDraw).

The early Inside Macintosh chapters also contained API features which were later removed by Apple. For example, the Core Edit manager supported styled text and was a superset of the simpler TextEdit manager. Core Edit was documented in a 1982 or 1983 Inside Macintosh chapter, but was removed from the 1984 Inside Macintosh. Core Edit was used in the original MacWrite word processor.

Inside Macintosh was from my perspective very well written and provided in a very readable fashion a structure which made understanding the Macintosh API much easier. Inside Macintosh's structure was designed from the beginning and all the chapters had the same appearance and readability even though they were written by many different people. Caroline Rose was the key person behind the original Inside Macintosh chapters. She was ably assisted by around a half dozen writers.

Technical notes were also provided as part of the early Inside Macintosh releases. I recall a note from Bill Atkinson describing the internal format of MacPaint documents (he was responsible for the wonderful drawing application MacPaint, the QuickDraw graphics library, and the HyperCard user-oriented "software erector set").

Actual Macintosh system programming sources were also provided as examples. These included all the Macintosh "definition procedures" which implemented features such as window and menu appearances (Andy Hertzfeld wrote these). The sources for the more interesting ROM managers such as the Window or Menu Managers was alas not provided (maybe today, how about it Steve Jobs?).

The User Interface Guidelines chapter was in my opinion the most innovative area in Inside Macintosh. This provided a description of the Macintosh's ideal user interface and a rationale behind the decisions.

Compared to the later book-based Inside Macintosh information that Apple produced around 1990, the original chapter-based Inside Macintosh information was for me more readable and concise. The later material tended to be wordy and overly simplistic.

LISA MACWORKS

In 1984 and 1985 Apple supported the Macintosh operating system on the Lisa. This system was called MacWorks and allowed most Macintosh applications to run on a Lisa 2 computer. MacWorks booted the Macintosh OS from a single 400K floppy disk and even displayed the standard "happy Macintosh" boot icon. I recall MacWorks running well as long as the applications you used were well behaved (my Macintosh application The Investor was).

EARLY MACINTOSH DEVELOPMENT DISAPPOINTMENTS

Though the original Macintosh provided a revolutionary user interface and application programming interface (API), there were some disappointments from my perspective.

Programming the Macintosh took a long time. Instead of having an application interface consisting of a simple command line interface whose output was a bunch of text lines in a fixed size font, you instead had to manage menus, multiple windows, resources, and events.

Apple could have developed higher level API routines which would have lessened some of the 3rd party development work. For example, in addition to the TextEdit manager, the Macintosh ROM would have contained a TextEdit tool which would have displayed and handled multiple text windows. Unfortunately, this would have required additional programming resources on Apple's part and possibly a larger ROM (say 128K instead of 64K bytes). This type of problem was later solved to some degree by Apple's MacApp object oriented environment but that was many years down the road from 1984.

Sophisticated Macintosh applications required more resources than the Macintosh 128 provided. The original Macintosh's 128K bytes of memory and 400K byte disk drive were on the small size when it came to sophisticated applications (I recall reading that even in Apple there was lots of discussion about this). The original Macintosh was really around a 90K byte memory machine since the screen took 22K bytes of memory and a bit of memory was devoted to system code such a ROM patches and file system buffers. I recall my Investor application was around 200K bytes in size and though it ran on the original Macintosh it was slow due to constant application code segment swapping. The Macintosh 512 ran our program well. It is a shame that the original Macintosh didn't have a bigger memory (I recall reading about a 256K Macintosh) and more disk space (the Macintosh originally used a Lisa 860K byte 5.25" Twiggy floppy drive which would have been wonderful, but in late 1983 Apple changed to the 400K byte 3.5" Sony micro-drive).

From a programming perspective, the Lisa Pascal language was good, but it could have been better. For example, routine and variable names were significant to only 8 characters. This meant that the names such as FlushBuffersNow and FlushBuffersSoon were seen as the same name, FlushBuf, by the Pascal compiler. Apple should have changed the compiler to support at least 16 character name significance, or even better 32 characters. 8 character significance was a real pain for me and reminded me of Apple's Apple II and III Pascal compilers. This naming limitation also caused the Macintosh API routine names to sometimes be very abbreviated.

Macintosh API routine names should have been named to indicate their origins. For example, I thought all Event Manager routine names should have started with EM or EM_ such as EMGetNextEvent or EM_GetNextEvent . This would have at least provided a visual clue in source listing that differentiated your application routines from Macintosh API routines. The Lisa API did this to a far better degree than the Macintosh and both used the same Lisa Pascal compiler.

Macintosh debugging using the MacsBug 68000 debugger was too low-level. I wanted a source level debugger since MacsBug was assembly language based.

Internal Macintosh API data structures should not have been published in Inside Macintosh. Apple knew these were going to change so should not have tempted developers into using this information which can cause incompatible applications when new OS versions are released. This would have been difficult to do given the Lisa Pascal compiler's scoping limitations, but Apple could have changed the compiler to support public and private information better (a Modula-2 reference mechanism could have been useful here from what I know).

The Macintosh API use of global variables was not good (these were also known as "low memory globals"). These promoted the Macintosh as a single process system which later was difficult for Apple to upgrade when it wanted to run real processes on the Macintosh. These global variables also made the Macintosh API non-reentrant which caused problems for interrupt-based tasks.

After using the Lisa and its wonderful Office System during my Macintosh development days I was disappointed that more of the Lisa's software architecture was not implemented on the Macintosh. The Macintosh was based mostly on the Lisa's visual aspects but missed other architectural elements which would have made the Macintosh a better system in my opinion. Too bad Apple could not have better leveraged off of the Lisa's best features to create a Macintosh that was really Lisa version 2 (I know the Macintosh team would cringe at this, but suspect the Lisa team would say that would have been the correct approach which was best for Apple's long term prosperity).

For example, the Macintosh should have supported virtual file names instead of file names tied directly to the file system. The Lisa finder (called the Desktop Manager) supported virtual names containing up to 63 characters even though the low-level file system supported only 31 character names. There could also be multiple Lisa documents with the same name in the same folder. The Macintosh should have also been document-centric and not application centric. Lisa users never dealt with Lisa applications directly (these were called tools in Lisa parlance) but instead always manipulated stationery pads which produced documents.

MACCOLLEGE

Around the end of 1984 I attended a wonderful Macintosh programming seminar called MacCollege. Held at Apple's Cupertino headquarters it provided a facility with direct access to Lisa computers for development and Apple's original Macintosh technical support team.

Support people such as Scott Knaster, Cary Clark, and Russ Daniels presented Macintosh information, answered programming questions, and helped resolve bugs in your application.

I recall at the end of MacCollege signing a large piece of cardboard paper which had around a hundred names of all the MacCollege graduates (I wonder where this is today?).

REFERENCES

Here is a list of the key materials that I used during the early Macintosh development days. I still have all these materials including The Investor source code listing and internal architecture manual.

Lisa Workshop manuals (3 volumes, dated 1983 and 1984)

Inside Macintosh manuals (3 volumes for the early days)

MacCollege class notes (around 200 pages)

BYTE magazine and its Macintosh articles (February 1984)

MacWorld magazine premier issue (February 1984)

A Mac For Mick
Back to The Original Macintosh
Font Manager Redux

Login
Account Name:

Password:

Create new account
Rating
Overall Rating: 3.00
(average)

Your rating:

  1
  2
  3
  4
  5
13 Comments     
from Andy Hertzfeld on February 17, 2004 18:33:07
I can't take all the credit for the "Uriah Heap" desk accessory as mentioned above. I wrote an initial version of it called "MemWindow", but Jerome Coonen added lots of features and its new name.
from Tom Emerson on February 19, 2004 00:14:13
Don't forget to mention the "phone book" edition of Inside Macintosh: printed on cheap paper it was included in some packages of the original Macintosh. Not quite as historic as the loose-leaf versions, but a fun (and historical) read nonetheless.
from Henry on February 24, 2004 17:56:29
I didn't have a Lisa and couldn't afford one. I did have a nice Apple][ with a meg of memory, a 7.5 MHz 65C02 with 64K level 1 cache, and 2 ST506 5 MB Shugart hard drives. S-C Software had a 68000 cross assembler, and I had a serial cable, so I worked out a way to use the Mac end of MacCOM and the Apple][ to write my first Macintosh application. Later, Yves Lempereur ported the S-C Macro Assembler to the Mac as MacASM, and I could develop directly on my Mac. I used MacASM to finish MacMovies. MacMovies could compile animations which ran 30 frames per second full screen on a Fat Mac long before the first tiny QuickTime movies. When we designed the Beck-Tech megabyte memory upgrade, Phat Ho wrote a slide show demo for it. As he streamlined the slide show, it got faster and faster, and he finally came up with a demon memory move routine that could fill the entire screen in one frame time. That slide show became MacMovies. My part of MacMovies was a refined user interface and packing / unpacking / motion compression routines which would still run within 1/30th of a second. MacASM wasn't elegant - more like the S-C Assembler on DOS 3.3, but it was a very FAST development system. It would assemble object code as fast as the Mac could read source off the floppy. And then we hacked a hard disk into my Mac... Heady times, and great fun. I'm not sure what Apple Inc. thought of their hardware developers opening the box. Every now and again Apple legal would swing a big sword just above our heads, but they always let us duck.
from Mike Cohen on February 25, 2004 15:14:42
I also didn't have a Lisa. The first real development environment I had was MacForth. I was able to make actual toolbox calls with it - I still remember the first time I called StdGetFile to display a file selection dialog and later when I actually created a real window. I also played around with MDS and wrote a few simple things, but the first environment that really let me write full featured applications was Consulair C. It used the same editor & linker that came with MDS.
from Henry Spragens on February 27, 2004 00:25:57
Actually, MDS came with Bill Duval's Consulaire Edit and Link. Bill's Mac had a 5.25" Twiggy floppy and a Sony 3.5" external drive . A real early Mac User!
from Jorg Brown on July 03, 2004 19:02:29
It took me two months to convince my dad to buy a Mac, and another 2 months before it arrived. (This was 1984; I was 15.) When it did, the only development system available for it was Microsoft Basic, so we went back to the store and bought that. After all, MacPaint and MacWrite were cool but only for a few days. We got Basic, installed it, and what a disappointment - there was no consideration for Mac's unique UI or APIs at all! There was, however, peek and poke, and it could do serial I/O transfer. Hmmmm... Apple's line at the time was that if you wanted to do Mac development, you needed to buy a Lisa. Well, my dad broke the bank buying a $2,499 Mac, and he wasn't about to buy a $10,000 Lisa, so we were stuck - as were most hobbyists. Fortunately we somehow found out about the Macintosh "software supplement", which came with binders for Inside Macintosh, which was still being written, and arrived in small chunks at a time. The trouble with early Inside Mac is that it was such a tease. It described all manner of fascinating routines, with NO INDICATION how you might call them! I don't remember how I eventually figured it out; I think it was because MacsBug came on one of the early software supplement floppies, and I knew enough about assembly language from Apple ][ and 6800-based computers to just have fun stepping along and seeing what the Mac was up to. Fortunately my dad worked at HP so 68000 manuals were easy for us to get. Anyway, every so often, an illegal 68K instruction was deciphered by MacsBug as "_PBRead" or "_DrawMenuBar" or somesuch. Weeks later, the necessary Rosetta Stone appeared - the part of Inside Mac that actually listed the Toolbox routines and their associated A-Trap values! It also described the auto-pop bit, which was crucial later... At last, armed with all of this information, I was able to write a long assembler file with auto-pop A-Traps and symbolic names, and use the HP 9816's pascal development system, to output an object file, which I then disassembled, piped over the serial cable, and POKE'd into memory using Microsoft Basic. After this several-minute process, a single CALL statement from basic ran the code I had written! Viola! A circle appeared on the screen! (Why a circle? Because QuickDraw was the first Inside Mac chapter, and it was a way to get immediate feedback that something was working.) But then, of course, I had to reboot the Mac, and start the whole process all over again - because I couldn't figure out how to return back to Basic, and because I was basically POKE'ing into the middle of Basic's heap, corrupting it. My next step was to try some of the more interesting calls like the Dialog Manager stuff. But it never worked. So I called up Apple (408-996-1010, I still know the number by heart) and told them what I was up to. They eventually transferred me to DTS (Developer Technical Support), and I asked some guy (whose name I do not recall) what was wrong with my calls. He asked me what I had in my resource file, and I said, my what? I think the resource manager chapter of Inside Mac had either not yet arrived, or was indecipherable to me because from a Basic / Apple ][ / 9816 Pascal compiler perspective, there was no way I could create a resource! He was very confused that I didn't know what resources were, and when I described my dev environment he was amazed that any of it worked. I wonder what he would have said if he knew that he was talking to a 15-year-old... Annoyingly, I was never able to duplicate the exact series of connections that got me into DTS, so all I got out of this was that there were something called resources that I absolutely had to have if I was going to write a Mac program. Overall, it was just par for the course. In those days computer adventure games were popular, and programming a Mac was just proving to be a big adventure game. Clues everywhere, but either no maps or incomplete ones. If you ask me, the biggest mistake Apple made in those days was putting so much emphasis on courting the existing big software houses, and not enough on allowing ordinary people to program their Macs out-of-the-box. Sure, a Mac should be easy to use like an appliance, but there was no reason it had to be so much harder to program than the Apple ][. And by "hard to program", I mean, an Apple ][ came with books describing the memory map, the ROM, even some disassembly. The Mac came with none of those things. After so many awful years of priesthood-admins were broken by the personal computer revolution, here it seemed the Mac was reintroducing it. The fact that you couldn't get at the hardware without super-long Torx screwdrivers was just another manifestation of this unfortunate attitude.
from Alfredo Delgado on March 15, 2005 19:17:48
I have to concur with Jorg Brown's assessment of Apple's over reliance on big software developers and the computing appliance paradigm. My first encounter with a Mac was in 1990 at my programming class in 7th grade at George Washington Carver Middle School. It had been given to the school as part of an educational fund raising drive held by Publix supermarkets. I found it to be a useless showcase of a graphical user interface. I was pretty focused on wanting to create software and by then the revolutionary innovations introduced on Macintosh weren't as impressive or rare. In high school a teacher heard my complaints of inaccessibility and handed me a copy of Resedit. However, he just knew it had something to do with programming so apart from turning his trash can into a grim reaper I wasn't won over by what I mostly used as a resource viewer. I think Apple has it's act together on many fronts these days. Shipping developer tools with every copy of the OS is the right move. They also make hyperlinks to Apple Developers' Connection easy to find and they offer free base membership with access to tool updates and documentation. Teaming up with O'Reilly was also an excellent idea. The Definitive Guide series on anything are always second to none.
from fronk kaufer on March 25, 2005 20:45:39
fascinating insights to the extent that my memories of 40 years as a silversmith are jogged after a further near 10 years of inactivity...yes nearly ga ga but not quite ! the word hallmark relates to the oldest registering of quAlity and indirectly, design in existance...in england the 14th century slightly later in france... re: APPLE !... i note that my registered mark with the french governmen"garantée"...their hallmark is an "apple " bit logo that precedes the existance of APPLE computers and i suspect the Apple CORPORATION (the pop-group the BEATLES) by some years.... i ought to get around to checking papers especially as this design logo is still,in france (for sure) is still current......what can one say ...OTHER THAN THAT WILL TEACH ME TO CATCH UP WITH THE WORLD,AND AQUIRE A COMPUTER ?
from Bill Scott on April 03, 2005 03:38:44
Reading the 3rd party developer's story above brought back a flood of memories for me. Perhaps a new section should be set up for third party developer experiences. I would especially love to hear from all of the other game developers from the early Mac days. In 1983 when I read the Byte magazine article on the Lisa I called a friend (co-developer) and said I found the computer we have always dreamed about-- but it is just too expensive. Then when the Mac was announced we were at the local Apple store in May, 1984 to witness it first-hand. Its hard to appreciate, but I remember having a flood of emotions. Just simple things like the Basic programming environment having scrollbars! I mean you could scroll back and forth in your code. And MacPascal with pretty printing in the code- Whoa! Of course we were blown away by MacPaint, MacWrite, MacDraw. Together we bought our macs and we knew that the one thing we wanted to do was write code for this beautiful machine. We tried out MacForth, MacBasic, etc. Soon, we went to work at the Apple store selling Macintoshes. While I have never cared for sales I found it effortless to sell something I believed so strongly in. One of the other guys in the store had been spending his nights playing an IBM game called GATO a WWII submarine simulation. He came in one day and announced that we should contact the game company for GATO (Spectrum Holobyte) and pitch writing a Macintosh version of this best-selling game. The next thing I knew we were putting together a prototype and had only one week to get it together. We took a cursory glance at the IBM version and knew that we wanted a distinctively Macintosh game-- not a port. So we built the prototype to utilize the Macintosh windows, menus and dialogs and not just take over the video directly. We had not bothered to get official developer status but a teenage kid had done so and loaned us the 1000 sheets of Inside Macintosh. A local firm we were consulting with allowed us to make three sets on their copier if we bought the paper. Armed with Inside Mac, our 128K Macintoshes and Consulair C (purchased from Bill Duvall just a week or so before) but with absolutely no experience with the C language, serious development with the Mac or how to write a game we embarked on our prototype. It turned out great. I created the screens with MacPaint wrote some routines to spin the needle on the gauges, faked out a lot of menus and set up the way the screens would rotate between map view and periscope view. Spectrum loved our idea and we soon quit our jobs and dropped out of college to write GATO. It was quite an experience. I remember the excitement of really comprehending the event management and object-oriented nature of the Macintosh. That was a big hurdle coming from IBM PC and Apple II programming. The most challenging aspect though was debugging the game. First, we barely knew C. Second, we had the debug switch installed on the side of our macs and used Macsbug to determine what went wrong when printf did not do the trick. A crash course in 68000. We got the game together in a little over 3 months and were shipping it by the May timeframe. GATO was the first simulation game for the Mac and did extremely well in the market (although the Mac market was not large at the time) (http://www.users.bigpond.com/james.jacobs/mac/gameguide.html) The next few months we stayed holed up just playing with our macs. I remember the first desk accessory I wrote was a silly tool called wrap that made the cursor wrap around when it hit the edge of the screen. And even sillier one was bounce (or bouncy) that made the cursor bounce around the screen. Years later, I was working for a defense contractor and someone had a mac and was showing me a cool desk accessory that wrapped the cursor around the screen (one man's junk...) During that time I hooked 2 macs together and via a serial cable and MacTerminal running on the other I could force a dump of the Macintosh ROM (if I recall through MacsBug) to the other machine. I got my then 4 year old son (who was happy to do anything he could to play with the Mac) to continue to hit the enter key on each screenful of rom dump--which took most of the day! We spent weeks annotating and commenting the Quickdraw portion of the rom. I think the frustration of not knowing 68000 when we started the game development really pushed us to want to understand the Mac from the ground up. The most exciting thing that happened in the summer of '85 (next to the game being commercially successful) was figuring out how regions worked. I tell you that to this day I speak the name of Bill Atkinson with reverence. It was while commenting the PtInRegion section that we understood the elegance of the compression that regions brought to the table. Probably in violation of a patent that I was not aware of I gave talks to my local university and user's groups on how Regions worked on the Mac. Another cool discovery was in disassembling and reverse engineering how Bill A. did the MacPaint blitting with the MOVEM (move multiple). If I remember correctly the MacPaint window was fixed at 480 pixels. Bill would take 14 registers and use them in a MOVEM to push out to memory or back in. The other 2 registers were used for bookkeeping. I used that trick in a few demos I wrote on the Mac. That summer was incredible. We went on to write a 3d graphics library patterned after the Mac library that was to be used in the (failed) Spectrum Holobyte Orbiter game. We played tons of that crazy maze game with the eyeball (what was that called??) over AppleTalk. And we read everything we could about the guys who brought this machine to life. We poured over the Quickdraw code and we dreamed what it would be like to work for Apple. Thanks Andy and all of you for this great machine (and site). It really changed so many directions in my life. I have had a fun career and so much of it springs from that summer madly developing for that insanely great machine in 1985.
from Sarah Homan on December 07, 2005 14:37:35
Hi! This website sucks! it is to hard to find any thing.
from Scott Willsey on December 07, 2005 18:45:53
Sarah, maybe you should just try reading the stories. I had no problem at all reading them using the topics menu on the main page and the arrows on each page to read the articles in each topic. I don't think the site's meant to be an "apple wikipedia", it's a collection of stories that can be read in any order or no order at all.
from Zoz on May 21, 2006 07:54:46
Bill: the maze game with the eyeball was Maze Wars! Played a ton of that over AppleTalk when I was an undergrad too. I preferred to be the video game upright rather than the eyeball. I have to agree with others about Apple making it much harder for the average enthusiast to develop on the Mac. My parents bought an Apple ][+ and a Fat Mac in the same year; the ][+ came with all kinds of cool manuals that introduced me to programming, but the Mac came with nothing but sparse manuals telling me how to point and click. As a result I hacked around with the ][+ and just used the Mac to learn desktop publishing. It was years before I learned how to do any hacking on the Mac besides editing resources with ResEdit (when I worked out how to give Finder icons to files that didn't have them, boy was I proud!). Of course, I was a few years shy of even being a teenager then, but still...
from yuhong on November 17, 2007 09:41:43
For example, IM volume II says that a _ExitToShell equals launching the Finder, which was not true in Switcher or MultiFinder.

Creative Commons License The text of this story is licensed under a Creative Commons License.