Over thirty years.  Hard to believe....

About half that time back, I wrote up a summary of how my computer game "IFR (Flight Simulator)" came about.  Recently, though, I've come across some old artwork and photos from that era.  And found that folks interested enough in the old Vic-20/Commodore 64 games to post videos to YouTube.

So...this is an update to the old writeup, with some additional detail.  I've also added some technical detail, but if you aren't interested in code and process ideas, you can just skip those bits.

One type of added material is kind of a follow-on to IFR.  It really changed my life, and not just in the sense of making a lot of money.  It actually directed...and helped...my engineering career.


I'm a bit old-fashioned.  I was taught to be modest; to not brag about my accomplishments.  I've posted a lot of my experiences over the years to the aviation newsgroups, but in all but very few cases, they've been along the lines of "Well, look what stupid thing I've done now...."

If I'm going to tell the "IFR Flight Simulator" story, though, I have to abandon my usual themes of ignorance, stupidity, and luck.  Most of us have defining events of our lives, and there's no question that "IFR" was one of the biggest ones in mine.  To tell the whole story, to fully explain how things came about, I'll have to grit my teeth and abandon modesty.  For once, I *did* do something right.

As you'll see, though, one of my usual traits still shines through: Luck.  Luck in catching the home-computer frenzy early, luck in making some decent decisions early-on, luck in finding a decent, honest, company to market "IFR," and luck in making the right friends. Especially the friends.

I'll have to apologize for any gaps or VIC-20 faux-pas in the following.  It's been a long time since I last fired up my VIC, and I finally abandoned using Commodore computers in the mid-90s.  I kept a scrapbook from the period, which helps.  I've got all the hardware, even all the tapes.  But a subsequent move has apparently buried my hard-copy of the code itself.  So I'm going to have to resurrect some of the programming details from rather faulty memory.

I'm editing this on a PC with six gigabytes of memory and a three gigahertz clock speed.  There's 256 Gigabytes of Read Only Memory in a solid state drive, with a 1 Terrabyte (1000 Gigabytes, 1,000,000 Megabytes, or 1,000,000,000 kilobytes) conventional hard-drive for storage.  

It's hard to think back over 30 years, to when I bought my first computer. I was just out of the Air Force, freshly married, working as a junior engineer for one of the biggest aerospace companies in the world.

Home PCs were all the rage.  It was 1982, and IBM was selling its 8086 machine for about $2,000.

Now, $2,000 for a computer is kind of high today, but that was a HECK of a lot of money in 1982.  It was about a tenth of what my Lieutenant's pay had been at the time I'd left the Air Force.

Fortunately, a bunch of upstart companies were introducing "Computers for the rest of us."  There was the Timex-Sinclair 1000, the Atari 400, the TI-99...and the Commodore VIC-20

I was facing some minor surgery that would lay me up for a couple of weeks, and thought that it'd be a good time to get a computer so I'd have something to fiddle with.

We lived on a hill overlooking a shopping complex, and there were several computer stores there.  At one store, a very earnest, *very* young man explained the virtues of the VIC-20 to me.  I was completely computer-illiterate, but Dave Paulsen was able to make it understandable.

The VIC had a full-size keyboard, a definite plus.  In fact, the whole computer was built into the keyboard.

It used the TV for a display device, showing 23 columns and 25 rows of rather squat characters.  In addition to the full upper-and-lower case character set (an advantage over some of its competitors) it also had a bunch of characters shaped like triangles, etc. that could be used to build shapes.  It had 3.5K of RAM.  To put things better in proportion, that's 0.0035 Meg.  Clock speed was about 1 Mhz, more than a thousand times slower than today's standard.

I paid my $300 for the computer and went home happy.  After a couple of days I was back...it was getting too tiresome to have to retype the programs in all the time, so I sprung $40 for the Commodore "Datasette"; their storage device using standard cassette tapes.  The Datasette was one of the drawbacks of the VIC, as far as I was concerned...other companies' computers used a conventional cassette recorder.

Anyway, I programmed happily away.  As a newlywed in a new job, money was tight, so I didn't buy any games.  I wrote my own.  I don't recall any particular details of these early games, except for one.  It was the typical artillery game, where you entered in the angle of the gun barrel, trying to range in on the target.  Being a Hornblower fan, I set it up as a nautical game called "On the Uproll."  The ballistics programming was easy; I spent most of my time getting the character-graphics navy cannon to recoil across the screen when it fired.....

IFR started as one of these games.  I've got an old flying buddy who occasionally came to town with his wife to visit her parents.  Rick and I go waaaay back, and love to bicker about trivia.  We automatically take opposite sides of every issue, just so we could argue it back and forth.

Anyway, Rick and I had done a lot of electronic experimenting in our high-school days.  On one of his visits, he mentioned he was using a new transducer to build a digital airspeed indicator for aircraft.

