Daily Apple

Working on debugging this program has been a challenge.

In order to debug it to the book I have been trying to recreate the run that is shown in the book.  The first column of the actual play at the bottom of the list took quite a while to fix.  With the blurry scan some of the variables are questionable.  In lines 620 and 635 they use a variable N which looks like an M and threw me.

At this point I have the first column, total time, and the last column, fuel units remaining, working.

Part of yesterdays project, reorganization, was to let both my Apple computers be close enough to the printer to share it.

I’ve been trying to debug from one screen to another, which quite often is enough.  I’m finding with Lem, it is not, so I fired up the printer and made a paper listing.  Four pages in length  it looks like it may take awhile before I get it debugged.  On the plus side, with a paper listing I’ll be able to make notes as I go, rather than trying to remember what everything does.

In the mean time, many projects call…

I slowly working my way through Lem with the debugging.  The fuzzy print of the scans is making it slower, so I’m hoping I can find my copy of Basic Computer Games and the print will be clearer.

In the meantime, I have entered rocket and got it pretty much debugged to the book.  Towards the end of the flight, the numbers differ from the book slightly, which I’m hoping is due to differences in the math package.

I started on debugging today.

I ran the program as shown in the book answering no to having flown before and metric to system measurement.  The directions scrolled past like lightning, so I missed most of them as they scrolled off the screen.  I’ll have to put in a temporary series of input statements just so I can double check the instructions.

353 INPUT “PRESS ENTER TO CONTINUE?”;X9$

433, 488 were added just like 353 above.

Later I’ll have to modify this part.

Using this I was able to double check the instructions.  One thing I noticed during this part of the debugging was the program uses the variables N$ and M$ which with the page scans being fuzzy is sometimes hard to tell apart.  Another thing that I noticed was the run in the book shows the user choosing 1 for metric, but the last section that explains the output, describes measurements in feet or English.  The actual run comes out correctly, but I had to double check it anyways because it was different from the book.

One value that puzzles me is line at line 295 which states:

295 M$=”M.MILES”

I think it should be just MILES, but won’t change it for now.

I’ve got the first part, about half of the listing debugged.  That was the easy part, it was just directions and setup.  The rest is going to tedious, because the book is blurry and the use of some very similar variables.

Right now when run the distance and vertical velocity are not printing correctly.

I finished typing in Lem today.  Debugging is going to take a little longer because of the size.  It is more than twice the size of Lunar and the scans are a little fuzzy.  I should be done tomorrow and can update the diskette image.

One line I saw, 1145, I plan to change when I get around to modifying.  It is simply a stop which is not a very graceful exit.  I’ll probably change it to a GOTO 1215, which is the end of the program.  Seems like it would be more graceful.

The next program in my games past series is actually a set of three programs presented in Basic Computer Games.  They are Lunar, Lem and Rocket.  They are different versions of the same game.  The object of these games is to manually land the lunar module on the moon by adjusting the rate of burn for the retro rockets.

I’ll be starting with Lunar.  I don’t know which version is closest to the one I played in high school, but I will say I remember sitting at the teletype and going through yards and yards of yellow paper trying to land that module.

I have typed in the listing for Lunar.

One change I had to make was to line 150.  Applesoft does not put any spaces around numbers when they are printed like some basics do.  In line 150 we are printing a line of information across the screen which include time, miles, feet, mph, and pounds of fuel.  Originally, the program printed mile and feet separated by a semi-colon.  This had the effect of printing one long number (ie 120 miles 0 feet became 1200 and 109 miles 5015 feet became 1095015.  I fixed this by simply inserting a (” “;)between the miles (a) and feet (calculated).

Along those same lines I had to modify lines 240, 260, and 310 adding spaces required to look right.

It seems to be debugged to the book, but like most programs I’m sure something will pop up.