photo by Mike Cheponis
Mike Cheponis and I exhibited a GT40 running the Lunar Lander game at the
Vintage Computer Festival
on October 2 & 3, 1999, and
won the Best of Class award in the Minicomputer category.
It's fairly difficult to land the LEM; I've come close a few times but haven't yet succeeded. One VCF attendee was skillful enough to do it.
I'd also like to thank Doug Coward, Al Kossow, and Ken Sumrall for their help in making this exhibit a success.
photo by Doug Salot
Al and I showed the GT40 at the DECWORLD 2001 event on June 16, 2001.
Photo 1: The lunar module is controlled by a light pen, and is seen initially high above a lunar plane.
[Photo and caption from the article "Some Graphics Background Information" by Ira Jay Rampil (Department of Electrical and Computer Engineering, University of Wisconsin - Madison), from the November 1976 issue of Byte.]
On 12-Aug-1997, Jack emailed me with some interesting comments on the game:
On early (and mid) versions of the program, after planting the flag (or getting the cheeseburgers) and the LEM is ready to take off, if you hold the fuel at 0, the lander will "reland" itself. By doing this you would get more fuel. The reason is that to insure takeoff, the program automatically gives you enough fuel to get off. It does this by simply adding it on to what you have. If you repeatedly "reland" the craft, eventually you can get enough fuel to take off and explore for some time. Later versions had the take-off mechanism force the values, but these could still be overridden by diligently applying the lightpen. This is "relanding" was a bug found by Herb Jacobs.
You can go through the mountains on the left side if you have enough speed. And be inside the mountain. This is also another bug, because you can be travelling so fast that the collision detection routine does not detect to collision because you've already gone through the wall. No impact.
You can also land on the plateau on the left side of the mountains by going over them. This takes quite a bit of skill. Well, practice anyway.
The Spring 1980 RSX SIG tape contains various VT11 demos, including CRFWAR, a clone of Space War written in RT-11 Fortran. I have not yet determined whether this will run on a GT40.
I've recreated the GT40's bootstrap loader ROM source code from the listing in the maintenance manual. It doesn't match the ROMs in my GT40; I'm in the process of disassembling them and will present the results here when I'm finished.
John Holden has written gtencode.c (4.8K), a utility to convert programs in absolute loader format or XXDP binary format to suit the bootstrap ROM.
I have these documents:
I'm looking for copies of these documents:
|Listed in Maintenance Manual||Available Here|
|GT40 Quick Verify||MAINDEC-11-DDGTE-A||dgtec0.gt ( 10K)|
|GT40 Instruction Test 1||MAINDEC-11-DDGTA-A||dgtad1.gt (9.5K)|
|GT40 Instruction Test 2||MAINDEC-11-DDGTB-A||dgtbd0.gt (8.0K)|
|GT40 Visual Display Test||MAINDEC-11-DDGTC-A||dgtcc0.gt (7.3K)|
|DL11-E, C/D Off-Line Test||MAINDEC-11-DZDLA|
|ROM Bootstrap Loader Test||MAINDEC-11-DDGTD-A-D||dgtdc0.gt ( 10K)|
|GT40/GTP Overlay Program||MAINDEC-11-DDGTF|
|not listed||dgtgb0.gt (7.3K)|
|Part Number||Price||Keyboard option||8-hour Maint|
|GT40-AC||GT40-AD||$15,720||LT33 (ASR-33 Teletype)||$223|
|GT40-AE||GT40-AF||$16,795||LA30-C (DECwriter I)||$217|
The GT40-Bx models are equivalent to the -Ax models, but with 4K words of core rather than the standard 8K.
I don't have any information on the GT41, GT42, GT43, GT48, or GT60.
On 15-Aug-1994, Digital announced that the last service date for the GT40 was to be 31-Oct-1995. On 1-Jul-1995, Digital announced that the last service date for the VR12 and VR14 monitors was to be 31-Jul-1995, and the last service date for the VR17 and VR20 monitors was to be 31-Jul-1996.
Richard Shiffman at one time had this note on his web page regarding the VT11, VR17, and PDP-11/45:
While working on Danny Cohen's Flight Simulator program, ORLY, Mr. Shiffman observed that the VR17 display scope's power supply would be damaged if the PDP-11/45 did a bus reset and the scope's power left on for an extended period of time. The VR17 display is a random beam positioning scope with the physical origin (point 0,0) in the center of the screen, this is the point of least power consumption. The VT11 display processor had its logical origin at the lower left-hand corner of the display. This is the state of maximum power consumption for the VR17. This condition would occur every time there was a bus-reset on the PDP-11/45. The solution was to construct a circuit that would disconnect the outputs of the VT11 from the VR17 and ground the inputs to the deflection amplifiers when the VT11 was at its logical origin and idle. Now the VR17 would consume minimal power when the VT11 was idle.Even though the GT40 uses a VR14 and PDP-11/05, it is likely that the information is applicable.
Last updated October 12, 2002
Copyright 1996, 1997, 1998, 1999, 2001, 2002 Eric Smith