Playable Version of Lunar Lander for the PDP-1 Uploaded

[MICHAEL GARDI]

Hi All,

I have uploaded the latest version of my Lunar Lander for the PDP-1 game to the development blog I have been keeping on Hackaday. You will find it in the files section.

I consider this to be a beta version of the code as there is still quite a bit of fit and finish work that I want to do like:

• Clean up the code.
• Performance improvements.
• Tune the game play parameters (if feels a bit to slow right now).

The code takes over 3K words of memory right now so I don't think that major features like scrolling terrain, and "zoom mode" on landing are in the cards but never say never, eh.  But don't let that stop you from making suggestions. 

I'm hoping that a few of you will give it a go and let me know what you think.

Mike

[Bill E]

I've downloaded the code, will give it a try soon. I'm impressed. I thought I was writing a lot of assembly code. Nope, not in comparison. I'm only up to a couple of k lines.

Bill

[Kevin McGrath]

Very nice!  I copied the code to my Windows machine, compiled it with macro1, slapped it on a thumb drive (aka modern papertape) and loaded it onto my machine and it ran just fine.  Actually quite challenging, I've only managed to land successfully once, but I was having a lot of fun trying to land, so nice work recreating the game!

What was your development cycle like?  You didn't do this all on machine in ET and MACRO, did you?  I got a kick out of building it and running it, felt very much like the old Creative Computing days, except with assembly and papertape, not BASIC and cassette tapes.  What did you find was the most challenging thing to implement?

Thanks again for sharing, this was a fun test of my newly built machine.

-Kevin.

[MICHAEL GARDI]

Thanks Kevin. I am having a lot of fun with this project.

At the very beginning I did enter and run the little CIRCLE program with ET and MACRO. It gave me a whole new appreciation for the amount of effort that was required in the early 60's to write and execute programs, let alone one with the complexity of Spacewar! I wonder how much blank paper tape cost back then because they must have burned through a lot of it. Also I imagine that they got pretty good at applying patches to the code directly on the PDP-1 to test little fixes before they did another iteration. 
 

At any rate I did most of the development on the Pi via VNC from my laptop. I edited the code using the default text editor (Mousepad) and assembled the code with macro1_1. Then I just loaded the rim "tape" via the Paper tape app and hit the physical READ IN switch on my Console. Here is my setup with my Type 30 display.

The biggest "challenge" I had was with the screen.  Type 30 displays by default are mapped with the origin at the center so:

                                   -512

                                       |

-512 ------------------------ 0,0 -------------------------- 512

                                       |

                                    512

(Now there is an option to relocate  the origin to the lower left corner of the screen but it is not yet implements on the PiDP-1.)

Furthermore the x and y coordinates that are passed to the dpy opcode have to be moved to the upper 10-bits of the word.  To make matters worse all numbers have to be converted to octal, and oh ya negative numbers on the PDP-1 are 1's compliment not 2's compliment. I gave me headaches.

Mike 

On Sunday, January 18, 2026 at 5:42:08 PM UTC-5 ke...@mcgrath.name wrote:

Very nice!  I copied the code to my Windows machine, compiled it with macro1, slapped it on a thumb drive (aka modern paper tape) and loaded it onto my machine and it ran just fine.  Actually quite challenging, I've only managed to land successfully once, but I was having a lot of fun trying to land, so nice work recreating the game!

[MICHAEL GARDI]

Small correction:

                                    511

                                       |

-511 ------------------------ 0,0 -------------------------- 511

                                       |

                                    -511

[Bill E]

I have it running also, it's fun. Except I haven't wired up my controllers yet, now I guess I need to. I'm impressed with the text drawing.

And yes, the 1's complement stuff is really annoying. I had to jump thru hoops in my assembler to deal with the math operations such that they would give the 1's complement values.

Oh yes, it now has a place on my drum as one of my load-on-demand apps.

Speaking of text, there was a hardware addon for the type 30 that was a character generator, the Type 33 Symbol Generator.. That seems a good candidate for an IOT implementation. It would be faster than dealing with the text in user code, it uses dma if I remember correctly.  I'll put it on my one-of-these-days list, unless someone else wants to start writing impls for some of these things. It would be a bit harder than some of the others because the original had direct access to the display, which the pidp-1 impl wouldn't, it would have to tie in with the dpy iot logic. Possible but some research would be needed, and some internal emulator routines would probably have to be exposed to the -33 iot.

Bill

[MICHAEL GARDI]

For anyone that's interested, if you like Bill don't have your controllers yet, you can play the game from the from the TEST WORD switches. You just have to change the following lines in the code:

3/ jmp sbf / Ignore sequence break.
jmp a0    / Alternate start address, jump to a0. Use control boxes.
/jmp a1 / Alternate start address, jump to a1. Use test word controls.

Just comment out the a0 line and uncomment the a1 line then reassemble.

Use the three leftmost switches as rotate left, rotate right, and thrust in order. It's a bit awkward (well a lot awkward) but you would at least get to experience the game play.

Mike 

[Bill E]

