Retrochallenge Day 21 — 75% Complete with Little Progress

The database called TapeStore is largely completed, built up from hundreds of audio and video recordings and comprising just under a terabyte of raw information.  I’ve worked a bit on getting everything organized, but in keeping with the Retrochallenge Theme I need to be able to locate and recall that information in a manner usable on a vintage computer system.  Sending streaming video to a Commodore VIC-20 over a serial link is probably impractical, given the low data rate and tiny memory, but can actually be accomplished if we treat the TapeStore server as a peripheral and transmit our program content using standard video and audio cabling to a second monitor connected directly to the TapeStore System.

What I envision at this point is sitting at the console of my VIC-20 (or any other 8-bit antique) and requesting a particular audio or television program from the TapeStore server.  TapeStore checks its table of contents, and if the program is available begins playback over a standard video and audio link.  It takes an extra monitor and some ancillary equipment but what we have is a version of YouTube circa 1984.

Right now, the plan is to move the TapeStore drives to a Linux system that supports serial terminals and allows shell access via a terminal program running on the vintage PC.  Server-side programming accepts the program request and begins playback using dedicated video and audio links to a second monitor located adjacent to the 8-bit console.  If I can figure out how to generate a plain-old NTSC video signal on TapeStore, the server software should be a small matter of programming.  In the end, all we have is a high-capacity and overly complicated VCR that runs under programmed control, but it’s a neat hack and worthy of the Retrochallenge.

I have nine days to implement this.  See you soon!

 

Day 13 — Compact Cassettes Getting Loaded

The number of different media types here is overwhelming… My project started with the Digital-8 Videotapes because of the ease in converting the digital video stream on the tape into a digital stream on disk. Likewise, the 9-track tapes were easily copied from tape to disk-images using the Linux DD command-line utility. Making sense of the data might take a bit longer in some cases, but most of the 9-tracks contained TARballs from earlier incarnations of the Unix Operating System, so decoding them won’t present much of a challenge.

2017-04-13-143801 2017-04-13-143810 2017-04-13-143816

