Hi everyone, The Nostalgic Computing Center <http://www.nostalgiccomputing.org/> has a virtual PDP-8 running TSS/8 <http://www.nostalgiccomputing.org:8080/aterm.html?m=pdp8&t=PDP-8&r=24&c=80> in its collection. We use the SIMH PDP-8e emulator to support the machine, and we recently updated the machine to run the TSS/8 distribution created by LCM+L, found here on GitHub <https://github.com/livingcomputermuseum/cpus-pdp8>. The LCM+L distribution is slightly different from other TSS/8 distributions available on the web in that it provides some additional goodies such as ALGOL and LISP. The NCC demonstrates how various classic computers worked by providing automated scripts that interact with the machines in the collection. For example, to demonstrate each of the programming languages supported by a machine, scripts are provided to create, compile, and run a simple Fibonacci sequence generator. We've done this for the TSS/8 system, but the scripts aren't working for FORTRAN or ALGOL, and we're wondering if anyone on this list might know why. Specifically, in the case of FORTRAN, the compiler exits with an error code 6204. This occurs even when trying to compile trivial "hello world" programs, and it appears to occur in all other TSS/8 distributions we've tried as well (i.e., this particular problem is not unique to the LCM+L distribution). We haven't found error code 6204 specifically documented in the TSS/8 user/admin manuals, but the manuals do document other error codes in the 62xx range. Documented error codes in the 62xx range appear to reflect file I/O errors, so we're wondering if perhaps one of the files supporting the FORTRAN compiler is corrupt in all of these distributions. For example, here is a transcription of a simple session demonstrating the problem: .R EDIT INPUT: OUTPUT:FTEST A WRITE(1,10) 10 FORMAT(5HHELLO,/) END E ^BS .R FORT INPUT:FTEST OUTPUT: 6204^BS . We tried enabling the floating point processor to see if lack of FPP might cause FORT to abort, but enabling the FPP did not solve the problem. The SIMH configuration file for the machine currently looks like: set throttle 800K set df disabled set rf disabled set rk enabled set dt enabled att rk0 tss8_rk_lcm.dsk set cpu 32k attach ttix 4000 load boot.bin run 200 Note that BASIC, FOCAL, and LISP all seem to run very nicely on the machine. The problem we're experiencing with ALGOL appears to be a glaring compiler bug, but the compiler was distributed widely through DECUS, and it is difficult to imagine that it would have been released with an obvious bug, so we are wondering if perhaps we're not interpreting the user manual <http://svn.so-much-stuff.com/svn/trunk/pdp8/src/decus/8-213/decus-8-213.pdf> correctly. Here is a transcription of a session that exhibits the problem: .R EDIT INPUT: OUTPUT:ATEST A 'BEGIN' 'INTEGER' I; I := 1; WRITE(1, I); SKIP 'END' $ E ^BS .R ALGOL INPUT:ATEST OUTPUT: *TOO MANY UNDEFINED [UEXPRESSION* ^BS . The compiler seems to be complaining that the simple assignment statement on line 3 of the program is somehow incorrect. If we change the statement to "I := 1 + 0;", the error message goes away, and the program runs, but it prints "0" instead of the expected "1". Also, if we change the program to: 'BEGIN' 'INTEGER' I; 'FOR' I := 1 'STEP' 1 'UNTIL' 10 'DO' 'BEGIN' WRITE(1, I); SKIP 'END' 'END' $ it compiles successfully and it prints what is expected, the numbers 1 through 10. Does anyone have experience with the ALGOL/8 compiler? If so, does this behavior make sense, and can you let us know what we're doing wrong? Note that the same ALGOL60 program compiles and runs as expected on the CDC mainframes and the TOPS-20 system at the NCC. thanks! Kevin