dungeon, or a Convoluted Case Study
Well, the first problem was that I didn't have a FORTRAN compiler. If one was available for the 3B1 at all, it was rare and hadn't gone down in price from the $8000-machine level; in any case, one never impinged on my consciousness. I did, however, have access to a Sun-3 with f77, which was close enough to be feasible and far enough away to be complicated. A 3B1 has a Motorola 68010 processor; a Sun-3 has a 68020, and its f77 still had a -m68010 flag to produce code that would run on a 68010-based Sun-2. From this point, it was clear that Something could be done.
No FORTRAN compiler means no FORTRAN runtime library, and that's going to be operating-system specific so the Sun's was of no use. However, the previous intrepid players who had initially wrestled the source into UNIX on a small PDP in 1981 had had to deal with that, as the game and the runtime library was too big a process for their system. They had split all the system I/O out into two helper C programs that connected to the game's standard input and output. That was still an option in the 1987 code, so with some surgery and fixing discrepancies between the FORTRAN and C code I had a complete single-process source with all I/O in C, which is what I had a compiler and runtime for. (This necessitated a “what's a 32-bit integer between friends” kludge noting that C file descriptors could be passed through FORTRAN unit numbers to the other C code as long as the FORTRAN code wasn't trying to actually present them to the system.)
Now it was time to actually work on compiling the FORTRAN side on the Sun. The BSDish Sun and the SYSV 3B1 were on different sides of the a.out/COFF object and executable format wars, so compiling the .F's to .o's would still leave a delicate conversion of symbol tables (but at least documented on both sides so feasible). Stopping the compile at the .s assembler level was better, but of course both the MIT and Motorola formats for 68k were represented (which sometimes have operands in different orders) as well as all the usual nuisancy differences in literal format and such between assemblers. But this was a brute-force string-processing operation with a few sed scripts and a small C program, and errors just meant it still wouldn't assemble. This also allowed munging the procedure names that bridged the language divide, adding underscores to make them match up.
At last the Sun had turned the .F's into .s's, and the 3B1 the modified .s's into .o's and the .c's directly into .o's and linked the whole mess into a native executable. All good preparation for playing the game with the same sort of end-around thinking.
(Crossing the divide with C source was generally much simpler, with a few standard things that had to be changed to the other flavor and some small compatibility libraries for BSD or SVR3 functions.)
Feel free to contact me, David Gesswein djg@pdp8online.com with any questions, comments on the web site, or if you have related equipment, documentation, software etc. you are willing to part with. I am interested in anything PDP-8 related, computers, peripherals used with them, DEC or third party, or documentation.
PDP-8 Home Page PDP-8 Site Map PDP-8 Site Search