Here's an example of what you can do with the Type 340 display

[Bill E]

Fun. But now the part that amazes me. Just as an experiment, I asked Claude/Sonnet5 to do this, telling it I wanted a 2d projection of a 3d wireframe cube viewed from a perpective at an altitude of 30 degrees rotating in 2 axes. And it did it, understanding the PDP-1, Type 340 and how to program it, and how to use am1. After saying it was a simple task, and very in line with 1960's graphics demos. I know how this ends, I saw the movie.

Bill

[Bill E]

Oh, it also built am1, assembled the program with it, checked the listing to be sure its program generated what it thought it should. I didn't tell it how to do anything, just gave it the description of what I wanted.

Bill

[MICHAEL GARDI]

Very impressive and scary. I am curious about the code emitted. Did it model the cube and add transformation and projection code to render the images or did it do the math behind the scenes and emit just the drawing code?

Mike

On Wed, Jul 1, 2026 at 9:46 AM Bill E <wjegr...@gmail.com> wrote:

Fun. But now the part that amazes me. Just as an experiment, I asked Claude/Sonnet5 to do this, telling it I wanted a 2d projection of a 3d wireframe cube viewed from a perpective at an altitude of 30 degrees rotating in 2 axes. And it did it, understanding the PDP-1, Type 340 and how to program it, and how to use am1. After saying it was a simple task, and very in line with 1960's graphics demos. I know how this ends, I saw the movie.

Bill

--
You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-1/775afcb2-7548-4c16-9d03-167e1863997bn%40googlegroups.com.

[Bill E]

It went through an initial design analysis and decided that computing on-the-fly using mul/div might be too expensive, so it precomputed all the t340 vector commands. Then in the main loop, it modifies the t30's program on the fly to point to the correct vector set, a classic use of pdp-1 self-modifying code, which it also pointed out in its analysis. Maybe even scarier.

I'm adding the program to the demo set.

Bill

[MICHAEL GARDI]

Very cool. Self modifying code is just a way of life on the PDP-1. Given the speed I suspected there was some pre-computation happening. 

Mike

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/ba099b1d-723d-4ad6-8d1c-c75eb7cceaa9n%40googlegroups.com.

[MICHAEL GARDI]

In addition to using much self-modifying code, the early PDP-1 pioneers also conceived of JIT compilers. When I was working on RIPOFF for the PDP-1 I learned that there are five distinct spaceship shapes in Spacewar!. The "outlines" for each was stored as data points, which were used at runtime to generate highly efficient code for displaying the ships on the screen.  Here is a sample of some generated code from my game. The Spacewar! code generated the opcodes directly into memory once when a ship was initialized. A few notes.

• The starting coordinate for the shape is loaded into the AC and IO registers in "screen" format. The X and Y positions are stored in the upper 10 bits of the registers as values between -511..512.
• Each block of code after that applies an accumulative offset to that initial point.
• The offsets are also in screen format and are pre-calculated based on the rotation of the shape.
• swap is a macro that switches the values in the AC and IO registers.
• disp is a macro to display a point on the screen; it expects X to be in AC and Y to be in IO.

This code is very efficient mainly because X and Y remain in the two (and only) PDP-1 registers without ever needing to be saved off to memory.

dtk, dap rox
     lac \px          / Starting point.
     lio \py         

     / Sprite code.
     / y=2, x=2
     swap
     sub \cn2
     add \sm2
     swap
     add \sn2
     add \cm2
     disp

     / y=4, x=0
     swap
     sub \cn4
     swap
     add \sn4
     disp

     / y=4, x=0
     swap
     sub \cn4
     swap
     add \sn4
     disp

     / y=2, x=8
     swap
     sub \cn2
     add \sm8
     swap
     add \sn2
     add \cm8
     disp

     / y=0, x=4
     swap
     add \sm4
     swap
     add \cm4
     disp

     / y=0, x=-8
     swap
     sub \sm8
     swap
     sub \cm8
     disp

     / y=2, x=-4
     swap
     sub \cn2
     sub \sm4
     swap
     add \sn2
     sub \cm4
     disp

     / y=2, x=4
     swap
     sub \cn2
     add \sm4
     swap
     add \sn2
     add \cm4
     disp

/ ...etc.

Mike

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/ba099b1d-723d-4ad6-8d1c-c75eb7cceaa9n%40googlegroups.com.

[Bill E]

That's really clever. Self-modifying code was certainly good for some things, but of course couldn't really last given the move to shared code, timesharing, etc.

Bill

[Bill E]

Looking at this closely, this is very similar to what the Type 340 does in 'increment' mode, I'm guessing the 340 stole the idea. For it, each increment instruction can draw up to 4 pixels by moving up, down, left, right, or diagonally, drawing all 4 points in 6usec plus one 5us instruction fetch cycle, blazingly fast by the standards of the day.

The 340 character mode, corresponding to the Type 30's symbol generator uses the same basic logic. I have a test program that draws 11.000 chars/sec using the authentic timing.

Bill