I’ve now moved back into conventional analog media — in this case, audio cassette recordings.  I’m using Audacity to record them to disk and generate MP3 files, but the sheer number of audio cassettes (and a few reel-to-reel tapes that I’ll convert with the same setup is pretty daunting.  I’ll start with this “small batch” of 100 tapes or so, and work my way through the library given time.  I probably won’t get through everything in time for the retrochallenge deadline.

 

Retrochallenge Day #4

The TapeStore project is moving along slowly. I’ve managed to digitize and upload the first 22 8mm tapes from the Sony Digital Handycam and fill about half of my first 500 GB Hard Drive.  While uploading the tapes, I’ve been taking notes and plan on starting my index database soon.

The next phase of the project will be to dig out the Ampex VPR-80 and Time-Base Corrector so that I can digitize and upload the dozen or so 1″ C-Format tapes in the collection. Some of these are edited copies of stuff that was sourced on the Digital-8, so you’ll see a certain degree of duplication.  Moving several hundred pounds of vintage video gear is a project in-and-of itself and I plan on filming the operation. Stay tuned for more video updates from Paleoferrosaurus.

 

Digital – 8mm Videotape (Sony Handycam)

Scanning the first few tapes is going well, but it seems I’ve vastly under-rated the amount of online storage I’m going to need to pull off the entire TapeStore Database.  I started with a 500 GB media drive on the video acquisition system in addition to the “native” 140 GB Windows volume.  This is on a “vintage” PC from 2007 (at 10 years, it actually meets the criteria for the Retrochallenge!) running Windows VISTA.  While scanning the 8mm videotapes, I’ve been looking at other media; the VHS tapes are relatively low-res so I’m not worried about the filesize, but even with compression I’m going to be hard-pressed to store all the Ampex videotapes on this system.  I haven’t even gotten as far as the 9-track stuff yet.

2017-04-01-154033

This screen-shot shows the directory listing for the first 16 tape cassettes.  Yes, I can count.  Tape 13 broke while playing, necessitating another file (AV8MM0014) to store the remainder of the tape.  I have another broken tape that’s going to need some TLC before I can scan it, so the day isn’t over yet!

2017-04-01-153920

This version of Windows doesn’t give you much of a preview while importing video, so an outboard monitor makes it easier to see what’s actually going onto the hard drive.  I’m also taking notes on the content of each tape while it’s uploading for the purpose of building an index to the content of each tape while building the TapeStore database.

Each file created from an individual tape gets a simple, systematic “name” describing the type of media stored therein.  This series is named as follows:

  • AV — For “Audiovisual” media
  • 8mm — for the source format
  • A unique sequence number

Thus, the first file in this series was AV8MM0001 and so on, leading up to the current tape, AV8MM0017.  Each tape has a general title, such as “Aurora Band Concert”, a series of named scenes, and notes based on content keywords.  I’m not sure yet how I’ll organize the rest of the database, but I’m hoping to come up with something that can link related documents in the grand scheme of things — I might want to find both the original “un-cut” footage and edited copies of a tape, for instance.

It might seem redundant when viewed in the context of a relational database, but I hope to keep much of the meta-data “built-in” to the directory structure.

Retrochallenge 2017/04

Greetings, fellow retronauts!

My project this time is called “Tapestore.”  It’s a small database containing large objects like operating systems, system images, video tapes, audio recordings, and photographs that are stored on a variety of media ranging from punch cards to 9-track tapes to various obsolete disk storage systems.  My goal is to put all this digital detritus into a form that can be stored and selectively retrieved on modern large-capacity hard drives but still be accessible to both archaic computer systems and modern emulators.

Vintage gear supported by this endeavor will include the Digital Equipment Corp. PDP-11, the Apple II+, Apple Macintosh, and Vintage PeeCee Type Equipment.  Work product will include source code, blog entries, and hopefully some video.


Recently, I was asked to provide a machine-readable copy of some documentation I wrote back in the late 1980’s.  The document was a set of programming specifications and a list of tone frequencies for the Zetron Model 25 encoder used at West County Fire Control in Girard, PA.  I knew right where it was and found it within a few minutes — wonderfully intact after all this time on a ProDOS data disk for the Apple IIe.  Sadly, I couldn’t find any quick methods for getting that data from a vintage Apple over to the Linux laptop for editing and transmission.  Yes, I have an Apple II emulator on the Linux box, but very little of the data I kept on floppy disks back in the day ever made it to the “new” computer.  Based on how you count the generations, I’ve had at least four generations of Apple computer, a few PeeCees, and three generations of Unix / Linux since that time.

The rest of the library isn’t in much better shape; there are punched paper tapes, C-Format Videotapes, Kodachrome slides, vinyl records, and DVD’s scattered all over the place and a host of different machines required to access the data.  What I really need to do is consolidate my stuff into a set of sustainable, current media formats that I can quickly locate and make use of without digging out the vintage Apple II or the Ampex VPR-80 and associated equipment.  Hopefully, TapeStore will be the answer.


The plan right now is to find some way of getting all this “stuff” into a format that can be stored on a current PC for safe, long-term storage, and ease of access.

In terms of video alone, I’m looking at several Terabytes of information, so while the number of entries in a “card catalog” might not be excessive, the actual content may prove to be rather enormous.  The first set of videotapes to digitize will be my Digital-8 “Home Movies” shot over the last 15 years.

These tapes were once the cutting-edge in home video production, with relatively high resolution NTSC video and good quality stereo sound.  The camera was also “computer” friendly with both USB and Firewire output as well as S-VHS and Composite Video connectors.

Sony_Handycam

The chief disadvantage to this camera is its age and the likelihood that a malfunction will render the tapes useless since I have no other device that can read the tapes.  The battery is also starting to show the limits of the “Infolithium” system favored by Sony in the first few years of the 21st century.

All told, I have perhaps thirty tapes in this format representing perhaps 25 hours of usable video.  Getting the video online isn’t much of a challenge, since the Firewire connection allows for rapid hi-quality transfer of raw data from the camera without need for extensive processing.  Storing the camera data in “AVI” format (Audio – Video Interleave) is relatively lossless but not very space efficient.   At around 13 GB per hour, I’m looking at around 325 GB for my Digital-8 Home Videos.

cassette

About Paleoferrosaurus

Context is everything.  For the few people on Earth that actually read this drivel, most will not know me personally.  We probably share some common interests that led you here, but sometimes a little bit of background information is helpful in interpreting what you find.

My name is Micheal Harve McCabe.  I’m presently 49 years old and live in northwestern Pennsylvania in the United States of America.  I’m married. I have three adult children.  I’m a graduate of Edinboro University of Pennsylvania.  If population demographics are an interest of yours, I’m a fat, middle-aged, white male. I’m not religious, and the current political climate of the United States disgusts me.

I am presently employed by two public-safety agencies in Erie County:  The West County Paramedic Association where I serve as an IT specialist and part-time paramedic; and the Central Erie County Paramedic Association where I serve as a full-time paramedic and general purpose technical wizard — involved in the care and management of computers, radio communications, and biomedical electronics.

I am a hacker and a tinkerer.  I write a lot of code for embedded devices that find use in communications equipment and medical devices.  Most of that stuff is pretty boring. The stuff that isn’t boring (from my perspective) are the “vintage” and “classic” computers that I tinker with and (occasionally) find useful applications for.

My hobbies include amateur radio (call sign: KB3NJY), model rocketry, firefighting, local history, and cellular biology.  I enjoy reading and writing both fiction and non-fiction.  I am sometimes employed as a teacher at the post-secondary level where I’ve taught classes as diverse as Medical Terminology, Human Anatomy, Medical Laboratory Practices, and Health Information Technology.

The content of this blog and associated web pages will reflect, to a greater or lesser extent, the total scope of my interests.  You will find articles on topics ranging from pre-hospital medicine to retrocomputing to railroad history and anthropology.  While I’m an expert in none of these fields, I tend to write whatever crosses my mind in a given moment.  As always, take everything with a grain of salt and consider the source!

Chest Pain / STEMI Candidate

The patient is a 66 year old white male presenting with substernal chest pain he rates an “8” on a 1-10 scale. He reports an acute onset at appx. 11:00 hrs this date while at rest.

The pain is described as a heaviness or “crushing” chest pain and is similar to pain the patient experienced during a prior heart attack. The patient states that the pain does not radiate, nor does anything make the pain better or worse. The patient denies SOB.

The patient has an extensive cardiac history with four prior stents.

Upon EMS arrival, patient is conscious, alert, and ambulatory. The pulse is 78 and bounding. Respirations are 18 and non-labored. The blood pressure is 160/78. The skin is pale, warm, and dry. Pupils are dilated and sluggish. Breath sounds are clear, present, and equal. Heart sounds are abnormal with a pronounced S4 Gallup. The pulse oximeter reads 98% on room air. The EKG shows a sinus rhythm with left atrial enlargement, a possible anteroseptal infarct, and ST changes suggesting and inferior wall MI.

Automated ECG interpretation software reports suspicion of an acute MI.

smaller_acute_mi

Treatment:

The patient was placed on the stretcher and moved to the ambulance. Med Comm was contacted and asked to relay the possible acute MI to <BLANK> Medical Center. An IV was established in the Left AC running Normal Saline TKO. Blood was drawn as per the ALS protocol. The patient was given 0.4 mg sublingual nitroglycerine at 1230 with a second dose of 0.4 mg given at 1236. The patient reports already having taken 4 x 81 mg Aspirin prior to EMS arrival. The patient was transported to <BLANK> aboard <BLANK> using lights and siren, arriving at the hospital within 20 minutes of leaving the scene. Upon arrival at <BLANK>, the ambulance was met at the ER door by Dr. <BLANK> and other members of the hospital staff. Verbal reports were relayed immediately while walking directly from the ER door to the Cardiac Catheterization Laboratory. The patient was directly transferred from the ambulance stretcher to the procedure table within the cath lab and the patient’s blood samples were relayed to laboratory staff at that time. Transport was without incident.

 

November 1, 2016 – End of the Retrochallenge

Once again, I’ve failed to accomplish much during the month-long celebration of Retrocomputing.  My Apple ][ programs can simulate simple ballistic motion and orbital insertion, but fail miserably when trying to realistically simulate Earth Orbit or (an order of magnitude harder) a transfer from Earth orbit to lunar orbit.  I can safely say I’ve reached the limits of my own understanding, if not the capability of the Apple ][+!

Looking at the other entrants, I’m amazed (as always) at both the breadth and depth of retrocomputing as a hobby!  Good luck to the judges when it comes time to pick a winner!

-Paleoferrosaurus

 

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:

orbital_mechanics

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.

rocketWeight – 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.

launch_of_friendship_7_-_gpn-2000-000686Friendship 7

Launch Date:  02/20/1962 14:47 UTC
Pilot:  John Glenn
Launch Vehicle Mass: 120,000 kg
Payload (Spacecraft) Mass:  1,224.7 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

2016-10-23-2 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