Is there a PDP-1 programming style / how to guide?

[Carlo Valpiani]

Hi,

I was wondering if there is a pdp-1 programming style guide as a beginner's guide? 

There are a number of instruction lists but I am looking for something that includes things like how to program subroutines, temporary variables without a stack, how to create / populate tables, how to random access tables, how to perform non-trivial computations given a single accumulator load/store architecture, best ways to write self-modifying code, how to use dynamic IOTs and interrupts rather than how to write a dynamic IOT, etc.

Re-inventing the round thing with a hole in the middle with documentation spread wide is non-trivial. 

Carlo

[MICHAEL GARDI]

Hey Carlo,

While I'm not aware of a "cookbook" style document for the PDP-1 I can tell you what I did to get up to speed with the PDP-1 instruction set. I copied the following excerpt from my own Lunar Lander for the PDP-1 blog.

I wanted to write some PDP-1 code but didn't know where to begin. The Obsolescence Guaranteed folks have a PROGRAMMING THE DEC PDP-1 - A QUICK WAY TO GET STARTED guide.  It's great, but it mostly focuses on using the tools they have provided as part of their distribution (lovingly recreated from original 60s source code) to build an assembly language program and run it on the PDP-1 using a simple circle program as an example.

When I posed the "How do I get started?" question on the PiDP-1 Google Group Oscar pointed to this document, Retrochallenge 2016/10: Ironic Computer Space Simulator (ICSS). Boy was he right. This link documents Norbert Landsteiner's entry to Retrochallenge 2016/10, where he implements a version of Computer Space on the PDP-1. Computer Space was the very first coin operated video arcade game introduced by Nolan Bushnell in 1971.

After a short overview of the origins of the PDP-1 machine and the Computer Space game the ICSS document is broken up into Episodes (chapters).  Episode 1 has a brief description of the PDP-1 architecture, the characteristics of the Type 30 Display, an overview of Computer Space, and an outline of how Computer Space might be implemented on the PDP-1.  Subsequent Episodes basically cover the implementation of one facet of the game on he PDP-1. For instance Episode 2 talks about how to draw the background stars and implement a basic game "loop". Design options are considered for each feature with lots of code examples to support decisions. The gold at the end of each Episode is "the code so far" section where the game assembly code created up to that point is listed. At the end of the document there is an Addendum with the entire Computer Space source code listed. Fantastic.

Norbert Landsteiner did not jump into ICSS coding cold. He had done extensive research into the Spacewar! code the year before as can be seen here: Inside Spacewar! A Software Archeological Approach to the First Video Game. I have a huge amount of respect for Mr. Landsteiner's abilities as a coder, a writer, and a historian, but when he wrote Computer Space he also had a little help from his Spacewar! precursors:

Dan Edwards
Martin Graetz
Steven Piner
Steve Russell
Peter Samson
Robert Saunders
Wayne Wiitanen
Alan Kotok 

I think examples for most of the things that you asked for—"how to program subroutines, temporary variables without a stack, how to create / populate tables, how to random access tables, how to perform non-trivial computations given a single accumulator load/store architecture, best ways to write self-modifying code"   can  be found in this document, you just might have to dig for them a bit.

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/b9af0745-4244-4bf3-bc0f-73a5fedc17e5n%40googlegroups.com.

[Carlo Valpiani]

Thanks to all who replied. Now to do more reading :)

[John Kennedy]

If you have an iPhone/iPad/Mac, you might also find this useful:  https://apps.apple.com/us/app/dec-opcodes/id6760246055

[Oscar Vermeulen]

I let an AI make one from studying Norbert Landsteiner's ICCS source code.

So: Warning: skip if you hate AI involvement in PDP-1 matters.

Otherwise, see the attached first version. It must be far from perfect, but made me understand much more than I did studying his code on my own. Caveat emptor, AI slop attached. 

Kind regards,

Oscar.

[Oscar Vermeulen]

I find this a very effective way to learn from other people's code! Today I analysed Spacewar 4.8 and DDT source code in the same way.

