Personal Computers – 25 Years and Counting – Part IV
October 6th, 2006 by xformed
Table of contents for 25 Years of Personal Computers
- Personal Computers – 25 Years and Counting – Part I
- Personal Computers – 25 Years and Counting – Part II
- Personal Computers – 25 Years and Counting – Part III
- Personal Computers – 25 Years and Counting – Part IV
- Personal Computers – 25 Years and Counting – Part V
- Personal Computers – 25 Years and Counting – Part VI
- Personal Computers – 25 Years and Counting – Part VII
- Personal Computers – 25 Years and Counting – Part VIII
- Personal Computers – 25 Years and Counting – Part IX
- Personal Computers – 25 Years and Counting – Part X
Part III told one story of automation at my training command (1st shore tour). This part is another way my hobby helped at work.
HP 7470A Two Pen Plotter
The “Training Aid Graiphics Generator” (TAGG) was spawned while I was at Dam Neck, because the support we got from the training support sucked. Need to be filled linked with supervisor upset no one seemed interested in getting the work done for his shop, so, off I went to fix the problem.
I arrived at Fleet Combat Training Center, Atlantic (FCTCL) in Sep 80. I was assigned to instruct the pre-Commissining crews of the PERRY Class frigates. When I arrived, we had the course material to teach the Baseline 3 program for the ships, which was also installed in our mockup. At the time, the Fleet was upgrading the systems at sea, and coming out of Bath Iron Works and Todd with Baseline 4. Big disconnect. We were saddled with teaching from “IGs” (Instructor Guides) that were now outdated, and running a mockup with software that wouldn’t ever be seen by the sailors we trained. Granted, it wasn’t a wasted effort, but certainly not satisfactory. For the first two weeks of the four week course, we taught the crews the console modes, which was done using slides depicting what they would see as they performed their functions. These, of course, were also outdated.
What to do? Well, get the materials updated. One part involved the updating of the entire set of IGs, to include the editing of the Terminal and Enabling Objectives. My shop got to work on this, and this part is fodder for a later sea story. The other part was getting the slides redone. Come to find out, the Naval Training and Education Support Center for this function is done by an office full of draftsmen (civil servants) all the way over at the Norfolk Operating Base (NOB) about 40 miles away. Time line to get it done? Somewhere between 6 months and a year. This young LT declared that unsat, and began figuring out how to tighten up the OODA Loop.
The answer came in the form of an (you guessed it) an Apple ][+ computer, with the addition of a Hewlett Packard HP7470A two pen plotter. I convinved the boss to get this very expensive equipment (around a grand for the plotter, and I got him to get us 2). Now, the problem was getting the new toy to draw our slides. Apple BASIC programming language was about all I knew, so I embarked on that journey to create a specific program, where an instructor could sit down and in a few minutes, be printing out a slide (on paper or transparency plastic). The other knowledge element was the language needed to “talk to” the plotter, HP Graphics Language (HPGL).
I didn’t realize, until 1993, the way I went about producing the program was very much in line with what became accepted as the process for developing a functional software package, and that story comes much later. I figured out the requirements, then I flow charted (some of it, I was bad about doing this part well), then began the coding process. I picked a lot of brains back then, the people of the Tidewater Apple Worms (discussed in Part II) was my brain trust and helped me over plenty of programming hurdles.
What I ended up with was a program that asked the operator what type display (the two variants of the tabular OJ-194 Tactical Data System Console were the Digital Display Indicator (DDI) and the Digital Read Out (DRO) type), and what tracks to display (up to 16 vehicular tracks or points). The tracks could be modified with overlaying symbology, such as engagement status, and course and speed vectors. I added “rules” that mimiced real world constrains, such as you could not engage a friendly vehicle, and onlyy one item could be shown as “hooked” (selected) into the program to help keep the display accurate. Two different slides would be produced for each teaching point, where one was the operator’s keyboard of Variable Action Buttons (VABs) to the left, with a 360 degree radar scope display, showing the selected TDS tracks/points, and the other slide was a DRO/DDI with the info from the tracks shown, above the upper half of the radar display. I had to program the entire set of TDS symbols into the program’s imbedded database, using the draw commands to talk to the plotter. I seem to recall that came to about 100 items.
Net result: An instructor could crank a slide out in about 10 minutes, either camera ready to take to the photo lab in Gallery Hall to make 35mm slides, or have a transparency for an overhead projector, all in color (I had programmed for multiple colors and prompted for pen changes, if required to complete the slide). It was, just a little faster than 6 months with the draftsmen.
I did find out that you could have program data encroach into your video memory area, as the Apple reserved enough memory for two pages of display, yet the operating system didn’t safeguard against variables and other stuff overwriting this area, when memory filled up. So, sometimes, you’d make a slide, then go to make another, and the video display for the computer was very strange, right before the program crashed.
I worked that program thru the 6 months after I left my assignment and went to my next school to tweak it to get rid of the errors in the video. It was a pretty stable program for those days, and I got it running pretty well and did my best to idiot proof it. I also prodcued a users manual, and kept my old command updated with new versions. TAGG was even flexible enough ti be used for any TDS console training, so it had a larger reach than just for the FFG-7 ships. The DD-963, DDG-993, CG/DDG and LHA training courses all could use the program, too.
This effort concluded when I submitted the program to the MILCAP program. Yes, I did the estimates for the cost savings ($13+/silde vs $1.40/silde (in 1983 $)) and computed many slides wold be made. The purpose of the MILCAP is to take an idea out of the trenches and put it into the lap of those who are part of the support mechanism, more equipped to smooth “it” up and do life cycle maintenance. And, if along the way, you save “them” (read taxpayers), they cut you in on a sliding scale, beginning roughly at 10%. As the Zenith Z-100 and Z-110 desktops were beginning to find their way into the offices, as a result of the USAF Contract, I had also taken the time to review the programming manuals and indicated I would make the necessary mods to allow the use of the program on those platforms. It was evaluated as very useful, and had been used extensively, and was aout to be used more, then it got buried because “we’re using Zenith computers now.”
Regardless, it took a huge load off a few offices of insturctors, while also taking the workload off an office full of draftsmen using hand cut out colored strips of plastic to make training aids and therein may have been the rub…
Next segment: The wonders of moving up to 64K (!!!) of memory, a Z-80 CPU card, dBase II, modems and a free copy of PASCAL.
This entry was posted on Friday, October 6th, 2006 at 11:59 am and is filed under History, Military, Military History, Navy, Technology. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.