## Orbital Mechanics

Just starting to think about how I can simulate the spacecraft orbiting the Earth.  Sure, I can draw some pretty little ellipses on the screen, but I’d like that to have some relationship with the actual orbital path of a spacecraft.  My understanding of orbital mechanics is pretty limited at this point, and I’m planning on spending most of this evening studying. Till then, here’s a nice diagram of what I have to simulate:

## Flight Dynamics

Spacecraft Flight Dynamics is the study of spacecraft performance, stability, and control. If you ever listen to mission audio from the American Space Program, the flight controller responsible for this particular aspect of the mission has the call-sign “FIDO.” In terms of popular culture, “FIDO” was the guy in the film Apollo 13 who determined that the mission could still make orbit after the second stage center engine cut out prematurely. In that case, Apollo 13 was able to make orbit by extending the burn time of the four remaining J-2 engines.

Every rocket, ranging from simple fireworks to the mighty Saturn V have the same four basic forces acting on them: weight, thrust, lift, and drag. Simulating the behavior of the rocket mathematically requires us to quantify these forces and establish mathematical relationships between them.

Weight – is the gravitational force acting on the rocket. This is distinct from the mass of the rocket and is dependent upon the local gravitational field.

Thrust – is the reaction force generated by the engine and is determined by the mass of propellant burned in the engine and the velocity with which the exhaust gas is expelled through the engine’s nozzle.

Lift – is an aerodynamic force generated by air flowing past the surface of the rocket. Lift is the component of this force that is perpendicular to the oncoming flow direction. This becomes confusing when the rocket’s flight-path is more vertical than horizontal and we begin treating lift as a lateral force rather that the usual vertical force seen in airplanes and helicopters.

Drag – is a similar aerodynamic force, this time exerted in a direction parallel to that of the airflow.