Practice makes perfect, and no AI can help with that. but these two code review files made me understand spacewar and DDT more clearly than I used to (attached).

I also added some features to the pidp1 setup so that any AI can work alongside me on the PDP-1. So it can use the typewriter concurrently with me, has access to the PDP-1 memory and front panel, and can view the Type 30 display (in the form of SVG snapshots). 

I don't want to start an AI thread - to some that is toxic, to some is is bandwidth pollution. But I've come to appreciate it as a very useful tutor.

It wrote a Tic Tac Toe in an afternoon, debugging on the front panel and inspecting the graphics code it wrote. But the main point: as a PDP-1 learning tool for me over the past two days, it has been valuable. I'll put a how-to on the web site once I think it's reached a decent quality state.

Kind regards,

Oscar.

[AB]

nice work Oscar!

cheers, Andy

[Andrew Barron]

There is the excellent PiDP-1 manual by Oscar Vermeulen. My book on the PiDP-1 should be finished about the end of August. It is a sequel to my books about the PiDP-10 and the PiDP-11.

regards

Andrew

[Bill E]

That's a very broad set of topics!

A few I can answer quickly. If you're not writing a dynamic IOT, you don't need to do anything other than write a program that uses one, everything else is automatic. There is extensive documentation and examples of them all in my release. Tmp vars are easy with AM1 using locals. However, the -1 does not have an intrinsic stack or stack instructions, so all tmp vars are effectively statics in their scope. Both macro and am1 have 'table' constructs, but they are effectively just storage space allocation. There are no indexing operations, you roll your own using usually the idx and lac i instructions. You'll again find a lot of examples in my demo apps. One of these days I'll create some more utility includes for doing some of these things. Finally, interrupts are tricky. Using the single-level SBS version is pretty limiting if you have more than one interrupt source, SBS16, the multi-channel version is supported. See the rotate, switcher, program selector, and fastcube demo progs in FunStuff, ../Demos, and ../Demos/Type340 for some examples.

Bill

[Aron Insinga]

A traditional approach is to look at the great source code written by those who came before:
https://masswerk.at/spacewar/inside/
https://spacewar.oversigma.com/readme.html
https://sourceforge.net/projects/pdp1spacewar/

The manual for the DEC PDP-1 macro assembler has the source code for the whole assembler in it, and describes its bootstrapping from the TX-0 assembler:
https://decdoc.itsx.net/bitsavers/pdf/dec/pdp1/F36P_PDP1_Macro_Internals.pdf
At the end of this message I'll add a couple of messages from COFF when we were discussing macro assemblers that (1) saved the characters in the macro def vs. (2) saved some intermediate code that could be 'fixed up' during expansion.

Here are handy subroutines:
https://bitsavers.org/pdf/dec/pdp1/PDP-1_Subroutines_1961.pdf

This manual has sample code for expr eval:
https://bitsavers.org/pdf/dec/pdp1/FRAP_DECAL_Intro.pdf

Here is the source code for DDT:
https://bitsavers.org/pdf/dec/pdp1/PDP-1_DDT_Listing_Feb63.pdf

A couple more handy subroutines, octal dump and RIM paper tape punch:
https://bitsavers.org/pdf/dec/pdp1/memos/M-1129_RIMpunch_Oct61.pdff

