NOTE: This page has not been updated significantly since 2004. There is a Romanian translation available thanks to the efforts of Alexander Ovsov.
There is an abundance of great software out there which the authors and copyright holders have made freely available to end users. Rather than duplicate effort, I try to use the standard tools whenever possible. Occasionally, there isn't anything out there that quite fits the bill. Here are some oddball tools which you may find come in handy if you can't get a more general tool to do the job quickly and efficiently.
Much of NASA and the commercial satellite industry works off of day of year dates rather than month/day dates for sequencing launches, scheduling tracking facilities, and other mission planning activities. When involved directly with planning on a regular basis, it is customary to carry around a "perpetual calendar", which is a single sheet of paper containing the conversion table. One side has the common year table from 1 to 365, and the other side has the leap year table from 1 to 366. Spreadsheets readily handle this sort of conversion.
As I often find myself without a "perpetual calendar" or spreadsheet program, but with my Hewlett-Packard 32SII programmable calculator, I wrote a program for the calculator which performs the conversion. The program implements equations from the book Astronomical Algorithms by Jean Meeus. Meeus attributes the forward conversion algorithm to the U.S. Naval Observatory, and the reverse conversion to a private correspondent in the Netherlands.
On the desktop machine, which is used for long-term planning and data analysis, the more complete Julian day number system common in astronomy comes in handy. This Perl script sits in ~/bin and converts between Gregorian calendar dates and Julian day number using three different algorithms. One algorithm is capable of converting fractional days, i.e. hours, minutes, and seconds, if optionally specified on the command line.
A set of style files for using the standard 45 scalable typefaces in the ROM of any PCL 5e or later high end printer. This package must be used with dviljk or a similar DVI to PCL driver to generate PCL from the DVI file that LaTeX produces.
To do list:
Few people have the need for exact color reproduction on their desktop, and most operate their displays in uncalibrated RGB mode, or assumed-calibration sRGB mode. A display color management API has been built into the X Window System since X11R5, but the documentation is scattered throughout the X distribution, and is rarely included in XFree86 distributions. Software is very difficult to use without proper documentation. Fortunately, there are many documentation archives available. Here is a collection to help the casual Xcms programmer.
Occasionally, for one reason or another, you may find it necessary or even enjoyable to work with outdated equipment. As Church's Conjecture appears to be true, we don't need to completely throw away the labors of the past when we get a new machine.
In 1945, while collaborating with Eckert and Mauchly at the Moore School of Electrical Engineering at the University of Pennsylvania, von Neumann wrote First draft of a report on the EDVAC. This document described the logical structure of a 32-bit, bit-serial architecture, and defined the concept of the stored program electronic computer. One year later in 1946, Burks and Goldstine, who had recently moved to the Institute for Advanced Study to join von Neumann's computer effort, published Preliminary discussion of the logical design of an electronic computing instrument with von Neumann as third author. This Burks, Goldstine, and von Neumann report described a 40-bit, bit-parallel asynchronous architecture. Most modern computers descended from this second report. The design is known as the Princeton or IAS architecture, to distinguish it from the Harvard architecture of Aiken's Mark I. von Neumann assembled a team at IAS to build the machine as outlined in the report. The progress reports of the IAS Electronic Computer Project were widely disseminated, resulting in the construction and installation of similar machines at six other institutions: Argonne National Laboratory (AVIDAC), Oak Ridge National Laboratory (ORACLE), Los Alamos National Laboratory (MANIAC), the University of Illinois (ILLIAC), the Ballistic Research Laboratory at Aberdeen (ORDVAC), and RAND Corporation (JOHNNIAC) [the JOHNNIAC is currently on exhibit at the Computer History Museum in Mountain View, California]. ORDVAC and ILLIAC were built at the University of Illinois, and then ORDVAC was shipped to Aberdeen Proving Ground. ORACLE and AVIDAC were built at Argonne, and then ORACLE was shipped to Oak Ridge.
One striking difference between the 1946 Burks, Goldstine, and von Neumann report and modern architecture manuals is the absence of the machine code, or instruction layout. Today new architectures are simulated on existing machines, so the instruction set is finalized and documented before hardware implementation begins. The Electronic Computer Project team at the IAS did not have a machine on which to simulate their proposed architecture. The actual instruction set was finalized during implementation. The IAS machine went on line in 1952. Vague descriptions of the implemented instruction set were published in the open literature by Estrin during the machine's first year of operation. In 1954, Goldstine, Pomerene and Smith published Final progress report on the physical realization of an electronic computing instrument, which lists the instruction set implemented in the IAS machine.
As the actual instruction encoding was not released until eight years after the original report, each implementation of the IAS 40 bit architecture had a unique and incompatible instruction set. The links below lead to documents which contain the instruction set encoding for each particular implementation of the architecture.
Other resources for 40 bit IAS architecture machines include:
The IBM 704 was the first commercially available scientific computer with a hardware floating point arithmetic unit and set the standard for scientific programming in the 1950's. It remains interesting today for several reasons, first, its lingering influence on programming language structure, and second, its user community and the programming tools developed and distributed by that community.
The CAR and CDR assembler subroutines are the famous examples from Lisp history. For the listing of these two subroutines, see Writing and Debugging Programs by Steve Russell (MIT AI Lab Memo AIM-6). Fortran was developed as the scientific programming language for the 704, and many of the boundaries of the fixed-form source code input format are due to the peculiarities of the 704 architecture. The 36 bit word machine could only load two binary words from a puch card card row into memory, which corresponded to the first 72 columns of a standard 80 column row. The 704 used 6 bit BCD character encoding, with 6 characters to a word. As the machine was word addressed, not character addressed, it made sense to limit labels and variable names to 6 characters. Hence labels and the continuation character made up the first 6 columns of an input card, and variable names were limited to 6 characters. The 704's three index registers and lack of indirect addressing made multidimensional arrays the dominant data structure.
The 704 resulted in the first computer user group, SHARE, forming in the southern California aerospace industry (modern incarnation). SHARE members developed a common assembler, SHARE assembly program or SAP, for exchanging subroutines and program libraries. Large quantities of SHARE software still exist in machine readable form, thanks to Paul Pierce's diligence. The first tapes in the SHARE codebase, consisting of the assembler and library subroutines dating from 1955-1957, probably represent the oldest machine-readable, community developed programming system in existence. IBM's commercial scientific assembler (Fortran II Assembly Program, or FAP) was modeled after SAP.
IBM's follow-on scientific computing systems, the tube logic 709 and transistor logic 7030 (STRETCH), 7090 and 7094, mostly retained binary compatibility with the 704. SHARE went on to design an entire operating system for the IBM 709 (SHARE Operating System, abbreviated SOS) [Shell, D.L., et al. The Share 709 System. (six papers). Journal of the ACM, Vol. 6, No. 2, 1959, pp. 123-155]. For System/360, IBM finally broke hardware compatibility and went with an emulation solution for older scientific applications.
The SHARE programs were distributed mainly in BCD source form, but some of the routines are in column binary format. The disassembler will convert 160 bytes of standard input, representing a column binary card image, into human-readable form. The disassembler first prints an ASCII representation of the holes on the card, followed by the binary disassembly.
Atlas is an emulator for the Univac Scientific 1103A. In addition to implementing all 41 basic instructions of the CPU, including repeat (RPjnw), Atlas also simulates the program interrupt feature. The emulator runs as an interactive, command line program and interprets binary 1103A machine code stored in simulated core/drum memory. Facilities provided by the emulation include direct entry of machine code in octal form, breakpoints, disassembly, and manual step debugging. Simulated input/output devices include a paper tape reader, a paper tape punch, and an electronic typewriter.
The emulator is written in C and should be portable to a large number of UNIX systems. It requires a compiler that supports two C99 extensions to the C89 standard: 64 bit integers (unsigned long long) and C++ -style comments (//). The emulator currently runs on Linux (gcc or Intel cc for IA-32), SunOS (Sun cc or gcc for SPARC), and Darwin (gcc for PowerPC).
An emeritus member of the department faculty came around one day with a 3.5" floppy disk full of BASIC programs from the Hewlett-Packard Integral Personal Computer. 1985's Integral PC was the last in a line of personal computers produced by the Corvallis, Oregon division of HP which was most famous for developing the hand held programmable calculator products from the mid 1970's to the mid 1990's. The earlier Series 80 desktop workstations, circa 1980-83, used custom HP 8-bit microcontrollers originally designed for the calculator market, and booted directly into a BASIC interpreter via ROM as did many 8-bit computers from that era. The Integral PC used a 16-bit Motorola 68000 and booted into UNIX (HP-UX 5.x) from a rather large 512k ROM. The Technical BASIC package for the IPC was designed to be source compatible with Series 80 BASIC.
The Integral PC formatted 77 cylinders on a disk. I was able to use a standard floppy drive on a PC running Red Hat Linux, setfdprm(8), and the following /etc/fdprm entry to dd the floppy to a disk image.
# HP Integral Personal Computer hpipc 1386 9 2 77 0 0x2A 0x02 0xDF 0x50Disk image generation:
setfdprm /dev/fd0 hpipc dd bs=9k count=77 if=/dev/fd0 of=disk.img
Once in the form of a disk image, Peter Johnson's IPC utilities compiled on an HP 9000/782 (C240) PA-RISC workstation running Debian Linux were used to extract the individual files from the Integral PC's hierarchical file system. Any big endian machine would have worked with Peter's utilities, which were originally developed on the SPARC running Solaris.
As with most microcomputer BASIC interpreters from the 1980's, the Integral PC's Technical BASIC could SAVE programs in ASCII source form, or STORE them in the internal binary tokenized format used by the interpreter. Of over 130 programs on the disk, only two were SAVEd as ASCII. The loading speed and compactness of the binary tokenized format made it the logical choice for archival purposes.
Two of the programs on the disk were archived in both ASCII and binary tokenized format. Using these two programs, and a description of the original HP-85 BASIC format [N.A. Mills, H.C. Russell, K.R. Henscheid, "Enhanced BASIC Language for a Personal Computer," Hewlett-Packard Journal, Vol. 31, No. 7, July 1980, p. 26]. the following detokenizers were written.
These BASIC interpreters used a reverse Polish notation (RPN) syntax internally for each line in the source file. The detokenized output is presented in a verbose RPN with one token per line, rather than in infix notation with multiple tokens per line. The opcodes changed as the BASIC interpreter underwent revision and porting to each new machine, so opcodes appearing in one version of the detokenizer don't necessarily appear in other versions. As the nature of the available programs on disk was mathematical rather than I/O related, many of the I/O opcodes are not known. The detokenizers are far from complete, but provide enough output to be able to read the code and comments, and port programs to infix notation languages on a modern platform.
Newer releases of the interpreter for the later model machines were not capable of reading tokenized binary format from previous models. The code migration method supported by HP was through ASCII SAVEs and GETs.
My only home computing equipment for over a decade was a Digital Equipment Corporation VT220 compatible terminal (a GraphOn 230) attached to a modem. As 8-bit character sets came into use in the mid 1990's, the hardware terminal started showing its limitations. This Perl program converts a standard 6x10 X Window System font in Bitmap Distribution Format (BDF) to DEC sixel graphics and downloads the upper page to the terminal. The terminal can then be used with any of the standard ISO Latin 8-bit character sets.