"G'wannnn," I told him.  "As I pilot, I want an analog needle so that trends are more obvious.  Flickering numbers don't tell you as much as a rapidly-falling needle."

We argued it back and forth, to the usual dismay of our wives.  But it didn't end when Rick went back to Boise.  By God, I *knew* I was right...and I would write a flight simulator program with a digital airspeed readout to prove it to Rick, the next time he came to town!

I knew displaying an outside view would be way beyond my programming capabilities, and would probably slow the simulation down to a crawl even if I *could* write one.  The lack of an outside view didn't bother me.  At that time, visual displays even on REAL simulators were rare, and non-existent on the ATC-510s and war-surplus Link Trainers that were all the simulation devices General Aviation ever saw. 

The Fundamental Issue

The first problem was how to display the aircraft's attitude.  I needed an artificial horizon (AH), or the whole thing would be a waste of time.

The ordinary character graphics were too clumsy...they weren't set with the right charcters for all the conceivable positions an AH would need.  Besides a one-character-wide AH was too small.

Fortunately, in reading some of the programming magazines, I discovered how to "reprogram" character definitions to make the character look however I wanted.  I could set up a 3x3 matrix of characters for a bitmapped area for my AH.  I redefined several other characters to surround the gauges to look like instrument bezels (frames).

But when I programmed the AH in BASIC...it was slow, horribly slow.  That was just a subroutine to draw one instrument...how slow would it get by the time everything was working?

I scanned though the VIC's Programmer's Reference Guide.  I had always skipped over the machine-language programming section, but looked at it with renewed interest.  I'd recently taken an off-hours course at work on programming the 8080 processor, and noticed how a lot of the 6502 codes looked similar.  On the course I'd taken, we'd programmed EEPROMs by entering hex codes.  Reading up on the VIC, it appeared I could POKE a decimal equivalent into the VIC memory.  Reading the RAM map carefully gave me the hints I'd needed as to where to put the machine language code.

I still had the programming forms left over from the 8080 course.  The Programmer's Guide had the appropriate hex numbers for the 6502 operations.  I hadn't heard of assemblers or any sort of aids that would let me just enter in the Op code itself.

Out of that ignorance, I ended up writing a simple hex-to-decimal-to-POKE routine to program the machine language.  I wrote the Op Code (INP, ROL, etc.) on the form, then wrote down the proper hex value.  The program let me key in the hex, which it would then convert to decimal and POKE into memory.  The program also saved the resulting machine language program to the cassette drive.

Fortunately, allocating memory to machine code wasn't a problem anymore.  I'd spent $150 for a 16K memory expansion for the VIC. That's about nine million dollars per Gig, BTW.

The simple program I wrote to display the AH information worked blazingly fast...but it had a problem.  I wasn't much of a Machine Langauge programmer...I wasn't able to do more than a "four-banger" calculator could do.  I couldn't come up with an easy way to do Sines and Cosines, so I used a "cheat" routine to compute the relative tilt of the AH based on the roll angle of the aircraft.

Unfortunately, the "cheat" didn't have a 90-degree point.  It worked up to about a 60-degree bank, but the line started distorting past that.

But as I considered *why* I was writing the simulator, I realized I didn't need it to be able to roll past 60 degrees.  You don't fly aerobatics in instrument conditions.  And having the BASIC program handle the control reversals involved with rolling inverted, etc. slowed the program down just too much.

So I made the decison: The flight model wouldn't allow rolling to ninety degrees or flying inverted.  What to do about the AH, though? Older model AHs couldn't handle aerobatic maneuvers and "spilled" if their limits were exceeded.  I merely put in a subroutine into the AH machine code that changed the display to "OFF" if roll or pitch limits were exceeded.