The fine manual:
https://gordonbell.azurewebsites.net/Digital/PDP%201%20Manual%201960.pdf
(The photographs show the PDP-1A so this is an early manual.  More important stuff here:
https://simh.trailing-edge.com/docs/architecture18b.pdf)

Most of the code here is for the PDP-6/PDP-10 but there is at least one item (on sound generation) for the PDP-1:
https://web.archive.org/web/20190905202912/http://home.pipeline.com/~hbaker1/hakmem/hacks.html#item168
https://undercodetesting.com/hakmem-the-ai-lab-memo-that-still-powers-modern-computing/

Speaking of the PDP-10, here is the famous RIM loader that fit in the ACs:
https://inwap.com/pdp10/rim10b.html
https://github.com/PDP-10/panda/blob/master/files/documentation/rim10b.

You will discover that, very sadly, comments were much more rare back in the old days.  But sometimes there is a memo (or 'Program Logic Manual') that explains what the code is doing.  Hack on!

- Aron

----------------

Subject: [COFF] Re: ancient macros, machine code translation,as mental architecture models

From: Aron Insinga <a...@insinga.com>

Date: 7/14/24, 21:44

To: co...@tuhs.org

On 7/14/24 14:02, John Levine wrote:

According to Aron Insinga <a...@insinga.com>:

On 7/13/24 19:46, John Levine wrote:

I looked at the manual and I think he's misreading it. The "words" in
question are the tokens in the macro definition. ...

Possibly, but they use 'syllables' for tokens (symbols or integers), and 
they say here that they advance the location counter after each word 
copied.  If they were copying characters into the input stream, they 
would not be incrementing the location counter ('.') after each word 
transferred.

If you really want to know what it did, here's the internals manual.
The description of the macro facility starts on page 19 and it is
quite clear that they're storing a tokenized version of the macros, so
they're not copying characters, but they're not just copying assembled
instructions either.

https://bitsavers.org/pdf/dec/pdp1/F36P_PDP1_Macro_Internals.pdf

Thank you!!  I found the PDP-1 and TX-0 MACRO sources and was sadly unsurprised by the lack of comments, so they are difficult reading.

http://www.bitsavers.org/bits/DEC/pdp1/papertapeImages/20040106/macro_6-63/_text/part2.txt

They are not storing tokens.  In fact, the list of 'codes' for items stored as the macro body on p 20 is:
    a storage word,
    a dummy symbol specification.
    a constant,
    a dummy symbol parameter assignment, or
    an end marker.
So it is not storing tokens for instructions, just storage words (instructions or data) as mentioned in the user manual.

In the discussion in the internals manual, after the paragraph mentioning the year this was designed (a nice touch), they say that they are storing the macro body as 'partially assembled' 'words' into which the dummy symbols are 'inserted'.  (And in a single-address architecture with a small memory address, addition is enough to do that insertion.)  They explain why they did this instead of storing characters:

They do not look at the opcode as I suggested was possible, they have a more general solution that works for a word containing either code or data.

I think that this may be (at least as far as any of us know) a unique case from the early days of computing where, on the TX-0 and a port to the PDP-1, a macro body *is* stored as a list of 'machine words' instead of source text.  The macro  body is not manipulated as a 'higher-level construct', it is just used for quite limited macro expansion.

This has NO bearing on what DEC/HP/VSI did more than two decades later for the Alpha, Itanic, and x86_64 (where macros are expanded by the conventional insertion of characters from the macro body into the source text stream).

- Aron

----------------

On 7/16/24 15:55, Aron Insinga wrote:

On 7/15/24 15:39, John Levine wrote:

It appears that Douglas McIlroy <douglas...@dartmouth.edu> said:

In 1959, ...
We never considered anything but recursive expansion, where macro
definitions can contain macro calls; thus the TX-0 model comes as quite a
surprise. We kept a modest stack of the state of each active macro
expansion. We certainly did not foresee that within a few years some
applications would need a 70-level stack!

As the PDP-1 Macro imeplementation manual said about the macro feature:

    It is the weakest
   in that it is quite inflexible and does not incorporate any of the more significant improvements
   in assembler technology that have occurred since the logic was first written in 1957.

The PDP-1 was not a very big machine, only 4K words and the only
standard I/O device was paper tape, so no overlays or multiple passes.
I can imagine that while they knew how to write a better macro
processor, they didn't want to use up the memory it would have needed.

Bitsavers has a bunch of memos about the TX-0.

Memo 39 describes TX-0 assembler as of 1962, which had real macros
that could insert arbitrary strings, as they show in an example on
pages 10-11.

https://bitsavers.org/pdf/mit/tx-0/memos/M-5001-39_MIDAS_Nov62.pdf

There are earlier memos about MACRO in 1959 and 1961 which suggest a weaker
macro facility but don't have details.

R's,
John

At MIT they wrote two assemblers on the TX-0, and retargeted/ported both of them to the PDP-1.  (The machines were in adjacent rooms at the time.  Their architectures were very similar.)

* MACRO (macro expansion by limited partly-assembed memory words). DEC adopted MACRO, but its later MACRO assemblers do not seem to be at all based on that one.

* Midas (generalized macro expansion by inserting a character sequence).  MIT chose Midas for future work, and they rewrote it for the PDP-6, so that's what you find on ITS.

One of these retargets/ports was a challenge by Jack Dennis to a group of 4 or 5 students (the original hackers from the Tech Model Railroad Club) to do it over a weekend.

I agree, there is a lot of great stuff in these memos, from both MIT and from DEC, and in the oral histories done by the Computer History Museum and/or  the Smithsonian.

Bitsavers also has the hardware details, although they are in a very old notation, more abbreviated circuit schematics than logic diagrams..

p.s. That was too sweeping of a statement.  For the machines built by MIT, I found block diagrams and some instruction flows and lots of memos, but not the clock distribution matrix details.  Since the WW clock distribution matrix (ROM) triggered Wilkes' invention of microprogramming, I'd love to compare WW's with their later machines'.  And I haven't found more than a little on Wes Clark's later machines, L-1 and ARC-1.  I know some info is in the U. Wash. archives.  So many curiosities, so little time. 🙂

Best,

- Aron 

----------------

[MICHAEL GARDI]

I found  https://www.masswerk.at/rc2016/10/ very helpful. 

Mike

Sent from Gmail on my iPhone

--
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/0e9b8e46-79e3-45d7-95a9-ec07d145a8c1%40insinga.com.

[Aron Insinga]

Great reference, thank you!

>The article featured a bland white machine, the PDP-1A prototype

Unfortunately, we don't have many good color references from those days.  On one hand, we do have the DEC standard for what colors were used on what machines, but on the other hand I don't think it goes back to the earliest machines.

However, the earliest DEC products, the Building Blocks/Laboratory Modules had extruded aluminum cases and rack mount boxes with a speckled paint pattern.  These modules also appear to be white in b&w ad or catalog photographs.

BTW, according to Steve Russell, these early PDP-1s weren’t exactly white. In his memory

the “Prototype PDP-1” cabinets that were in the CHM Visible Storage were a very light cream color with a dark speckle.
(Steve Russell, PDP-1 Team mailing list, March 5, 2021

https://www.masswerk.at/nowgobang/2021/pdp1-spotting#update

These colors are also similar to those of the TX-0.  (I think this story is in the Smithsonian oral histories: Ken Olsen was musing once that his Memory Test Computer didn't get as much usage as it could have.  [It did off-load work from Whirlwind, was used to test peripherals, and other research such as the first neural net simulation.]  Someone suggested, probably jokingly, that it was because the machine looked so "blah" with its WW-II black crinkle paint finish.  Ken was surprised that scientists and engineers would care about that, but subsequent status reports mention that they were investigating cabinet colors, and indeed the TX-0 had a "two-tone" paint job similar to automobiles of the era [Gwen Bell said it was the first computer with 2 colors of paint on it] along with a sloped console with an angle in it.  It worked, the machine was positioned towards the back of the room, so there was floor space in front of it for "photo ops" which were reportedly popular.)

>drum computer with no memory at all

If you mean machines like the G-15 and LGP-30 (and many others) they did have memory!  The drum was the main memory from which instructions were fetched to be executed.  Larger, later computers than those often had drums as secondary storage for files or for swapping jobs in and out of core or as I/O buffers (SAGE).

But with magnetic core and transistors, the PDP-1 was from the generation after those machines.  It might have cost 2-3 x more but it was also something like 60 x faster!  Plus you could add additional memory to it.  Plus, something inherited from the earlier MIT machines and SAGE's radar displays, was that you actually could buy it with a CRT, and you could interface it to your own instruments fairly easily.