Ultimately, the behavior of our rocket – and its simulation on the Apple ][ – come back to Sir Isaac Newton and his laws of motion. In particular, the second and third law find application here since our rocket’s thrust is dependent on his third law (“For every action, there is an equal and opposite reaction.”) and the motion of the rocket is dependent on the second law:

F = ma

Where F is the sum of all forces acting on the rocket, m is the current mass of the rocket (constantly changing as it expends fuel and rocket stages), and a is the acceleration vector, the instantaneous rate of change of velocity (v), which in turn is the instantaneous rate of change of displacement. Solving for a, acceleration equals the force sum divided by mass. Acceleration is integrated over time to get velocity, and velocity is in turn integrated to get position.

The weight of the rocket is computer by multiplying its mass (in kg) by the acceleration imparted by the local gravitational field. Although gravity varies as the distance from the center of mass changes, according to the inverse square law, we can assume that for objects near the surface of the Earth, the gravitational acceleration is approximately 9.8 ms2.

w=mg

As we are using metric units to simplify our arithmetic, we should note that while mass is expressed in kilograms, weight (like thrust) will be specified in a derived unit, Newtons.

As mentioned above, thrust is the reaction force generated by the rocket engine and is determined by the mass of propellant burned in the engine and the velocity with which the exhaust gas is expelled through the engine nozzle. The basic equation for finding the thrust of a rocket is:

Fn=mve

Where Fn is the thrust (in Newtons), m is the mass of the fuel and oxidizer burned in the engine and ve is the velocity of the exhaust gas.

Without spending too much time on the mathematics, our simulation has to integrate all four of these forces acting on the rocket.  The BASIC source code here is a little rough and is still in a very preliminary stage, but is an attempt at simulating the flight dynamics of a rocket attempting to reach orbit.  Again, we’re sticking with the early space program… In this case, the weight and general characteristics of our rocket is a Mercury-Atlas similar to MA-6 that put John Glenn into orbit on February 20, 1962.

```Friendship 7

Launch Date:  02/20/1962 14:47 UTC
Pilot:  John Glenn
Launch Vehicle Mass: 120,000 kg
Approximate Fuel Mass:  114.420 kg
Main Engine (Sustainer) Thrust: 300 kN
Booster Engines - Thrust:  1,300 kN
Main Engine Burn Time: 300 seconds
Booster Engines Burn Time:  134 seconds
Velocity at Orbital Insertion: 7,844 m/s
Altitude at Orbital Insertion: 248 km
```

Running this simulation on the Apple IIe Emulator (Source code below), it appears we get the time, range, altitude, and velocity approximately correct, but our translation on the X, Y, and Z axes is way off.  Apparently, I’m not resolving the forces correctly in all three dimensions…

I’ll review the code and post more later…  I need to check my arithmetic!

```]LIST

1000 REM PROGRAM MAIN
1010 GOSUB 1390: REM INITIALIZE STATE VECTORS
1020 GOSUB 1630: REM INITIALIZE LINEAR INCREMENTAL CHANGE
1030 GOSUB 1230: REM DRAW THE PLOT AXIS
1040 GOSUB 1280: REM PLOT THE COURSE
1050 GET A\$: IF A\$ = "" THEN 1050
1060 END
1070 REM RESOLVE FORCE IN THREE DIMENSIONS
1080 REM
1090 LET TZ = 90 - T: REM T IS ANGLE THETA FROM 6000
1100 LET TY = A2: REM LAUNCH AZIMUTH FROM 7000
1110 LET TX = T: REM CURRENT PITCH FROM 5000
1120 LET R9 = (22 / 7) / 180: REM PI OVER 180
1130 LET FX = F * COS (TX * R9): REM FORCE ALONG X AXIS
1140 LET FY = F * COS (TY * R9): REM FORCE ALONG Y AXIS
1150 LET FZ = F * COS (TZ * R9): REM FORCE ALONG Z AXIS
1160 LET F1 = SQR (FX ^ 2 + FY ^ 2 + FZ ^ 2): REM CHECK YOUR ANSWERS!
1170 REM
1180 RETURN
1190 REM CALCULATE ACCELERATION GIVEN THRUST AND WEIGHT
1200 REM
1210 LET A9 = T9 / VM
1220 RETURN
1230 REM DRAW SCALE
1240 HGR : HOME : HCOLOR= 3
1250 REM
1260 HPLOT 0,159 TO 279,159
1270 RETURN
1280 REM PLOT INITIAL BOOST PHASE
1290 VTAB 21: HTAB 1: PRINT "INITIAL BOOST PHASE:"
1300 LET PX = 0:PY = 0:R = 159:PI = 22 / 7
1310 FOR T = 0 TO 90
1320 LET X = R * COS (T * (PI / 180))
1330 LET Y = R * SIN (T * (PI / 180))
1340 LET PX = 279 - X:PY = 159 - Y
1350 HPLOT PX,PY
1360 GOSUB 1680
1370 NEXT T
1380 RETURN
1390 REM INITIALIZE STATE VECTORS
1400 SX = 0: REM POSITION X METERS
1410 SY = 0: REM POSITION Y METERS
1420 SZ = 0: REM POSITION Z METERS
1430 VX = 0: REM X VELOCITY MPS
1440 VY = 0: REM Y VELOCITY MPS
1450 VZ = 0: REM Z VELOCITY MPS
1460 MT = 0: REM MISSION TIME SECONDS
1470 A1 = 0: REM ALTITUDE MSL
1480 R1 = 0: REM DOWNRANGE METERS
1490 V1 = 0: REM NET VELOCITY
1500 FM = 114420: REM FUEL MASS KG
1510 AX = 0: REM ATTITUDE X AXIS
1520 AY = 0: REM ATTITUDE Y AXIS
1530 AZ = 0: REM ATTITUDE Z AXIS
1540 RX = 0: REM RATE CHANGE X AXIS
1550 RY = 0: REM RATE CHANGE Y AXIS
1560 RZ = 0: REM RATE CHANGE Z AXIS
1570 VM = 120000: REM VEHICLE MASS KG
1580 A2 = 57.5: REM LAUNCH AZIMUTH (90 DEG DUE EAST)
1590 LET G = 9.8: REM ONE G OF ACCELERATION
1600 LET FR = 384.1: REM FUEL CONSUMPTION PER SECOND
1610 LET T9 = 160000: REM THRUST IN NEWTONS
1620 RETURN
1630 REM LINEAR INCREMENTAL CHANGE TO STATE VECTORS
1640 DIM D(4): RESTORE
1650 DATA 320,188000,248000,7844
1660 FOR I = 1 TO 4: READ D(I): LET D(I) = D(I) / 90: NEXT I
1670 RETURN
1680 REM UPDATE STATE VECTORS
1690 LET MT = MT + D(1)
1700 LET A1 = A1 + D(1) * V1 * COS (T * (PI / 180))
1710 LET R1 = R1 + D(1) * V1 * SIN (T * (PI / 180))
1720 LET V1 = V1 + D(4)
1730 GOSUB 1190
1740 LET F = T9
1750 GOSUB 1070
1760 LET VX = VX + (FX / VM) * D(1)
1770 LET VY = VY + (FY / VM) * D(1)
1780 LET VZ = VZ + (FZ / VM) * D(1)
1790 LET SX = SX + VX * D(1)
1800 LET SY = SY + VY * D(1)
1810 LET SZ = SZ + VZ * D(1)
1820 LET VM = VM - (FM / 90)
1830 HOME
1840 VTAB 21: HTAB 1: PRINT "TIME: "; INT (MT)
1850 VTAB 22: HTAB 1: PRINT "RANGE: "; INT (R1)
1860 VTAB 23: HTAB 1: PRINT "ALTITUDE: "; INT (A1)
1870 VTAB 24: HTAB 1: PRINT "VELOCITY: "; INT (V1);
1880 VTAB 21: HTAB 20: PRINT "POS X: "; INT (SX);
1890 VTAB 22: HTAB 20: PRINT "POS Y: "; INT (SY);
1900 VTAB 23: HTAB 20: PRINT "POS Z: "; INT (SZ);
1910 RETURN
1920 REM DELAY LOOP
1930 FOR N = 0 TO 2000
1940 NEXT N
1950 RETURN```

## Simulating Simple Ballistic Motion on the Apple ][

The very first flights of the American space program were the Mercury-Redstone Ballistic flights.  A total of six Mercury-Redstone vehicles were launched between November 21, 1960 and July 21, 1961 on sub-orbital ballistic trajectories that carried the Mercury Spacecraft from Cape Canaveral Air Force Station to splashdown in the North Atlantic.  Two of these missions were crewed by humans — MR3 on May 5, 1961 carried America’s first Astronaut Alan B. Shepard into space in his capsule Freedom 7; and MR4 on July 21, 1961 piloted by Astronaut Gus Grissom in his capsule Liberty Bell 7.

Unlike later Mercury missions, these Mercury-Redstone flights did not go into orbit around the Earth; rather they “went up like a cannon ball and came down like a cannonball.”  From an engineering perspective, these flights were important because they facilitated the development of an attitude control system that could orient the spacecraft in a given direction, life-support systems that could keep an astronaut alive in the vacuum of space, heat-shields that could protect a spacecraft and its occupants during re-entry, communications, and tracking systems.

From the standpoint of simulating the basic physics of spaceflight, these missions are an ideal starting point — we can disregard the complexity of orbital mechanics and concentrate on the relatively simple physics of ballistic motion.  This first attempt at creating an Applesoft Program to simulate ballistic motion is pretty bare-bones:  it doesn’t take air resistance into account, nor does it attempt to simulate the attitude of the spacecraft or any of the systems therein.  For all intents and purposes, we are simply simulating ballistic motion, be it a baseball, a cannon shell, or a spaceship.

```100 TEXT : HOME : SPEED= 255
110 HGR : HCOLOR= 3
120 VTAB 21: ONERR GOTO 5000
130 LET HS = 2.74400055E - 03
140 LET VS = 6.26803705E - 03
150 GOSUB 4000
160 PRINT "SIMPLE BALLISTIC MOTION FOR THE APPLE ]["
170 PRINT
180 INPUT "INITIAL VELOCITY: ";V0
190 IF V0 < > 0 THEN 210
200 NORMAL : TEXT : HOME : END
210 IF V0 < 1000 THEN 240
220 PRINT "EXCESS VELOCITY. TRY AGAIN!"
230 GOTO 180
240 INPUT "LAUNCH ANGLE: ";TD
250 GOSUB 1000: REM CALCULATE FLIGHT DATA
260 GOSUB 3000: REM PLOT FLIGHT DATA
270 GOSUB 2000: REM DISPLAY FLIGHT DATA
280 GET A\$: IF A\$ = "" THEN 280
290 GOTO 170
1000 REM CALCULATE FLIGHT DATA
1010 LET G = 9.8
1020 LET PI = 22 / 7
1030 LET T = TD * (PI / 180)
1040 LET VX = V0 * COS (T)
1050 LET VY = V0 * SIN (T)
1060 LET H = (VY ^ 2) / (2 * G)
1070 LET TP = VY / G
1080 LET TT = TP * 2
1090 LET R = ((V0 ^ 2) * SIN (T * 2)) / G
1100 RETURN
2000 REM DISPLAY FLIGHT DATA
2010 HOME : VTAB 21: HTAB 1: INVERSE
2020 PRINT "ANGLE: ";
2030 VTAB 21: HTAB 21
2040 PRINT "VELOCITY: ";
2050 VTAB 22: HTAB 1
2060 PRINT "HEIGHT: ";
2070 VTAB 22: HTAB 21
2080 PRINT "RANGE: ";
2090 VTAB 23: HTAB 1
2100 PRINT "P TIME: ";
2110 VTAB 23: HTAB 21
2120 PRINT "T TIME: ";
2130 NORMAL : VTAB 21: HTAB 12
2140 PRINT INT (TD);
2150 VTAB 21: HTAB 32
2160 PRINT INT (V0);
2170 VTAB 22: HTAB 12
2180 PRINT INT (H);
2190 VTAB 22: HTAB 32
2200 PRINT INT (R);
2210 VTAB 23: HTAB 12
2220 PRINT INT (TP);
2230 VTAB 23: HTAB 32
2240 PRINT INT (TT);
2250 RETURN
3000 REM PLOT TRAJECTORY IN HIGH RES
3010 REM
3020 FOR ET = 0 TO INT (TT) STEP 0.5
3030 LET X = VX * ET * HS
3040 LET Y = VY * ET - (0.5 * G * ET ^ 2)
3050 LET Y = Y * VS
3060 HPLOT X,160 - Y
3070 NEXT ET
3080 LET PX = VX * TP * HS
3090 LET PY = (VY * TP - (0.5 * G * TP ^ 2)) * VS
3100 HPLOT INT (PX), INT (160 - PY) TO INT (PX),159
3110 RETURN
4000 REM PLOT SCALE ON MONITOR
4010 HPLOT 0,0 TO 0,159
4020 HPLOT 0,159 TO 279,159
4030 FOR I = 0 TO 159 STEP INT (159 / 25)
4040 HPLOT 0,160 - I TO 5,160 - I
4050 NEXT I
4060 FOR I = 0 TO 279 STEP INT (280 / 100)
4070 HPLOT I,159 TO I,154
4080 NEXT I
4090 RETURN
5000 REM ERROR HANDLING ROUTINE
5010 PRINT CHR\$ (7);"RANGE ERROR -- VALUE EXCEEDS PLOT RESOLUTION."
5020 END```

When the program begins, it draws a reticle on the screen used to scale the display.  In the vertical direction, output is scaled to approximately 26 kilometers and in the horizontal direction, output is scaled to approximately 101 kilometers.  Although this is not enough resolution to simulate the flight of the Mercury spacecraft, it is intended as a proof of concept for work that will follow.  In this case, the degree of scaling was chosen in order to simulate the flight of an object launched at up to 999 meters per second at a launch angle of 45 degrees.

After preparing the display, the program prompts the user to enter the initial velocity and the launch angle.  It then calculates the flight parameters, attempts to plot them on the screen, and displays the final parameters of the flight at the bottom of the screen.  The program then waits for a keystroke and returns to the initial prompt for velocity.  The user can then either enter a zero to terminate the program, or enter another set of launch parameters.  The display is NOT cleared for subsequent plots, the previous flight path remains on the display. This is intended to allow for comparison of multiple runs.  The sample shown below demonstrates three individual runs — each run used a velocity of 999 meters per second at a selection of launch angles at 15 degrees, 30 degrees, and 45 degrees from the horizontal.

As you can see, the program calculates that an object launched at a 45 degree angle and a velocity of 999 meters per second will reach a maximum height of 25,475 meters in 72 seconds and will travel downrange a distance of 101,836 meters in 144 seconds total elapsed time. These figures are approximate and in general agreement with the values found by various online ballistic calculators.

One online resource that was used to confirm these calculations is:  http://hyperphysics.phy-astr.gsu.edu/hbase/traj.html

There are several obvious objections that come to mind when considering how closely this sort of simulation corresponds to the behavior of actual spacecraft.  First, a rocket begins with a velocity of zero and actually accelerates as it is boosted upwards. True ballistic motion does not begin until acceleration ceases.  Secondly, large rockets (and spacecraft) are launched vertically at an angle of 90 degrees to the horizontal and then maneuver in order to obtain the desired trajectory.  Finally, this simulation is strictly two-dimensional whereas real rockets and spacecraft travel through three dimensions and have to deal with things like atmospheric resistance, lift, drag, and variable gravitational fields.  These are subjects for future experimentation.

## The Spacecraft Coordinate System (Borrowed from Apollo)

Before simulating a spacecraft, we need to establish certain conventions that serve as an absolute reference for our position and attitude.  To this end, I’m planning to borrow the coordinate system used by the Apollo Spacecraft.

Using this model, we can describe spacecraft motion and maneuvers as either translation along a particular axis or rotation about one or more axes.

• Roll is described as rotation about the X axis.
• Pitch is described as rotation about the Y axis.
• Yaw is described as rotation about the Z axis.

Spacecraft attitude, then, can be described by giving three angular measurements that describe the current degree of roll, pitch, and yaw. Likewise, we can describe rotation or tumbling of the spacecraft as a series of vectors that describe the rate at which the spacecraft is revolving about each axis.

Translation of the spacecraft along a particular axis describes how the overall mass of the spacecraft is moving – regardless of attitude.  In the initial boost phase following launch, the principle motion of the spacecraft is “upward” – describing positive translation along the X axis. Likewise, the force of gravity is found acting in opposition to thrust along the X-axis.  Wind can act upon either the Y or Z axis and cause the craft to deviate off course.

Shortly after liftoff, the spacecraft performs a roll maneuver to align the spacecraft on it’s heading relative to the Earth’s equator. Likewise a pitch maneuver marks the beginning of a gravity turn that allows the spacecraft to move in a particular direction as well as “up” away from the surface of the Earth. These initial maneuvers will determine the ballistic (and hopefully) orbital trajectory the spacecraft takes.

In order to describe the spacecraft’s absolute position and movement away from its point of origin, we need to measure its movement along each of the axes and maintain a record of its velocity along each axes.  We also need to estimate the current mass of the spacecraft to determine the properties of thrust and acceleration. Obviously, the mass of the spacecraft is constantly changing as fuel and oxidizer are expended. Likewise, the overall thrust of the craft is changing due to changes in atmospheric pressure and expansion of the gasses at various altitude.

Overall, our first task in simulating the flight of a spacecraft involves the integration of these and other parameters to describe the motion of the spacecraft.  Wherever possible, the mathematics will be simplified so that the Apple II Plus can calculate these values in real-time (or at least approximate them in real-time.)

## Retrochallenge 2016 / 10

Greetings, Retronauts!

As always, participation in the annual Retrochallenge begins with nostalgia for those computers whose time has come and gone; it usually ends as an exercise in masochism.

My goal, this time around, is to convince my aging Apple II Plus that it can simulate a spacecraft with some degree of fidelity.  Having said that, I’m setting my sights pretty low since I’m only seeking to simulate the flight dynamics and underlying physics of ballistic and orbital flight. Unlike Kerbal Space Program or the mighty (and inscrutable) Orbiter, I’m not looking for photo-realistic graphics or high-end animation.

The core of the simulation is a data structure representing the spacecraft’s overall status at a single point in time:  Three-dimensional coordinates for its present location, a set of state-vectors indicating its relative motion, and spacecraft attitude (roll, pitch, and yaw.)  Other information describing the vehicle status includes its internal and external environment, fuel and oxidizer status, electrical power system status, communication parameters, and general spacecraft “health.”  At the moment, I’m trying to develop a spreadsheet (in VisiCalc, of course!) that brings all this data together in a single place.  From there, actual software development begins — mostly in Applesoft BASIC but may also entail 6502 assembly language and FORTRAN (if I can get the UCSD Pascal System running on real hardware.)

Here we go!

## Determining the Altitude of a Model Rocket

Before we try and simulate a “real” spacecraft in flight, it might help to consider the problem of tracking a model rocket, or similar “simplified” ballistic problem. Using a single tracking station, with a known distance from the launch point, we can estimate the altitude using a single measured angle and some simple trigonometry:

When we code this particular exercise in Applesoft BASIC, we need to remember to convert our angles (typically measured using degrees) to radians by multiplying by PI/180.

``` 1000 REM SINGLE STATION TRACKING OF A MODEL ROCKET
1010 REM DETERMINES ALTITUDE BY MEASURING ANGLE AT
1020 REM APOGEE GIVEN A KNOWN BASELINE.
1030 TEXT : HOME : SPEED= 255
1040 PRINT "MODEL ROCKET - SINGLE STATION TRACKING"
1050 PRINT
1060 PRINT "DETERMINES ALTITUDE AT APOGEE GIVEN A KNOWN BASELINE AND SIGHT"
1070 PRINT "ANGLE AT APOGEE."
1080 PRINT
1090 INPUT "ENTER BASELINE (DISTANCE FROM LAUNCH PAD TO TRACKING STATION: ";B
1100 PRINT
1110 INPUT "ENTER SIGHT ANGLE (REF GROUND) AT APOGEE: ";A
1120 PRINT
1130 PRINT "THANK YOU."
1140 PRINT
1150 REM CONVERT DEGREES TO RADIANS
1160 LET PI = 22 / 7
1170 LET A = A * (PI / 180)
1180 REM NOW CALCULATE THE HEIGHT
1190 LET H = B * TAN (A)
1200 PRINT "THE ESTIMATED HEIGHT AT APOGEE WAS ";H
1210 PRINT
1220 PRINT "END PROGRAM."
1230 END```

The program works pretty much as expected – given a known baseline and several “convenient” angles, we get results that are both intuitive and mathematically correct.  As long as the rocket’s flight path is perfectly vertical, we obtain a good approximation of the altitude at apogee.

Since it’s unlikely that an Apple II computer will be portable enough to drag along on a rocketry field exercise, a better approach to this particular problem might be to create a table of baselines and sight angles that can be printed and carried afield when launching rockets.

``` 1000 TEXT : HOME : SPEED= 255
1010 PRINT "TABLE OF ALTITUDES FOR MODEL ROCKETRY:"
1020 PRINT
1025 PRINT TAB( 17);"BASELINE"
1030 PRINT "DEG","100","200","300","400"
1040 FOR I = 0 TO 79: PRINT "=";: NEXT I
1050 FOR A = 5 TO 85 STEP 5
1055 PRINT A,
1060 FOR B = 100 TO 400 STEP 100
1070 LET A1 = A * ((22 / 7) / 180)
1080 LET H = B * TAN (A1)
1100 LET H = INT (H)
1110 PRINT H,
1120 NEXT B
1130 NEXT A
1140 END```

A screenshot of the table-formatted output is shown below.  This can be easily printed on a half-sheet of paper and carried into the field.

## Warming Up for the Retrochallenge

Simulating a spacecraft — or more accurately simulating spaceflight — will involve any number of astronomical calculations.  At the minimum, for a simple simulation of a ballistic or orbital spaceflight, one must solve the “two body problem” when finding the spacecraft’s trajectory.  Long before Galileo, Newton, Copernicus, or Kepler dared to challenge conventional wisdom or the church itself, the clergy found themselves with a similar problem:  What is the date of Easter?

Easter is normally defined as the first sunday after the fourteenth day after the first new moon following the Vernal Equinox… Since the date of Easter is determined by the date of Passover and we’re mixing both a solar and lunar calendar (courtesy of the ancient Hebrews) with the modifications to the solar calendar courtesy of both Julius Caesar and Pope Gregory, the problem becomes one not only of Sun, Moon, and Earth but one of Political whim and Ecclesiastical dogma… Are we sure they didn’t have computers back in the middle ages?  Oh, yes!  They were called “Monks!”

Anyway, the best definition for Easter (and the means by which one can calculate the date) can be found in ‘The Explanatory Supplement to the Astronomical Ephemeris and American Ephemeris and Nautical Almanac.”  Otherwise, there are some nice tables in the ‘Book of Common Prayer (1662)’, and an algorithm found in ‘Butcher’s Ecclesiastical Calendar’ published in 1876.  A variant of this algorithm, prepared for use with a handheld calculator, was printed in ‘Practical Astronomy with Your Calculator’ by Peter Duffett-Smith in 1979.

Applesoft Source Code Follows:

```]LIST

1000 REM FIND THE DATE OF EASTER
1010 REM WORDS FOR ANY YEAR IN THE GREGORIAN CALENDAR FROM
1020 REM 1583 ONWARDS
1030 REM
1040 REM ALGORITHM IS TAKEN FROM THE BOOK 'PRACTICAL ASTRONOMY
1060 REM 1979 BY CAMBRIDGE UNIVERSITY PRESS.
1070 REM
1080 TEXT : HOME : SPEED= 255
1090 PRINT "CALCULATE THE DATE OF EASTER:"
1100 PRINT
1120 PRINT
1130 IF Y > = 1583 THEN 1170
1140 PRINT "SORRY, YEAR MUST BE GREATER THAN 1583."
1150 PRINT
1160 GOTO 1110
1170 LET A = Y - ( INT (Y / 19) * 19)
1180 LET B = INT (Y / 100)
1190 LET C = Y - (B * 100)
1200 LET D = INT (B / 4)
1210 LET E = B - (D * 4)
1220 LET F = INT ((B + 8) / 25)
1230 LET G = INT ((B - F + 1) / 3)
1240 LET H1 = 19 * A + B - D - G + 15
1250 LET H = H1 - ( INT (H1 / 30) * 30)
1260 LET I = INT (C / 4)
1270 LET K = C - (I * 4)
1280 LET L1 = 32 + 2 * E + 2 * I - H - K
1290 LET L2 = INT (L1 / 7)
1300 LET L = L1 - (L2 * 7)
1310 LET M = INT ((A + 11 * H + 22 * L) / 451)
1320 LET N1 = (H + L - 7 * M + 114)
1330 LET N = INT (N1 / 31)
1430 LET P = N1 - (N * 31) + 1
1440 PRINT "MONTH: ";N
1450 PRINT "DAY: ";P
1460 PRINT
1470 PRINT "END PROGRAM."
1480 END

]```

## The Apple II Plus

What can you say about the Apple II Plus that hasn’t already been said?  6502 Microprocessor, 48k RAM (Plus 16k RAM bank switched into the ROM address space for the “language card), AppleSoft in ROM, DOS 3.3, UPPER CASE ONLY, 80-column text optional.  In short, I love the damned thing.

Unfortunately, mine has a flakey keyboard encoder, so reliability has become an issue with this favorite artifact of the 1970’s.   I’ve also noticed some problems with cassette I/O — but that could easily be the computer, the tape deck, or the tape itself… Cassette I/O was never known for either speed or reliability. 🙂

I’m told that some versions of PRODOS might actually be made to work on the II Plus.  This might be a fun, if pointless, endeavor for the long cool evenings this fall.

What I would really like to accomplish is to recover some FORTRAN programs I wrote on this machine back in 1981 and move them to a newer platform.  Since FORTRAN on the Apple II actually ran under the UCSD Pascal operating system (the compiler generated the same pseudocode as the PASCAL compiler), it’s always been a bitch to interchange data with either DOS or PRODOS.  I might have to try and get the p-System running on an emulator in order to exchange data in the form of disk images.  We’ll see!

## The Commodore VIC-20: 36 Years Later

Like many kids that grew up in the 1970s and 1980s, the VIC-20 was the first computer I actually owned, if not the first one I regularly used or programmed.  Mine came from Montgomery-Ward (a now-defunct department store and mail-order company that was the chief competitor to Sears and Roebuck for a century or so) and had been marked down to \$329 from it’s original price of \$499. Naturally, right after I got it, the MSRP was dropped down to \$299 and sold “on the street” for under \$200!  With no means of data-storage, there was an immediate need for some peripherals so I soon acquired the C2N Cassette Drive, the VIC-1525 Graphics Printer, and eventually a 1541 Disk Drive.  All told I had the full-on Commodore Experience as my main machine until 1985 when I received one of the original 128k Macintosh Systems.

I’ve had it out of the box a few times since then.  I had to show my kids what the term “gaming system” meant to me — they played the retro games for a few months and it went back into storage.  I dug it out for the Retrochallenge a few years ago.  Heck, I even pulled it out of storage so I could use the 20 ma Current Loop interface to read some punched paper tapes off the teletype!

Even as limited as the VIC-20 was, with its 22 column display and 5k (3,583 bytes free!) memory, it was still a REAL COMPUTER that was capable of serving as a word processor, programmable calculator, data terminal, and BASIC programmer’s workstation.  With a “shell account,” it is even possible to surf the net and do rudimentary email and such (but only if you’re a real masochist!)

In all honestly, the biggest limitation really is the 22 column display — I have RAM expansion packs that fill out the address space to a full 48k of RAM, just like the Apple II.  The printer produces reasonable dot-matrix output on standard 8.5 x 11 inch paper. The BASIC programming language is more than capable of handling any mathematical problem I might feed it.  Even communications on the VIC-20 are fairly painless, even though the emulated UART maxes out at 9600 baud on the “user port.”  It’s a handy little system that still gets me excited when I boot it up.

8-bits forever!

## More Trojans, Viruses, and Malware

Well, isn’t this just special!  I clicked through a facebook link to read whatever salacious bit of trivia the advertisers were posting and I get one of the (always charming) fake virus warnings.

Yep, complete with a convenient telephone number, Microsoft Logo, and all the particulars needed to either bilk me out of some hard-earned cash or allow some scumbag to access my computer and install some actual bullshit malware.  A closeup of the message box gives us the details…

This one is particularly cute, since it tries to give you a drive-by download (courtesy of Javascript) and won’t go away when you click the stupid x in the upper right corner. Instead, it just reloads the page and displays another identical dialog box. Any reasonable anti-virus software will stop it, even the freebie Microsoft Security Essentials, but it’s still a pain in the ass to get away from.

Needless to say, I didn’t call the number.  The 844 area code is a dead giveaway — that area code is reserved for toll-free numbers but is supposedly not currently assigned in the continental United States.  A quick look at the WHOIS data for hailwater.com also points us to mainland China instead of the good folks in Redmond, Washington:

```Domain Name: hailwater.com
Registry Domain ID: D400730592
Registrar WHOIS Server: Whois.domainerschoice.com
Updated date: 2016-07-05T20:30:05Z
Creation date: 2016-07-05T20:30:05Z
Registrar Registration Expiration date: 2017-07-05T20:30:05Z
Registrar: Nanjing Imperiosus Technology Co. Ltd
Registrar IANA ID: 953
Registrar Abuse Contact Email: abuse@domainerschoice.com
Registrar Abuse Contact Phone: +86.2584752360
Registrar Abuse Website: http://www.domainerschoice.com/report_abuse
Domain Status: ok
Registry Registrant ID:
Registrant Organization: WhoisGuardService.com
Registrant Street: Tian Hong Shan Zhuang, BLd. 7, Office 104
Registrant City: Nanjing
Registrant State/Province : Jiangsu
Registrant Postal Code: 210049
Registrant Country: CN
Registrant Phone: 86.2584752362
Registrant Phone Ext:
Registrant Fax: 86.2584752362
Registrant Fax Ext:
Registrant Email: abuse@domainerschoice.com
Admin Organization: Nanjing Imperiosus Technology Co. Ltd
Registry Tech ID:
Tech Organization: WhoisGuardService.com
Tech Street: Tian Hong Shan Zhuang, BLd. 7, Office 104
Tech City: Nanjing
Tech State/Province: Jiangsu
Tech Postal Code: 210049
Tech Country: CN
Tech Phone: 86.2584752362
Tech Phone Ext:
Tech Fax: 86.2584752362
Tech Fax Ext:
Tech Email: abuse@domainerschoice.com
Name Server: NS1.DNSSUPPORTPC.COM
Name Server: NS2.DNSSUPPORTPC.COM
DNSSEC: UnSigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
```

I suppose I could try and contact these folks and let them know about the scam, but it’s a fair bet that already know. Heck, it’s a fair bet that these particular folks are getting paid by their government to spread the joy…

Anyway, on a Windows machine the best way to get out of this little trap is to give your computer the three-finger salute (CTRL-ALT-DELETE) and use the task manager to kill the browser.  If you don’t feel comfortable with the task manager, shutting down the computer may get you out of their clutches.  If you’re on a Macintosh or Linux machine, just laugh at the poor stupidity of the folks who bought a Windows machine and go about your business…

In any case, don’t call the number.  If you already screwed up and called the number, don’t pay the bastards anything.  If you let the nasty little hackers get into your computer, make sure you do some serious housecleaning before using the computer for any banking or personal business.  If you have any doubts about your ability to eliminate Malware, it might be time to consult a professional to wipe the machine and start over.

Incidentally, neither the local, state, or federal law enforcement types will be of much help… They might offer you a certain amount of “tea and sympathy” but until we’re actually in a position to permanently eliminate China, India, Pakistan, Nigeria, and all the other places that host these scammers, there won’t be any concrete progress in catching or punishing the bad guys.  It’s Piracy, plain and simple, but there’s nobody to enforce the laws on the high seas of cyberspace just yet.

In the mean-time, I have a simple message for the person at domainerschoice.com calling himself Stefan Hansmann  — Fuck off and die, asshole!

Micheal H. McCabe