One minor code comment, you explicitly disable sequence break via putting a jmp in location 3. There's no need to do so, it's off by default. More importantly to me, my program that sits in bank 1 and rotates thru programs on the drum every minute uses sbm to get the 1 minute interrupt from the clock. Fortunately, I overwrite locations 0-3 when I load a program from the drum before I turn control over to the program. The moral - if sbm is for some reason on, it's probably on for some reason. :)

Bill

[MICHAEL GARDI]

Interesting. Like with much of my code, I took my lead on the sequence break stuff, from Norbert Landsteiner's ICSS writeup and he copied it directly from Spacewar!.  (I checked spacewar_2b_25mar62.txt and yup it's there.)

/routine to flush sequence breaks, if they occur.

sbf,	tyi		/ reset console typewriter
	lio 2		/ restore io (fom contents of addr. 2)
	lac 0		/ restore ac (fom contents of addr. 0)
	lsm		/ leave sequence break mode
	jmp i 1		/ resume: indirect jump to address in loc 1

He seemed to imply that it was to handle the case where someone presses a key on the console.

Here, "sbf" is the first example of a label (it's 3 characters and followed by comma), marking the location of instruction "tyi". This one resets the internal state for the communication with the console typewrite (Soroban), because, it's 100:1 that — once again — someone couldn't resist to tap a key. 

Since my goal is to be as compatible as possible with the PDP-1 at the CHM, I'm going to leave it in, which won't matter since it's off by default anyway.

Mike

On Tue, Jan 20, 2026 at 12:37 PM Bill E <wjegr...@gmail.com> wrote:

One minor code comment, you explicitly disable sequence break via putting a jmp in location 3. There's no need to do so, it's off by default. More importantly to me, my program that sits in bank 1 and rotates thru programs on the drum every minute uses sbm to get the 1 minute interrupt from the clock. Fortunately, I overwrite locations 0-3 when I load a program from the drum before I turn control over to the program. The moral - if sbm is for some reason on, it's probably on for some reason. :)

Bill

--
You received this message because you are subscribed to a topic in the Google Groups "[PiDP-1]" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-1/ukB4cha73Ms/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-1+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-1/473bcdae-a198-4529-8a2e-8039f4e25370n%40googlegroups.com.

[Bill E]

That's interesting and amusing. Spacewar48 is what I run, don't know if it does that or not since I overwrite 0-3 anyway.

Why was this a concern? Interesting question. Tyi would not interrupt unless a tyi 400, completion pulse wanted, was done by something and sbs was enabled. Maybe part of the timesharing mods? Something else?

The PDP-1 handbook says that tyi i should not be used, not sure why:

When a typewriter key is s truck , the code for the st ruck key is placed in the
typewriter buffer, Progra m Flag 1 is set, and the type-in status bit is set to
one. A program designed to accept typed-in data would periodically chec k
Pro gram Flag 1, and if found to be set, an In-Ou t Trans fer Instruction with
address 4 could be e xe cuted for the informati on to be transferred to the In-Out
Register. This In-Out Transfer should not use the optional in- out wait.

BTW, afaik the -1 at CHM doesn't have any of the random mods other systems had. It's a pretty standard -1C.

Bill

[Norbert Landsteiner]

Regarding the sequence break trap, the historical reason for this construct is that this used to trigger the ddt online debugger.

Hitting the Soroban to divert a session of Spacewar! to ddt seemed to have been a favorite prank. So this is what must be the first anti-prank trap in game history.

(Contrary to common belief, there's sufficient memory left for Spacewar! to coexist with ddt in memory,. At least, if we set the config variable 'ddd' to 1, which will result in both players using the same outline – if I recall this correctly, it's the "Wedge" – so that only memory for JIT code for a single outline will be used, leaving the part of memory where ddt resides untouched. This also shows that this was a setup used frequently enough to provoke this response.)

Best,

Norbert

[Norbert Landsteiner]

Regarding using the test word for controls, there isn't any need to comment out and re-assemble. Just use start address 5!

3/ jmp sbf / (loc, 3) Ignore sequence break.
jmp a0 / (loc. 4) Alternate start address, jump to a0. Use control boxes.
jmp a1 / (loc. 5) Alternate start address, jump to a1. Use test word controls.

So start address 4 (default) jumps to configure the control boxes for input and start address 5 jumps to configure for using the test word.

It's a manually operated dispatch table! ;-)

(As usual, credit goes to Steve Russell et al.)

Best,

Norbert

[Norbert Landsteiner]

PS: A more elegant solution to use a game with this kind of start/configuration pattern with test word controls permanently is to specify start address 5 at the very end of the source before assembly.

As in,

   start 5

This instructs Macro (macro1.c) to use a "jmp 5" (instead of the standard/default "jmp 4") at the very end of the bin-loader process, where it diverts control to the program that was just loaded from tape. The obvious advantage being that this is still the same program and all addresses stay the same, just the bin-loader will  be modified.

Best,

Norbert

[MICHAEL GARDI]

I posted updated code to the Files section of the project on Hackaday. Not much is new except that I have been cleaning up the code and doing some optimizations.

One big change is that I have implemented a 50 "gallon" penalty for each crash. I walked away in the middle of a game once for a couple of hours and came back to find that I had racked up a pretty good score (2000+) because the LEM was in a crashing loop and received 5 points for each crash.  The penalty limits a score achieved this way to about 40 points.