The other gauges were simple in comparison.  Re-use the same character graphics to form a bezel, then a line to indicate the value.  Vertical bar graphs for throttle and fuel indicators, and some simple graphics for landing gear and flap positions.  Text at the bottom to show a "LORAN" position (GPS wasn't down to the consumer level, yet).

The Airspeed and Altitude, of course, were Text only so I could prove to Rick that you couldn't fly that way....


With that, it was time for the flight model.  I'd played around with the early Microsoft Flight Simulator on a friend's IBM, and there were a couple of things I didn't like about it.  First was the keyboard interface.  As a pilot, I was offended.  If I had a flight simulator, it was GOING to be joystick only.

Second...and probably most important...I didn't like the "remoteness" of the control feel.  Too often, the airplane operated contrarily to my actions the controls.  I'd flown a variety of aircraft and simulators, right up to a KC-135 simulator at CAP camp.  I'd *never* had problems in basic control. 

So however else I worked the flight model, I would always have it so that the airplane always responded the same way to the joystick input (except for modes like stalls, of course).  Moving the stick to the right would immediately start a right roll, you didn't have to "take out" previous aileron inputs first.

Unfortunately, the VIC-20 used the Atari joysticks, which were switch-type devices, not analogs.  Pulling the stick back activated a switch, and no matter how hard or far you pulled back, all that would happen is that that single switch would activate.

So control would be pretty simple.  Pulling back on the stick would give one pitch rate, and one pitch rate only.  Actually, I used the "fire" button on the stick as a rate doubler...pressing "Fire" gave twice the rate of control.  But the pilot ALWAYS had control.  Once in a roll or pitched up or down, the airplane maintained that attitude until the pilot changed it or the airplane stalled or crashed.

With this limitation, the fidelity of the flight model didn't have to be too close.  There was no reason to write a complex, interactive flight model when the only controls were the four little switches.

I started with an airspeed model, with an airspeed "delta" being defined by the throttle position, pitch position, flap setting, and landing gear extension.  Each factor was multiplied by a constant to set the relative impact of each factor.  Also include was an airframe drag factor that varied by the current airspeed...otherwise, the airspeed would just keep increasing without limit.  The total "delta" was added to the current airspeed to compute the new airspeed.

Altitude was handled similarly.  The altitude delta depended upon the pitch angle multiplied by the airspeed, with flap position causing some altitude drop as well.  An additional decrease in altitude depended upon the amount of roll, too...that way, the pilot needed to add some back pressure in a turn to maintain altitude, just like a real airplane.

All of these delta factors were just simple math..though I may have squared the airframe drag factor in the airspeed equation.  From my earlier programming, I knew that complex math slowed down the execution speed, so I kept the math as simple as I could.

Simple?  Yes!  Accurate?  Well, no.  But again, the point was to make it fly right from the point of view of the person holding the stick.  It flew like an airplane.  It didn't automatically start rolling upright when you released the stick, but some airplanes actually don't do that.

Time to Fly...Ooops!.

The airspeed calculation looked good, the altitude calcuation looked good, the AH was working, and the airspeed and altitude readouts were simple PRINT statements.  Time to fly!

I started the program...and immediately the altitude dropped from zero to negative numbers.  This started the second, probably most frustrating part of programming a flight simulator: Getting all the subsidiary rules to work right.

What had gone wrong?  Well, I had nothing in the program to detect WHEN THE AIRPLANE WAS ON THE GROUND.  It just calculated its new altitude, and the program didn't care if the altitude was negative.

There were a lot of things like that that had to be caught and accounted for.  Like I mentioned earlier, the program would always change attitude based on pilot input on the simple four-switch stick. But, of course, it SHOULDN'T do it when the airplane was sitting still on the ground!  And if the airplane is rolling along at 25 MPH, moving the stick back should lift the nose off the ground...but the effectiveness should be less than when the plane is moving at 75 MPH, and moving the stick to either side shouldn't cause the plane to bank. If the plane is banking at 45 degrees, moving the stick back shouldn't cause pitch-up at the same rate as in level flight.

The computer, of course, didn't know it was simulating an airplane. All it knew was the programming I told it.  So I had to set a number of flags, gimmick some of the basic flight equations, and include IF-THEN statements to cover wide variety of flight conditions.

With the basic laws set, it was time to tweak the flight-dynamic constants.  I wanted the airplane to fly like a common light aircraft, so I diddled the constants to produce the proper rates of climb and cruise speeds for the Cessna 172.

This was one of the more enjoyable aspects, since it involved "test flying" the simulator.  Establish level flight, then drop the flaps...how much should the airspeed sag, and how should the altitude start dropping?  If it seemed too much or too little, change the constant for that factor and try it again.

(It was necessary to have the altitude decrease with flaps lowering...the pilot had to apply power and pitch up to maintain altitude.  The plane thus ended in a nose-high pitch attitude in level flight...just the sort of realistic effect I was looking for.)

I got the flight dynamics working pretty good.  The only unrealistic result is that the Best Rate of Climb speed came out at about 90 MPH...a bit more than the actual 172RG.  Considering the simplicity of the model, though, I was happy overall.

And wonder of wonders, Rick had been right.  Flying with the digital airspeed and altitude displays wasn't much different than using analog gauges.  I hadn't flown regularly since going into the Air Force six years earlier.  I *really* enjoyed "test flying" the simulator.

Here's a video of someone flying IFR....

Crashing is Fun!

With the dynamics up to snuff, it came time for the REAL fun programming: Problem subroutines!

Something I didn't mention earlier is that I had some prior flight simulator experience, in that I helped restore a WWII model Link Trainer a few years' prior to IFR.  The Link is an analog computer in vacuum (uses a vacuum system to "store" altitude, has an vacuum manifold for the airspeed value, etc.  I ended up using the Link Trainer systems as direct inspirations for IFR.

Take stalls.  On the Link Trainer, a pendulum is held forward by the airspeed vacuum manifold and the pitch position.  If the airspeed drops too low for the current pitch angle, the pendulum drops back, leaking vacuum out of the altitude storage tank.  It also triggers another pendulum, which drops left or right depending upon rudder position and puts the Link into a spin.

I pulled the same sort of thing with IFR.  I wanted stalls to be a BAD thing, not the gentle experience they often are.  So when the airspeed dropped below the limit value (set by bank angle and flap position), the nose dropped a LOT and the plane ALWAYS spun.  I didn't have rudder pedals, so had a random number generator pick the spin direction if wings were level, or spun the opposite direction from the bank if the plane was tilted.

I once accidentally spun an airplane...with Rick in the back seat, in fact.  I was in a tight left turn when, all by itself, the plane rolled in the opposite direction and the nose dropped to point us nearly at the ground.  I remember the panicked feeling in my gut when that happened...and was glad I was able to reproduce it in IFR.

Turbulence generation came almost directly from the Link.  The Link used vacuum bags to control the fuselage attitude.  A small motor turned a set of cams, which could be cranked into close to a set of keys like a piano.  When a cam hit a key, vacuum was leaked from one of the bags.  In IFR's case, I generated a random number and XORed it with the output from the joystick!  A magazine mentioned the memory locations that set the display X and Y positions, so when turbulence bumped the airplane, I had the instrument panel jerk up/down/left/right as appropriate.

Other subroutines were fun.  Fly too fast and exceed Red Line?  Do burst of white noise for a loud rushing noise from the speaker, and have the airplane pitch down at 45 degrees, rocking the wings as it plummeted into the ground.

Land gear up?  Shake the panel up and down with a scraping sound from the speaker as the plane slides on its belly with the screen shaking and scraping noise reducing as the plane slows to a stop.

Crash into the ground or land with too much bank?  Change the screen to RED with an explosion.

Land going too fast?  Have the pitch pop up as the plane bounces.

Land off the runway?  Increase the drag factor due to the mud, and shake the screen as the plane taxis over rough ground.  Use the random number generator to taxi the plane into a "Tree" on occasion to discourage off-runway operations.

Other instruments were added.  I added a turn needle, basically as a backup for if the AH spilled.  Fuel quantity was easy, and fuel burn rate worked linearly with throttle position.  A VSI was simple enough.

On the Map

Once the flight model and the instruments were working, it was time to actually fly the plane SOMEWHERE.  I drew up a map, including four airports and a mountain range.  There ws a high straight pass on one leg of the L-shaped range, and a lower Z-shaped pass on the other leg.  I used an ordinary Sine/Cosine calculation with the speed to determine the movement over the map, and a simple machine language routine to determine the height of the ground at any particular location. Postion was given to the pilot by a digital display of Latitude and Longitude at the bottom of the screen.

Or at least, they were similar to Lat and Long.  The map itself was initially 256 miles across (don'cha love 8-bit systems).  I started by displaying the numbers as Lat and Longs...but soon realized that 256 miles doesn't cause a real big difference in lat and long (about 4 degrees total, in fact).  I didn't want to be flying by noting the fourth decimal places, so I dropped the total map scale down from 256 miles.  On my first flight betwen the two farthest-apart runways, I soon realized that my actual time in flight would approach *two hours*...most of which was the droning along in flight that's the most boring part of flying.  So I scaled the map down by a factor of ten.

One other item that came out of this was the addition of a "pause" key.  I had deliberately not included one ("There ain't no pause in a real airplane").  Then I got a phone call one day while on a tight approach....

One other reach at realism worked out better.  I didn't like having an "end flight" key that worked in the air, because, again, you just can't quit flying when you want to.  But then I decided to make it work in the air as well...but when you hit the "e" key in flight, the words EJECT would flash on the screen....and the instrument panel would shoot out the bottom of the display accompanied by a loud WHOOOOSH!

Flyability Problems

But while I was adding all the heading and position calculations and the tests to determine when to enter the special subroutines, bad things were happening to the flyability of the aircraft.  It was taking over a second to cycle through all the calculations...which meant that the joystick postion was only being read once a second, and thus the aircraft attitude would only be updated at the same rate. This gave an incredibly ponderous control feel..and it tooks something like ten second to roll 45 degrees.

The solution was simple: I just called the stick-reading and attitude-display subroutine *four* times instead of once during the full cycle of the calculations and subroutines.  While it didn't affect the flight calculations, this quadrupled the apparent control rate. The instruments updated once a second as before, but at least the airplane seemed a lot more nimble.

On the Market?

I eventually had the program working pretty well.  I'd developed the Saturday habit of stopping by the store where I'd bought the VIC, and I'd enjoyed chatting with David, who'd sold me my computer.  One Saturday I brought by a tape with the working version of IFR.  We loaded up the program, and I let him fly around for a while.

"Y'know," said David.  "You could probably sell this."

I was a bit stunned.  I wasn't that familiar with the games on the market for the VIC; I had enjoyed just writing my own.

But it sure sounded good.  While we were better-off than many newlyweds, we certainly didn't feel that comfortable, financially.  My wife was going to school full-time, with only a part-time job on Saturdays.  "It'd be nice to make enough money back to pay for the computer," she said.  "And a new convertible top for the VW," I dreamed.

So, what the heck.  I wasn't sure how, exactly, to keep myself from getting ripped off.  I called around and got the forms to apply for a copyright.  Scanning through the ads in the computer magazines yielded the names of about six companies whose product ads also invited submissions of new programs.  I filed the copyright report, and sent a query letter off to the companies..  "I have written a program for the VIC-20 in which you might be interested.  IFR is a realistic simulation of instrument flight...."  To show I was at least SOMEWHAT cagy, I included a comment as to how I'd already filed for a copyright.

Most of companies responded favorably, willing to examine the program. A couple of them made me a bit skittish.  The one from Academy Software impressed me the most: It was professional, it mentioned that I didn't have to wait to get the copyright verification back before I was protected (very true), and included a signed non-disclosure agreement.

I sent the program in to them, and they loved it.  They called, offering me a 15% royalty on sales.

At the time, I'd had absolutely no experience in any sort of royalty sales.  I went to take to David at the computer store.  He allowed it sounded fairly good, except for the lack of an advance on royalties. But we knew software sales were iffy at best, so that was no big drawback.

This being the usual Saturday mill-around at the computer store, there were a number of other fellow computer geeks around.  "Man, why give THEM all the gravy," said one.  "Publish it yourself!"

I didn't really consider that option.  There were a number of self-published programs at the store...tapes in plastic bags, with mimeographed instructions and cheesy-looking art.  I felt that a publisher that could afford to advertise in COMPUTE! probably had pretty good marketing and distribution.  Besides, I just didn't want the hassle of doing it all myself.

So I signed, in March 1983.  They came back with a set of desired changes, most of which I felt were pretty reasonable.

One, though, rather threw me.  I'd written the program on my VIC, which, with the 16K memory expansion added to the 3.5K internal, had a total memory of 19.5K.  I knew most folks wouldn't have that pricy expansion, so I'd written it to run within the 11.5K that an 8K RAM cartridge would give.

Academy wanted to shorten it further...so that it'd fit on an 8K ROM chip.  "If we limit it to folks who have memory cartridges, we'll cut down on sales," said Academy's Bob Weidner.  "We'd have to bring it out on both tape and disk, too."

In any case, the thought that IFR would come out as a cartridge really pumped me up.  I quickly cut the required 4K out of the program, mostly by eliminating the detailed crash modes and the ejection seat. But as I kept looking at the program, I found unneeded and duplicated code.  I quickly trimmed enough that I was able to replace the deleted features.

All I had for a storage device was the cassette drive, and Academy quickly got tired of having to load in tapes.  They sprung me a $200 advance so that I could buy a disk drive for my VIC.  The reality of having a big 180k storage device was a minor consideration, next to NOT having to take five minutes to read the program from a cassette tape.

We needed an instruction manual, too.  I didn't have a printer for my VIC (or for that matter, any sort of word processor) so I went to my friends Judy and Bo Stringer's place and used their IBM.  I learned Wordstar as I went, ending up with about twenty pages.  I drew the maps by hand, which Academy redrew in decent format.

Versions went back and forth as bugs were eliminated.  Finally, in July, I received the first FEDEX package of my life: An IFR cartridge, and a sample of the cover art to go with the instructions.  I opened the package and just started laughing: The cover art was PERFECT!  A head-on, wide-angle view of a Cessna landing in the rain, with a narrow mountain pass in the background and the inset of a sweaty hand on a joystick in front of the IFR panel.

A real joy it was, too, when I plugged the cartridge into my VIC. Power switch on, and there it was... "IFR (FLIGHT SIMULATOR) By Ron Wanttaja."  No loading, no waiting.  Just like an Atari game.


Right about the same time, an advertisement in the Seattle Times newspaper caught my eye.  Compufair, the first-ever citywide computer fair aimed at general users, was being held in the Seattle Center Exhibition Hall (a leftover from the 1962 World's Fair) in September 1983.  As part of the program, they were having a contest... for "Individual innovators or anyone else with a bright new idea in computing."  Seven finalists would be picked for the "Cloud Nine Idea" contest, and all would receive free display booths at Compufair.  The winner would receive $1000!

I put in an entry, and on August 30th, received notice that I was a finalist.  I would get a free booth, a table, and a couple of chairs...everything else was up to me.  I had two weeks to put it all together.

Academy was thrilled...except the production plans for the IFR cartridge would make it JUST miss the show date.  Instead, they printed up advertising sheets with coupons for $10 off the mail-order price of $40.  Plus a nice blow-up of the cover of the program box.

Now, how can I spiff up the booth?  Judy Stringer volunteered to sew up fluffy clouds for the backdrop.  I had a 727 pilot seat I'd bought from Boeing Surplus and a B-50 autopilot joystick that I'd bolted to it (I'd built an A-D converter to allow it to work with the VIC).  I bought some particle board and cut out a 1/4 scale Cessna rudder, covered it in white contact paper, then put "IFR" slanting down the tail just like Boeing put the model numbers on its new jetliners.

Somehow we were ready by the weekend of the show.  Bo and Judy hauled our TV, the pilot chair, and the rest of the gear down to the Center on Thursday.  Friday morning the show started.

I damn near talked myself hoarse.  I usually had a pretty good crowd. A lot of pilots came by, and several of them managed to take off, fly to the other airport, and fly a successful instrument approach.  Many wanted to buy the program, and were a bit disappointed when all I had were order sheets.

I still remember one older man.  His arms were loaded with purchases, and he was being followed by his wife, who had a suffering expression.  He saw my booth, and his eyes positively lit up.  He almost ran over to try his luck flying the program.  Turns out he was an airline pilot.

The local CBS affiliate even did a live report from the fair for their noon news show...with me sitting in the pilot chair, flying IFR, while the reporter interviewed me on the air.

Sunday noon came the announcement of the winner.  It wasn't me...but the winner had a cool teaching program that he needed money to bring market, so it was a good choice.  I'd given away all my discount certificates, and turned down about a half-dozen offers to buy the 727 seat....

So there was my moment in the limelight...fun while it lasted.  I took Bo and Judy and David out for dinner that Sunday night, after we took down the display.

It Gets Surreal...but in a GOOD Way

Back at my engineering job on Monday, it was like Cinderella back scrubbing the hearth.  The ball was over...or so I thought.

I got a call from Bob at Academy in the middle of the week.  "We just got a massive order from Toys-R-Us.  Your royalty on that sale comes to eighteen thousand dollars."

I was absolutely, totally stunned.  That was about 75% of my annual salary at that time.  All in one sale.

I couldn't stay at work. I went home, and called my wife's school. I'm sure she (and everyone else) thought there was some sort of dire emergency.  Everyone else probably STILL thought so when I told her the news...she screamed, long and loud.

We went out to eat that night, too.

Commodore 64 Version

As the VIC version of IFR wrapped up a couple of months earlier, Academy asked me to do a Commodore 64 conversion, and I was right in the middle of THAT project.  The Toy-R-Us order included orders for the C-64 version, so we had to get it competed and published in time to get it in the stores before the Christmas rush.

The C-64 version was about the same as the VIC.... except now I went with gauges for the airspeed and altitude, instead of the text readout in the Vic version.  Rick had been right, but I still preferred the look of gauges.  I added a digital readout of the last two digits of the altitude.

The Attitude Indicator was now in color, twin fuel tanks and a DME (Distance Measuring Equipment) were added.  Everything else worked the same.  The 6502 machine code worked the same on the 6510, with some minor changes necessary.

We made it, with a month to spare.  I had been haunting the local Toy-R-Us, and it was another big thrill to see the red (VIC version) and black (C-64 version) boxes on the shelves, proclaiming "IFR FLIGHT SIMULATOR by Ron Wanttaja."  The chain started advertising for Christmas..and there was IFR, in the ads.  Academy printed up posters, which Toys-R-Us displayed in their computer area.  Academy added IFR to their  full-page ads in the computer magazines.

One hell of a feeling.

The Reviews are Out!

The reviews started coming out.  They all seemed to take the "There I was" approach... "Ceiling is 200 feet in light rain...."  The reviews extolled the play and interface of the game, with the only negatives referring to the rather crude depiction of the panel.  A fair hit.

Academy passed on a few fan letters, too.  One was written on stationery from the Hotel Lexington in New York, from a 747 pilot who just loved the program. I got letters from happy mothers, telling me how their kids had developed an interesting in aviation science from playing with my program.  Once letter was from the "Institute of Social Sciences" in The Hague, with some small suggestions but a closing comment calling it the "Best simulation I have yet seen." Some letters expressed admiration at how well the airplane model worked, others asked about how some of the little tricks were done.

Not every one was positive, of course.  One writer stated his opinion clearly and distinctly: "It stinks!"  He didn't like the lack of an outside view...again, a fair hit.

First Year's Results

All this trickled in during 1984, the first full year of release. Personally, I was waiting for my first royalty check.  The contract specified the delay between sales and royalties, so I knew the first one of my quarterly payments would come out about mid-August.

Good timing, really.  I was turning 30 that month, with the visions of over-the-hilldom dancing through my head.  I was looking for a nice check to make it seem like I'd accomplished something with my life.

It did.  It was a tad over $25,000....more than my yearly salary.  I had driven home from work to open the envelope when my wife said it had arrived.  I drove back to work laughing maniacally all the way.  I deposited the check, keeping out $500, which I gave to my wife for a shopping spree.

The next quarterly payment came in mid-November.  It, too was over $25,000.

We opened up an interest-bearing checking account to deposit this windfall.  We nicknamed the checkbook, "Bottomless."

Our friends Bo and Judy took a trip, and I picked them up at the airport.  On the way home, I said, "Hey, there's an interesting airplane at that little airstrip near your place.  Let me show you."

We drove onto the ramp and stopped in front of a Cessna 150.  "What do you think?"

They looked on silently for a moment.  "What's so interesting about it?"

"I bought it, yesterday."  After thirty years of dreaming, I finally owned my own airplane.

Fortunately, my wife and I have simple tastes.  We didn't go crazy buying sports cars, stereos, or trips to Europe on the Concorde. Other than the airplane, there was only one major expense: We finally had the down payment to buy our own home.

Oddly enough, though, the VW never *did* get a new top.

We had some taxes to worry about, though.  One of the secretaries at work had a daughter who'd just started a tax company, so we worked with her.  Income Averaging was still allowed, so the big windfall of that year was softened by my lower salaries in years past (including the last year or two I was in the Air Force).  Still, my engineering salary that year all went to pay the tax bill.


That second $25,000 royalty was the peak, though.  Royalties for the second year were about a third of the first year, and subsequent years showed similar drops.  Commodore came out with a new set of computers, the Commodore 16 and PLUS/4, and, per Academy's request, I ported IFR to those platforms.  Due to the rarity of joysticks for these computers, I had to break down an allow optional keyboard control.  It was mostly for naught, though, as the computers flopped in the US, Pretty soon my annual royalties dropped to below $1,000.

Other things were happening in my life, though.  In 1985, my airplane suffered an engine failure due to bad gasoline.  I managed to nurse the glide to a safe landing at my home field, then wrote up a report of the incident for the Usenet newsgroup net.aviation.  Response was positive, and I decided to work on the tale a bit and submit it to FLYING magazine.  They bought it, my first sale as a freelance writer.

I eventually sold the Cessna and joined a local Flying Club flying a small homebuilt open-cockit airplane called a "Fly Baby."  I submitted an article to PRIVATE PILOT magazine about the airplane...but the editor of a sister magazine intercepted the article, and felt it worked far better in HIS magazine: KITPLANES.  He called me and invited me to send him lots more articles...just the thing a freelancer dreams of.

His name was familiar, though.  Eventually, I looked in my scrapbook. He had written a report on flight simulators for an aviation magazine back in 1986.  He had panned IFR.

I kidded him about it, but he kept buying my articles.  Within a year, a book publisher had talked to him about writing a book on building homebuilt airplanes. He didn't have the time to do it...but told them to contact me.  TAB Books sent me a letter inviting me to write a such book for them.  The book turned out to be 100,000 words long, and was written on the Commodore 128 left over from my IFR days.

KITPLANE CONSTRUCTION was published in 1991.  The first edition came out in five printings, with the second edition published in 1996, and a third edition ten years later.  The book even won a journalism award.

Back in 1986, I started working on a novel about a young boy in the US Navy during the War of 1812.  Working title for the book: ON THE UPROLL, the same name I'd used for that cannon-firing game I'd originally written for the VIC.  Not quite as much success on that; I sent it to publisher after publisher. The name eventually morphed to THE KEY TO HONOR.

Fast-forward back to 1994.  I was facing the big 4-0.  Like my 30th birthday, I needed a bit of perking up.  It came late, but it came: Two months after my birthday, a publisher enthusiastically bought THE KEY TO HONOR and asked if I could make a series of it.  I also wrote a sequel, THE PRICE OF COMMAND, published a few years later.  Eventually will write some more, once I had time.

The Work Impact

All through this, I kept working at my aerospace job.  A bit after IFR had come out, me and a co-worker were trying to figure out how much of the ground a satellite could see from a certain altitude and position.  We were squatting down with a globe and a ruler, squinting at this faux Earth and trying to sketch the visibility contour on a hard-copy map.

"Damn," I said.  "There's got to be a way to do this on a PC."

So...I started writing a program.  Didn't know squat about orbit mechanics, so I grabbed a basic textbook  ("The Fundamentals of Astrodynamics") and started to see what it took.  I learned how to compute the ground track of a satellite, worked out how to draw a Mercator map on the computer screen, then figured out how to combine them.  I had used an orbit-analysis program on a big computer earlier, and stole its name:  "Interactive Globe and Orbit Mapping and Display" (IGOMAD). 

With the basic capability, it was that hard to figure out how to compute visibility contours, beam footprints, and most of the other features the big guys would be doing ten years later.  It was an easy modification to kick out files that gave the geometry (azimuth, elevation, and range) whenever a satellite went over a given ground target, or just a set of rise-set times. These were all time-consuming computations, but I used the speed-up tricks I'd learned on IFR to make the run times acceptable.  I could use the data to perform trade studies and pick the right combinations of satellites and orbits.

There were other bits of IFR's DNA in IGOMAD.  Remember the story about the plane "falling" when the program first started because the program didn't know about "ground"?  That an other experiences had made me VERY careful about not assuming that there weren't any "gotchas."  I did a lot of cross-checking out output, to ensure what was being computed was what I assumed was being computed.

In addition, I'd learned how to program sequentially without having to plan everything in advance.  In IFR, I'd program in a basic feature (such as computing whether a plane is rising or falling) and add code to it to perform more and more detailed function.  I learned how to track the capabilities in my head and understand where things were going.

IGOMAD itself wasn't the end.  I'd be assigned to another program, and the need would be slightly different.  So I added a feature to the main program, or did a custom version.  IGOAPE, IGOPOP, IGOBATS, IGOPISS (don't ask), even IGOMARS (IGOMAD plotted against Mars instead of the Earth).  At one point, I was assigned to an early UAV program, and developed IGOFLY...a simplified mission-planning tool that included computing when the UAV would be able to talk to a relay satellite.

Keep in mind that I'm not officially a programmer.  I was never brought on to a program to "write code", I was sent there to answer questions, usually about mission performance and the ideal orbital population.  How often does a satellite view a given ground target?  How does it improve with a different inclination or orbit altitude?  My job was to answer questions like these, and the best way to do it usually turned out to be some sort of simulation.  Even when commercial orbit-analysis tools became available, IGOMAD still filled a niche because I was able to incorporate unusual features or limitations of the space systems we were examining.

Not that long ago, I developed a version that completely simulated a proposed space system, right down to how the ground communications antennas and ground command software worked.  It used IGOMAD orbit files as inputs, and let one vary particular settings (such the number of satellites and their orbits, the number and locations of the ground antennas, the magnitudes of system constraints, and the amount of ground processing time) to support trades to figure out the best settings.  This program had the highly prosaic title of "Mission Model."

The Government decided to bring in consultants to, basically, duplicate my work and provide confirmation.  I spent a couple hours explaining what Mission Model did, and how it implemented some really strange limitations our system had.  Then the consultants declined the job.  They were using, basically, commercial packages that couldn't factor in the realities of our system.  They couldn't modify their tools, like I could.  Learning programming flexibility with IFR paid off again.

There was only one time my IFR work directly crossed my professional sphere.  I was tasked to lead a team to develop a Space Station assembly simulator, using a 737 flight simulation cab.  At the time, one project I was working on was a Shuttle Flight Simulator, and I got concerned about a potential conflict of interest.  So I contacted my work legal department to get a reading.

I gave them the background, and they were curious about IFR.  One of the lawyers said to me.  "Our company develops flight simulators, as well.  We think we might own the rights to your flight simulator."

Did what was probably the best thing I could have done:  I laughed in his face.  "Does this massive, international aerospace company want to claim ownership of a video game?"  Pushing back was all it took.  They cleared me to continue with my separate, private, Space Shuttle simulation as well.


But...nothing came of it.  The computer gaming industry was not longer the province of individual hackers like myself.  Games were built by teams now; able to merge multiple talents together and crank out high-quality products a lot quicker.

Immediately after IFR for the Commodore 64 came out, I started working on an improved version.  I made the graphics looked better, I enlarged the attitude indicator, and made it so it could load several maps it.  It was designated "IFR II". 

I stopped by Toys-R-Us once to check that they still had the big "IFR" poster in their software area.  I heard a guy ask the clerk if they had "Flight Simulator 2" yet.

I felt pretty darned good...until I realized he was NOT referring to IFR II.  A company called "Sublogic" had developed a flight simulator with an outside display for the IBM PC, and they were apparently getting ready to produce a version for the C-64 and the Apple II.  "Sublogic Flight Simulator 2" came out about a year after IFR, and, of course, blew IFR sales away.  Never mind that it was slow and clunky, people wanted that outside view. 

Haven't heard of "Sublogic Flight Simulator", you say?  It had been previously licensed for use on the IBM PC and renamed, "Microsoft Flight Simulator."  Sublogic was coming out with a Commodore 64 version, and that's what folks were waiting for.

I was lucky IFR had come out when it did.


"Lucky," of course, sums things up pretty well.  I was never so much a good programmer as a lucky one...I hit the market with the right product at the right time.  I'm lucky at the variety of decisions resulted in just the right combination of accuracy and playability. I'm lucky in my wife, who tolerated the distraction and lack of attention that development of the program engendered (and who proudly wore the "Computer Widow" T-Shirt I bought her).  I'm lucky in my choice of Academy, with them turning out to be 100% honest and upfront.  I'm especially lucky in my friends, from Rick Reierson to David Paulsen to Bo and Judy Stringer and a host of others who helped.

Thanks, guys.  It was a heck of a ride while it lasted....

Ron Wanttaja
March 2016

Download the IFR Manual!