Background of the Study
Fortran has began around late 1953 and early 1954 as a revolution in “automatic programming” in a day when code was written using mnemonic devices of raw assembly instructions [1]. To most it was believed that the inginuity of humanity was required to create efficient software. But after pulling all-nighters in the Langdon Hotel in spring 1956, John Backus and others managed to produce a working compiler in early 1957. About which John remarked
In spite of its continued development it has the reputation of a dated, obsolete language, used by perhaps only a handful of old developers. And yet Fortran is used extensively in many scientific contexts, in part due to inertia. If very efficient and complex code has solved a problem, why re-implement it again? One example domain is Quantum chemisty and solid state physics, where many CPU and GPU based software is still maintained in Fortran [5]. Another example are the excellent linear algebra routines and interfaces written in Fortran such as BLAS/LAPACK [6, 7] which have been the workhorse of many applications, including especially a lot of machine learning (although now of course new CPU/GPU libraries have been developed).
David’s first job after graduating from Harvard was as an Applied Mathematician in the Computing Laboratory of the Aberdeen Proving Ground, Maryland, during 1950–1951. His fellow co-workers included Samuel Conte, Charles Warlick, and Mario Juncosa, among others. During this time, David and Mildred purchased their first new house, and had their first son, William David. At that time, Aberdeen Proving Ground contained one of the largest collections of electronic computers in the U.S. They were employed in the Ballistics Research Laboratory, primarily for the calculation of bombing and firing tables. Some of the computers that were being used at BRL included the ENIAC, which was the first general- purpose electronic computer, the ORDVAC, which was designed by John von Neumann who often visited Aberdeen Proving Ground, the EDVAC, which was a rotating drum computer, and a Bell Laboratory paper tape-driven computer. David Young and Charles Warlick worked on the ORDVAC computer using Richardson’s method on a 21 x 21 grid, which required writing a tricky computer program, at that time, because the machine had a total memory of only 1024 40-bit words with no external memory.
The University of Texas in Austin wanted to establish a Computation Center. Professor Robert Greenwood, and others from the Department of Mathematics, wrote to David, inviting him to come to Texas. At first, David dismissed the offer, because he considered Texas to be an outback area of the country. Eventually, he decided to go and take a look for himself. He was pleasantly surprised to find that Austin was quite a nice city, with a river, hills, and oak trees, as well as having a good university. Lou Ehrlich followed David from Maryland to California to Texas, and became his first PhD student in 1963. In the summer of 1958, David moved his family to Austin-he would spend the rest of his career there. David and Mildred’s third child, Carolyn Ellen, was born in Austin.
In the Fall of 1958, David brought Bob Gregory to Texas to join him as a member of the mathematics faculty, and to help him set up the Computation Center-which was almost non-existent. David, Bob, and a secretary shared an office next to the computer room. The first computer was an IBM 650 Magnetic Drum Data Processing Machine, which was the world’s first mass-produced computer. During the next several years, Young and Gregory purchased new computers, expanded the staff, and designed a new building for the Center, which was built partially underground near the University tower. In 1965, David asked Charles Warlick to move to Austin, and to help him run the expanding operations of the Computation Center.
Under David’s leadership, The University of Texas not only built a new Computation Center building, but also acquired two large supercomputer systems-the CDC 1604 computer in 1960, and the CDC 6600 computer in 1966. Gregory was particularly interested in the CDC computers because of their long 60 bit word length. Based on his reputation, David obtained the first $400,000 grant, from the National Science Foundation, toward the purchase of the CDC 1604 computer, which was one of the first transistorized computers. The CDC 6600 supercomputer, which was one of the largest and fastest computers at that time, was purchased with the help of the first NSF million dollar equipment grant.
Literature Review
The skeleton of the Decwar-playing robots is turning out to have other uses. It’s now also the skeleton of an automated Tape Bridge between the local system and the DEC-10, in action within Project UTEXAS as tape.py in the msc folder.
The tape.py code automatically copies files from the local filesystem into the DEC-10 filesystem. It’s as quick and simple as possible, for doing fast iterations around editing local files using modern tools and then smoothly syncing those edits onto the DEC-10. It’s almost a fully automated filesystem sync between the local system and the DEC-10, and in fact could be made into such by scheduling periodic runs. It runs in the Docker container where the DEC-10 lives. The container is effectively an intermediary environment between the local system and the DEC-10. The local files are available live within the container and tape.py sees and copies them there. To use tape.py, work within a terminal session connected to the container. To schedule periodic runs for example, do that in the container, not in the local system. This is necessary because the tape drive and the mounted tape live in the container as part of the DEC-10, not in the local system. In other words, the hardware is in the container. The tape exists as a .tap file within the container’s environment, and meanwhile the local system is simply a place for using modern tools to edit source code.
Execution begins in the container, where tape.py creates a temporary folder and copies in all necessary files. It then executes back10, named after the DEC-10 backup utility, to convert the temporary folder into a tape image with the TOPS-10 tape format. This step generates a standard tape archive .tap file and verifies its integrity by listing its contents. If tape.py is executed with a –simple argument it terminates here, leaving the tape ready for use, and this is in fact the route taken during startup of the container when the tape is initially mounted on the drive. There is one tape mounted on the drive from container startup onwards. What tape.py can do at any time is replace the contents of the tape. One tape, many writes to it, many restores from it within the DEC-10. This one tape is the bridge between the local filesystem and the DEC-10, and many files can pass over it at various times during its lifetime. More tape drives and tapes are possible. One alone is minimalist simplicity.
When not in –simple mode the code transitions into the restoration phase, utilizing the pexpect library to establish a programmatic telnet connection to the DEC-10. With pexpect, the code sends text and monitors terminal output for expected responses. To the DEC-10 the code is indistinguishable from a human user telnetting in. The code is a robot and the overall setup is a kind of Turing Test. As long as the robot acts like a human, everything is fine. This system was developed from late 2024 for the Decwar-playing robots. The full Decwar robots are more complex, but the essential skeleton was directly adapted into tape.py in roughly an hours work. The robot opens a telnet connection and logs in, then uses the standard TOPS-10 tape utility BACKUP to restore from the tape. The tape.py code here is actually a guide on how to use BACKUP, for whenever a restore needs to be done manually. It then gracefully logs out and closes the telnet connection.
The UT Austin Decwar coders had to use MACRO-10 assembly to invoke specific TOPS-10 Unimplemented User Operations. UUOs acted as traps or interrupts that suspended user-level execution and called the TOPS-10 monitor. The monitor would then assert exclusive access over the magnetic-core memory high segment, queuing any other player-jobs attempting to write to the lists until the holding job issued an unlocking UUO. In other words, in order to use the shared memory linked lists for attack and radio messages, player-jobs had to call TOPS-10 directly via assembly code. This is the root reason that assembly code became essential for Decwar, and code in pure Fortran was simply no longer feasible. It unlocked the full potential of the DEC-10, and at the same time forever bound the code to TOPS-10.
There was very little separation between the game and the operating system, and little hope of moving the code to even a sibling environment such as the DEC-20 and its TOPS-20 operating system. Even though TOPS-20 ran on the same 36-bit hardware, it was derived from BBN’s TENEX operating system rather than TOPS-10, and it used a completely different system-call architecture known as Jump to SYStem instead of UUOs. While TOPS-20 did include a compatibility emulation library called PA1050 designed to intercept and translate old TOPS-10 UUOs into JSYS calls, this emulator had severe limitations. The PA1050 emulator was completely incapable of translating the direct physical segment locks and atomic inter-job synchronization routines that Decwar used to protect its message queues. Because the emulator relied on virtual memory page-mapping structures rather than static core segment locks, the Decwar binary simply could not run on TOPS-20 without a complete rewrite of its underlying assembly code.
The cancellation of the PDP-10 product line by DEC in 1983, and the demise of DEC itself in 1998, seemed to permanently strand the UT Austin Decwar code on an obsolete architectural island. But in another of its surprising near-death experiences, the UT code has survived and flourished in new forms far tougher and more survivable than before, through the physical and digital preservation efforts led by Obsolescence Guaranteed. The mid 2020s saw a spectacular revitalization of this ecosystem. Rather than treating historical computing as dead artifacts meant only for museums, Obsolescence Guaranteed, an informal group of computer history hobbyists and engineers, has focused on creating computer time capsules. By building affordable, fully functional hardware replicas of the classic DEC lineup, including the PiDP-1, PiDP-8, PiDP-11, and PiDP-10, they allow modern users to directly experience the tactile and interactive realities of the mainframe era.
For Decwar, the PiDP-10 replica is one form of resurrection. The PiDP-10 is a scaled-down, desktop-sized physical reproduction of the original PDP-10 KA10 front panel. It features an active array of 74 functional switches and 124 indicator lamps, driven by modern LEDs, that accurately reflect the machine’s internal state. Inside this console beats a dual-hearted system: a modern Raspberry Pi that runs a physical Linux kernel concurrently with a cycle-accurate PDP-10 emulator based on Bob Supnik and Richard Cornwell’s SIMH engine. Physical switch toggles on the front panel trigger interrupts on the Raspberry Pi, altering register states in the PDP-10, while memory writes are translated in real-time to illuminate the physical LEDs.
Another more permanent and accessible resurrection is represented by Docker. The UTEXAS DECWAR 2.3 Source Distribution Tape Reconstruction is a digital time capsule containing both the source code and the TOPS-10 environment. Docker excels at creating reproducible, automated build pipelines. A Docker image encapsulates the underlying SIMH emulator, the TOPS-10 operating system, and the SDT virtual tape into a single, isolated package. This guarantees that anyone can instantly spin up the living environment as it existed on the HRC DEC-10 in 1982, without worrying about local hardware dependencies or host operating system characteristics. In fact, running in the Cloud is no different than running on local hardware. The preservation efforts go far beyond running a single standalone mainframe. The ARPANET Reconstruction Project aims to revive the ancestral Internet using Old Bits wherever possible. For UT Austin this would mean containers for the HRC DEC-10, Painter Hall DEC-20, and ARPANET IMP, with various connections through telnet and FTP links. Docker, especially using Docker Compose, is explicitly designed to orchestrate multi-node, networked applications. Instead of a user manually launching and configuring separate environments for mainframes and IMPs, a containerized setup can automatically spin up each historical machine in its own isolated container and seamlessly manage the networking between them. Placing the SIMH PDP-10 engine, historical tape images, and disk images inside a container shields users from the friction of modern software dependencies. They don’t need to compile code or configure environments, but can simply start containers and immediately telnet into an Old Bits environment.
The simulation model can be described in two parts, static and dynamic. At a certain moment in time, all variables in the model have fixed states; under these conditions the model is static. If, however, more than one moment in time is considered, several model states are linked successively so that some of the output variables from one state become input variables to the next state and in this way the model becomes dynamic.
DECWAR is a dynamic (real-time) multiplayer game rather than a static (turn-based) one.
DECWAR is a real time space battle game designed to be played by from 1 to 18 people. The object of the game is to destroy all enemy bases and ships, and capture all enemy planets, before the enemy does the same to you. Each person plays on a separate terminal, and enters the game by typing R GAM:DECWAR Players are free to enter and leave the game as desired, since each has his own job and therefore won’t interfere with the other players (the jobs interact through a shareable high segment). The first person to run the game selects the startup options. The startup options are:
- Regular or Tournament game. A regular game randomly initializes the galaxy. A tournament game prompts for a startup code. Each tournament game played with the same code has the same initial galaxy setup. Answering with a defaults to a Regular (ie random) game setup.
- Include Romulans. Romulans are nasty beasts that beginners are better off without. However, if you’re the only person playing, the Romulan is your only competition. Romulans tend to make for shorter games, and answering with a defaults to include Romulans in the game.
3. Include black holes. Black holes are annoying, since if you are displaced into one, you’re dead. They also tend to gobble up stray torpedos. Answering with a defaults to NOT include any black holes. There are two primary opposing forces in the galaxy — Humans (Federation) and Klingons (Empire). As you enter the game for the first time, you get to choose which side you’ll join (unless there is a large imbalance in the team sizes). If you are subsequently destroyed and later reenter the game, you automatically rejoin your old team. You get to select the ship you want to control from a list of remaining ships on your side.
There are 9 ships on each side:
Federation ships Empire ships Excalibur Farragut Intrepid Buzzard Cobra Demon Lexington Nimitz Savannah Trenton Vulcan Yorktown Goblin Hawk Jackal Manta Panther Wolf
Due to continuous espionage activities, present front-line ships of the Federation and the Klingon Empire are identical in strength and weaponry. These ships can move from sector to sector using either warp or impulse engines, can attack enemy installations and ships using either photon torpedoes or phasers, and can defend themselves against such attack using their deflector shields. All ships also possess sub-space radios which keep them in touch with friendly starbases and other ships. The various devices of a ship are subject to damage. This damage may be due to enemy attack or to over use. These damages, unlike total ship damage (see ship attributes below), may be repaired while underway. If damage on a device is less than 300 units, its performance is degraded. If damage is 300 or more units, the device is inoperative. A ship possesses the following devices:
1. Warp Engines — These engines are the normal mode of trave l for starships. The maximum speed is warp factor 6, with warps 5 and 6 risking potential damage to the engines. If warp engines are damaged (less than 300 units) the maximum speed is warp factor
3. 2. Impulse Engines — These engines are basically for emergency use while the warp engines are critically damaged. Impulse engines move the ship at warp factor
1. 3. Photon Torpedo Tubes — Used to fire photon torpedoes. If these tubes are damaged, the accuracy of torpedo bursts is impaired. The maximum torpedo range is 10 sectors.
- Phaser Banks — Each ship possesses two phaser banks, with a single phaser control. Damage to this phaser control or to the ship’s computer reduces the strength of the phaser hit. 5. Deflector Shields — The deflector shields of a ship protect it from damage from phaser and photon torpedo hits, and shield it from the energy released when a star goes nova. The percent shield strength indicates the percent of the incoming hit which will be nullified. In addition, strong deflector shields may deflect photon torpedoes with little or no damage.
NOTE: If a ship’s shields are up, the amount of energy expended during movement is doubled.
6. Computer — The ship’s computer is used for computed firing, computation during ship movement, and for phaser control. I f the computer is inoperative, navigation during warp and impulse movement becomes inexact.
7. Life Support — If the life support units of a starship are inoperative, the ship must either repair this damage or dock within 5 stardates. If this is not accomplished, the crew will die.
8. Sub-Space Radio — The sub-space radio is used to communicate with other ships, of either side. Bases under attack also use the sub-space radio to call for help and notify their team’s ships of their destruction.
9. Tractor Beam — The ship’s tractor beam is used primarily to tow damaged friendly ships away from danger. The beam can not be used unless both ships have lowered their shields. In addition to the individual devices discussed above, a newly commissioned ship (or a fully repaired and rearmed older ship) possesses the following attributes: 1. 5000 units of ship energy. Ship energy is used during movement and phaser firing. It is also decreased each time the ship gets hit with phasers or photon torpedoes. If this quantity ever reaches zero, the ship is dead. A ship possessing 1000 units of ship energy or less automaticallУ goes to yellow alert, and a warning bell sounds after every move. 2. 2500 units of shield energy.
This energy is stored in the ship’s shields (whether up or down), and is separate from the ship energy. However, energy may be transferred between these two energy reserves as needed. If shields are up, their energy is decreased each time the ship gets hit. 3. Zero units of ship damage. During battle, a ship collects hits from enemy installations and ships. If these accumulated hits ever reach 2500 units of damage or greater, the ship is destroyed. Ship damage may be reduced only by docking. The galaxy is arranged in a grid of 75 by 75 sectors. Players can move freely throughout the galaxy in search of enemies, which come in several categories:
1. Romulan. This can be the most dangerous thing to come up against, and fortunately there is a maximum of 1 Romulan in the game at any given time. The Romulan moves around concealed by his cloaking device until he comes across a suitable target (Federation or Empire ship or base) which he immediately proceeds to attack. An infinite supply of torpedoes and energy make him a formidable foe. If you kill one, another will eventually appear somewhere in the galaху.
2. 3. Enemy ship. This is the second most dangerous thing to come across, since all enemy ships, are backed by human intelligence. All ships are created equal, and so the outcome of a clash between two ships is usually due to skill on its captain’s part, although some other factors do come into play. Enemy base. These aren’t dangerous unless you come within range 14 sectors) since they are immobile. If you ARE foolish enough to get within range, however, their overwhelming phaser power will quickly pound you into rubble! Destroying a base is useful primarily because this removes it from use by your enemy (bases are used as supply stations and as a refuge in times of stress). A damaged starbase will slowly build itself
stress). A damaged starbase will slowly build itself back to full strength if it is not completely destroyed.
4. Enemy planet. These are just like enemy bases, except that they are weaker (how much weaker depends on how many fortifications the enemy has built on them), and they can be captured. Their firing range is only two sectors, and they can re-supply the enemy less rapidly than can a base.
5. Neutral planet. While these aren’t strictly classified as enemies, they will take pot shots at you (their range is also 2 sectors), so be wary of them. You can capture neutral planets and win them over to your side.
When playing the game, all commands can be abbreviated to 2 characters, and some can be abbreviated to 1 character (you can use the shortest unambiguous abbreviation). For a list of commands typе and HELP * for a description of an individual command tyуpe HELP command The help on individual commands will be read from this help file (that’s what the periods in column 1 are for in the long description of each command). The legal commands are:
1. BASES — List information on friendly and known enemy bases.
2. BUILD — Develop installations on a planet, and eventually build it into a base. The planet must first be captured.
3. САРTURE — Win a neutral or enemy planet over to your side.
4. DAMAGES — List damaged devices and their current status.
5. DOCK — Dock at an adjacent base or planet. This increases your energy, replenishes your torpedoes, repairs your ship a little, and reduces your ship damage.
6. ENERGY — Transfer energy between two ships.
7. GRIPE — Record bugs, comments, suggestion, etc. in the file GAM:DECWAR.GRP, which is periodically reviewed by the implementors.
8. HELP — List or describe the legal commands•
9. IMPULSE — Move using impulse engines.
10. LIST — List various information about ships, bases, and planets.
11. MOVE — Move using warp engines.
12. NEWS — Tell about any new features or enhancements described