Fixed version of macro1_1.c

[Bill E]

See the other thread for the issue.

Compiled and tested.

I would suggest to Oscar that this be distributed, since all of the other versions have the bug.

Bill

[Norbert Landsteiner]

Still, I'm not convinced, if I should recommend this: constructs like "law -23" aren't valid Macro assembler syntax (or PDP-1 syntax), even, if the documentation for "macro1_1.c" states that it would support this.

The expected behavior of the traditional MIT Macro assembler is to add the values of the (predefined) symbol "law" = 700000 and the signed value "-23" = 777764" in ones' complement arithmetic, resulting in 67764 +1 = 67765.

Therefore, this code variant may result in invalid object code for historic or 3rd party sources.

I don't think that this is good idea. Just use "law i 23", as you're supposed to. Notably, these are two distinct PDP-1 instructions: 700000 (load unsigned/positive 12-bit value into AC) and 710000 (load ones'' complement of the unsigned 12-bit value into AC).

Best,

Norbert

[Bill E]

I decided rather than forcing the world to get a fixed macro1, and given your objections, I also updated my disassembler to use the known-working form, law i n instead.

Still, it was annoying. The sw should match the docs! I wasted hours on this.

Bill

[Norbert Landsteiner]

I think, it's a wise decision. You find all sorts of wonderful constructs in source code.

E.g., just look at this memorable line from the Minskytron, defining some  coordinate data:

xa0, dpy i 17770 

= 730007 + 10000 + 17770 = 757777 = –20000 (who would have thought?)

(Macro defines dpy with the i-bit already set, so there's i + i.)

Notably, this is a source by Peter Samson (no less), but, we may guess, reverse engineering the original code from a disassembly.

(Minsky would have probably written the original source code in Ed Fredkin's FRAP assembler.)

But I've also seen things like "opr + <some small value>" for data, where "opr" = 760000 (but I can't remember at the moment, where this was exactly). So, seeing "law"= 70000 used similarly may not be out of the world.

Best,

Norbert

[Norbert Landsteiner]

HOWEVER, having that said, "law –n" has actually something going for it.

Namely, the "Abbreviated Instruction List" in the appendix of the PDP-1 Handbook (in the Oct 1963 edition, p.62) states:

INSTRUCTION  CODE #     EXPLANATION                      OPER. TIME (µsec)

  law N       70     Load the AC with the number N           5
  law-N       71     Load the AC with the number -N          5

So this is really ambiguous! If we were to go by this definition, we had to define a special case for "law", like,

"If an instruction includes the symbol 'law' and the value of the instruction minus 'law' is a negative value, complement the address part and set the i-bit."

(Mind that this should be also valid not just for "law -3", but also for "-3 law" or "4 law -7", etc., since we're allowed to do similar with any other instruction. Meaning, we have to set a flag, in case we encounter "law", in order to eventually evaluate that special case and to fix up the instruction. But now "law" != 700000, which isn't ideal, since symbols and literal values should be always mutually exchangeable.)

Which is probably why Macro didn't do it like this.

Best,

Norbert

[Oscar Vermeulen]

>> xa0, dpy i 17770 

>>

>> = 730007 + 10000 + 17770 = 757777 = –20000 (who would have thought?)

>> (Macro defines dpy with the i-bit already set, so there's i + i.)

So much for my claim 'a delightfully simple instruction set to get into'... 

[Bill E]

Trying out various scenarios, it's quite easy to get macro1 to fail miserably.

It seems perfectly legal to define a label "i," which then makes every op i x wrong.

You can use a negative number for many things, example "lac -7", get no warning, get a totally bogus instruction.

This really isn't great as a general purpose assembler.

I'm not going to make any attempt to fix any of this in macro1, it is what it is.

[Oscar Vermeulen]

Bill,

Can I have your permission to use the disassembler code in my tape_visualizer? I'd like to extend its output from 'tape with holes'+fiodec codes+fiodec characters to include a row with disassembled words.

On Friday, September 26, 2025 at 1:00:24 PM UTC+2 wjegr...@gmail.com wrote:

 

I'm not going to make any attempt to fix any of this in macro1, it is what it is.

We await Angelo's assembler! It will also deal with Extend-mode programs. AFAIK, the original assembler that could deal with >4K programs has not been preserved - except for ones that require MIT's heavily modified PDP-1X.

I've yet to try any of the other native assemblers for the PDP-1, there are some in the tape archives though. 

Kind regards,

Oscar.

[Norbert Landsteiner]

BTW, the version of "macro1.c" is the one that used come with simh.

It works generally fine and – as a faithful recreation of the original – it features the same limitations of up to 3 characters for symbols and 4 characters or longer for macros (only 4 chars significant). Also, just like in the original, the very first line is the title (printed out on top of each page) and must not be a comment.

Caveat: It does not support the "DIMENSION" directive for data tables, but this can be worked around rather easily. Apart from this, I never encountered any issues and I consider it to be reliable.

It can be found here: https://www.masswerk.at/spacewar/sources/macro1.c

Mind that this may not be the latest revision, but this is what I'm generally using.

Best,

Norbert

[Bill E]

That's the one I'm using, and I'm finding lots of bugs. Example, assemble the little test attached. It appears to be fine, the listing file shows everything as ok, but if you examine the rim file, the JMP instructions jump to addr 0! Assemble it, look at the bytes starting at tape location 383. That's the code being loaded by the BIN loader. You'll see 600, 600, which are both JMP 0000. Yet more wasted time thinking it was a problem with my disassembler. Nope. I'm amazed that it manages to assemble some of the complex code like spacewar. It will produce garbage easily, as I noted. Change the lac 7 to lac -7. No errors, but a total fail for an instruction. I'm wondering if this is the reason for some of the flaky bin tapes in various archives.

And I found the issue, no terminating start x in the test. Is there an error message? Nope, just produces bad code. Add a start 100 at the end, all is well.

So the moral is, if you're using macro1, be sure you check everything, because it sure won't and then you'll pull your hair out trying to figure out what's wrong.

Bill

[Norbert Landsteiner]

> Add a start 100 at the end, all is well.

Yes, you are expected to add a start address.  ("start" also explicitly finishes the source.)

If not, it will default to 4. (The first 4 locations, 0…3, are used by/reserved for the sequence break mechanism.)

The start address is essential for the bin-loader, since this is where it will jump to after the payload has been read in and deposited into memory.

Mind that with multiple tapes (like with Spacewar) or patch tapes, there is no guarantee that the lowest address specified is also the start address. So it does make sense.

BTW,

  100/

       hlt

  (…)

       jmp i 100

"hlt" is 760400. Therefore, "jmp i 100" extracts the address part of 760400 at 100, which is 0400, and uses this as the effect address.

Is this what you want?

Best,

Norbert

[Norbert Landsteiner]

Just a general observation:

I think, it's not fair to bring expectations formed on modern assemblers (which kind of arise in the mid-1970s with microprocessors) to Macro.

Macro was originally ported in 1962 from the TX-0, so it's origins are probably in the 1950s, which makes it one of the earliest symbolic assemblers around. (It must have been quite the sensation, when filling in octal code in code sheets was the norm.)

So the "<location>/" directive isn't a quirky equivalent of the modern "org" directive, it just does what it says, it sets the location for where the code is going to be. On the other hand, this also allows for wholes in the code (so it's sparse object code) and allows for easy patches or addition to the source code. With multiple tapes to load to run a program more often than not, it totally makes sense to separate the start address from any use of the "<location>/". Users were expected to know that the default start address is 4 and that they had to specify the start address explicitly otherwise.

It's always good style to end the source with the "start" directive (which guarantees that the buffer will be flushed) and adding the start address here is quite convenient.

(It's also a reminder that there is an action, which will be performed by the bin-loader, namely, to continue execution at that location. So we may think of "start" as a "jmp", which it effectively is.)

Please, have at least a quick glance at the manual:

http://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf

And for details, see:

http://bitsavers.org/pdf/dec/pdp1/F36P_Macro_Internal_Operations_Manual_Jul62.pdf

Best,

Norbert

[Bill E]

re: 

hlt" is 760400. Therefore, "jmp i 100" extracts the address part of 760400 at 100, which is 0400, and uses this as the effect address.

Is this what you want?

This isn't intended to be a working program, I was trying various things to see what macro1 generated.

BTW, I'm not arguing about the merits of macro or not, I'm arguing that the cross-compiler is buggy and hasn't been fixed for decades.

Bill

[Norbert Landsteiner]

Hum, still, ending the source with "start" and the start address is basic operational etiquette, I wouldn't blame macro1.c for this.

Again, this is really owed to the binary loader, since this doesn't just halt, when it has ended its job, but rather jumps to the given start address, defaulting to 4.

And this was already established behavior, from the TX-0, which assembled to the same loader format.

(Yes, in theory, you could keep track of the lowest address and default to this, but this wouldn't have made much sense with the editing practices of the time. So, if macro1.c is supposed to be a faithful port, what should it do? Default to 4 like the original or do its own thing? An all-new assembler would be free to do whatever we may deem due and useful. But, in my opinion, a faithful port is really bound to the original behavior, in order to work with original sources. And, if it doesn't conform to the original implementation and does break rules, it really should be called something else, to avoid confusion. – I'm already alarmed that macro1_1c apparently breaks rules for symbols and macro names and is still called "macro".)

Also, a small correction on my side: The port of Macro of from the TX-0 to the PDP-1 was probably part of that famous weekend effort in Fall 1961, which earned the TMRC associated bunch access to the PDP-1, and not in 1962. (1962 is just the date of the manual. We don't want to spread misinformation, here. :-) )

Best,

Norbert

[Oscar Vermeulen]

Norbert,

Have you tried any of the other PDP-1 assemblers? I've not tried, just curious. Original PDP1 Macro works fine for my simple things.

Kind regards,

Oscar.

[Bill E]

I've tried macro1.c from various places, all the same code, macro1_1, and marcro1_1alt. The last 2 have no code differences. All exhibit the issues I've reported.

If there are others, let me know and I'll try them. I have NOT tried the native assembler on the -1 itself, but I know it will have similar issues because of the second point below.

Again, it comes down to two things. First, there is very limited error checking, and second, the interesting processing where all terms are just added up, even for instructions, which leads to the bad opcode generation (this is documented behavior from the native assembler), and the related failure of the above assemblers to handle 'law -n' even though it is documented to work in the original DEC manual.

The disassembler will output what it sees, and that will assemble back into the original binary.

So, to repeat the moral of this, pay attention if you're writing your own macro code!

[Norbert Landsteiner]

Regarding "law-N", as already pointed out, this wouldn't really work reliably in an assembler (too many edge-cases). And, even if we get it it working, it's necessarily more of a directive than a symbol. I personally think, this table in the Handbook isn't meant to define an assembly language, it rather gives an overview over the instructions. So, what we are meant to take home from this that instruction code 71 loads the complement of the literal unsigned 12-bit operand in the address part, but not a particular notation.

(If you look at it from this angle, it's not "law" + "–N", but really "law–" + "N". So it may work with a symbol "law–", but then we break the 3 character rule and not allowing for a space before the minus, would be another apparent bug. And allowing for a minus symbol at the end of a symbol would complicate parsing quite a bit.)

Regarding loading extended memory: I think, at the CHM, they are just loading each bank separately. (Mind that this is a bank switching system.)

Regarding error checking: The assembler available before Macro was Ed Fredkin's FRAP, which is for Free of Rules Assembler Program. With initially just 1K of memory available, Fredkin's crucial insight was that what really made for most of the code is rule checking. So, in order to fit an entire symbolic assembler into 1K machine, what you really have to do is having as few rules as possible… (The other insight was that on the PDP-1 you can the paper tape in both directions, so you can do it all in a single pass, were the tape runs forth and back again.)

In a some regard, this is still valid for a 4K machine, and also, we want our programming tools to be quick. Given the audience (MIT students and personnel), I think, the error checking is sufficient, as long as we take responsibility for what we write in a given line.

Mind that a stack-less machine, like the PDP-1, necessarily requires self-modifying code – and with this comes a certain amount of responsibility. The same is true for the universal indirection feature via the i-bit, which may be hard to track for any small assembler. But this, the i-bit, is what gets PDP-1 code really going…

Personally, I think, the PDP-1 is the closest you can get to "bare metal" with some amount of comfort. (E.g., I'd rate it higher and more enjoyable than the 6502.)

This also extends to what we might expect from an assembler and what it should do and what not.

For example, MIT's "fio-dec" system (collection) of macros comes with the building blocks of what amounts close to a high-level FOR-loop, but I personally found that I rather not want to use them, as they already feel rather remote if you're thinking that close to the machine. It's really more natural to write those two or three instruction manually and come up with your own variations, where needed.

On the other hand, composing your own instructions by what DEC called "microcoding" is something you really want to do (e.g., for additional conditions). And Macro's system of just adding up symbols, where any op-codes are just predefined symbols (but otherwise just like any other symbol, including those that we define) is really great for this. (I think, this is the most crucial feature any newly written assembler should support. But this also poses a natural problem for any disassembler, if it doesn't know about any of those additional op-code symbols. But, if we compose a program from multiple sources, something like a symbol table – think header file – is a necessity anyways.)
Anyways, Macro is what is (and has been for nearly 70 years). It may be quirky, but it's also enjoyable if we commit to its ways.

(Macro is by no means a modern IDE. But, if an IDE is what you want, I've no idea why you should be interested in the PDP-1. And any modern IDE would struggle with the PDP-1 anyways, since it's not static code, and there's also no hard separation of code and data. In the old paradigm of "is it art or engineering?", the PDP-1 is clearly on the artsy side of things. Which is really what makes it enjoyable.)

Best,

Norbert

[Oscar Vermeulen]

Norbert,

I should be able to find them in the tape archive - but maybe you have them right at hand, then:

>> MIT's "fio-dec" system (collection) of macros

Do you know where to find them? No need to spend time on that, I should be able to dig them up as well of course.

They might be good to read, good to train my AI on, and generally useful for a beginning PDP-1 dabbler.

Kind regards,

Oscar.

[Norbert Landsteiner]

I don't think that I've found a stand-alone source for this.

But here is, what I think came from the start of Spacewar!:

https://www.masswerk.at/spacewar/sources/macro_fiodec_jun63.txt

The bit that is really relevant are the following composed instructions, which are a reoccuring thing (comments are mine):

szm=sza sma-szf /skip, if AC zero or minus spq=szm i /skip, if AC positive (not negative or zero, see above) clc=cma+cla-opr /load -1 (777777) into AC (clear and complement AC) ioh=iot i /wait for completion pulse (form Type 30 display)

Regarding the afore mentioned building blocks for loops, the equivalent of

  for (n = -4; n < 0; n++) …

is,

setup 4, n

a1, (...)

count n, a1

n, 0

resulting in,

law i 4 /load -4

dac n /deposit it in loc. n

a1, (...)

isp n /index n and skip next, if positive (count up to zero)

jmp a1 /redo loop

As we may see, this is not so much about savings in typing (it's actually 2 characters more) as it is about a change in perspective…

(I personally found that I didn't like that kind of switching perspectives that much. And this is true for most of those macros.)

macro "listen" may require explanation (comments are mine):

define listen cla+cli+clf 1-opr-opr /clear AC, IO and program flag #1 (at once) szf i 1 /skip next, if program flag #1 not zero jmp .-1 /jump to prev. instr. (i.e. wait for flag #1) tyi /read from console typewriter term

So we wait for program flag #1 going high and then read the input character.

Best,

Norbert

[Glenn Babecki]

Forgive me for circling back to Norbert's entry in this thread dated 9/25/2025 11:18 PM, but I've been pondering the description of instructions/data and it took some time to wrap my head around my disbelief.  So I just had to look up the related minksytron source listing to see for myself, and sure enough it was my worst nightmare.

// constants for initial values for oscillators
// encoded as instructions, but used as numerical values.
// (this may be the result of a disassembly?)
//
// these initial positions give the corners of an upright triangle
// with the base through the center origin of the screen (+):
//
//                  b  (0 | 0100)
//
//
//  (-040 | 0)  a   +   c  (040 | 0)
//
// (points in screen coordinates = 10 most significant bits of 18-bit words)

xa0,  dpy i 17770  // (730007 + 10000) + 17770 = 757777 = -020000 (1's complement!)
xb0,  0            // 0
xc0,  and          // 020000
ya0,  0            // 0
yb0,  ior          // 040000
yc0,  0            // 0

It actually states:  "constants for initial values...encoded as instructions, but used as numerical values."  WHAT?!  This deserves some more explanation as to why such an arcane approach was necessary rather than just putting the (calculated) numerical value in the constant declaration.

My issues with this coding approach aside, I also wanted to point out some other documentation in the event that I missed it being called out in various other threads.  There are a number of other PDP-1 documents associated with MIT in the https://bitsavers.org/pdf/mit/rle_pdp1/memos/ directory.  My mimeograph copies from MIT while I was there from 1971-1975 had various version dates from 1969-1971.  There appears to be later (dated) versions of all the pages I have so I don't think I need to upload any of my copies, but I will do a more thorough check.

The discussion of the instruction set is mostly contained in the PDP-35 series of documents.  While these documents contain references to the "PDP-1," I don't recall if the PDP-1 at MIT was in fact the PDP-1-X as some of the documents explicitly note. The labeling of these documents appears to have evolved over time so it takes some care to find a complete set.

So all the history around the PDP-1 makes me wonder what instruction set(s) the PiDP-1 simulation is attempting to cover.  I can appreciate that it would be great to be able to recover and use as many historic programs as possible, but this may complicate the development tools.  Right now I don't have a good feeling about the stability of those development tools.

I'm generally up for a good retro-computing archeological adventure as the next person, but being in the throes of another such adventure right now is somewhat exhausting.  I've been working for the better part of a year to recover some old FORTRAN IV software from my undergraduate thesis which was done on a PDP-9 lab computer at MIT.  I managed to get my DECtaps transcribed to use with a SIMH PDP-9 implementation, which was a gating factor for the project.  I subsequently got a lot of help from Michael Thompson at the RICM to wrangle and relearn the development tools.  However, I have hit some roadblocks with identifying the video display device and getting visibility into a lab image processing library.  I just hope I didn't make a mistake getting lured in by the PiDP-1 front panel, only to get entangled in another mystery.

I know, it sounds like a personal problem.  Any ongoing thoughts on the instruction set issues and development tools would be appreciated to help talk me off the ledge.

Thanks,

Glenn

--
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/63882826-fd51-456c-950f-712330770c70n%40googlegroups.com.

[Oscar Vermeulen]

Glenn,

 

  This deserves some more explanation as to why such an arcane approach was necessary rather than just putting the (calculated) numerical value in the constant declaration.

It is at least interesting.

 

My issues with this coding approach aside, I also wanted to point out some other documentation in the event that I missed it being called out in various other threads.  There are a number of other PDP-1 documents associated with MIT in the https://bitsavers.org/pdf/mit/rle_pdp1/memos/ directory.

I think I once checked - the memos slowly start to describe things for specifically the PDP-1X, thus the MIT modified instruction set. 

The PiDP-1 is a PDP-1D. Once you'd switch to the 1X modifictions, you get compatibility problems with all the other PDP-1s (correctme if I am wrong, though!). 

One day, we could envisage a PiDP-1X mode. But Angelo is pessimistic about that, because the instruction set modifications of the MIT machine happened gradually over time (there's no 'PXP-1X instruction set', there's many of them over time). And, he has no schematics of the 1X rewiring. Because the simulator simulates the circuit, not the high-level instruction set, mixing in the 1X instructions would be impossible (no circuit schematics) or dirty (hack in high level logic onto a simulator that simulates a lower level).

It looks more tempting to add the BBN peripherals to their PDP-1, and run their time-sharing OS. For which we do have the sources, here. (The https://walden-family.com/bbn/ link has many other interesting things, BTW).

So all the history around the PDP-1 makes me wonder what instruction set(s) the PiDP-1 simulation is attempting to cover.

PDP-1D. On the longer-term planning list is adding the drum and the multiple terminals BBN allowed on their time-sharing machine. 

 

  I can appreciate that it would be great to be able to recover and use as many historic programs as possible, but this may complicate the development tools.  Right now I don't have a good feeling about the stability of those development tools.

As far as I know, no-one has attempted a simulaton of the MIT later-stage modified PDP-1X, because you immediately hit the question 'which stage of the 1X'.

I'm generally up for a good retro-computing archeological adventure as the next person, but being in the throes of another such adventure right now is somewhat exhausting.

[...]

I know, it sounds like a personal problem.  Any ongoing thoughts on the instruction set issues and development tools would be appreciated to help talk me off the ledge.

It is not in my interest at all to talk you out of this particular rabbit hole :-)

Kind regards,

Oscar.

[Glenn Babecki]

Oscar,

Thanks for being the first to respond, at least from the PiDP-1 perspective.  Apologies if I seemed frustrated with the state of the tools.  I had no intention of disparaging the work you and Angelo have done on the PiDP-1 project.  I completely get the pitfalls that come with the labor of love for such a historical project that has many gaps to fill.

As I sort of noted in a backhanded manner, although the MIT RLE documents didn't explicitly indicate when they referenced PDP-1-X specific topics, I was fairly certain that most of those documents were in fact leaning towards the PDP-1-X.  Even though I have a legacy affiliation as an alum and briefly used the MIT PDP-1, I didn't mean to express the desire to implement the PDP-1-X instruction set(s) for all the reasons you cited.  In fact my desire is to understand the PDP-1 version implemented by the PiDP-1 (which is probably in your documentation somewhere, my bad), and more importantly what legacy software is supported on that architecture. It helps nail things down to know that the PiDP-1 is a simulation of the PDP-1-D.  Recreating the PDP-1-D makes sense if you're striving to stand up the BBN time sharing environment.  I'll just have to pay more attention to what software is supported on the PiDP-1.

That all sorted, I'm still perturbed by the whole "instructions as data" thing.  It's stuff like that which gives "hacking" a bad name.

I understand that talking me out the rabbit hole is not in your interest, but talking me off the ledge is important...at least to my mental health.  I may have prematurely wound myself up about the state of the development tools without fairly investigating the behaviour myself.  I'll have to get things running and take it a step at a time.

Many thanks for the perspective.

Best Regards,

Glenn

--
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/e6078372-6c94-468d-8526-1331b8048da8n%40googlegroups.com.

[Bradford Miller]

On Oct 1, 2025, at 7:52 PM, Glenn Babecki <glenn....@gmail.com> wrote:

That all sorted, I'm still perturbed by the whole "instructions as data" thing.  It's stuff like that which gives "hacking" a bad name.

You’re going to want to stay away from Lisp, then, as they have the whole instruction syntax = data syntax thing nailed. Also you would struggle to implement the kind of macros most Lisps support, which is a program for the compiler (or interpreter) to rewrite the input code into something it can do something with. (Lisp macros are “Turing complete”.)

At one point, AI was thought to need the ability for programs to (re-)write themselves. That’s mostly a lost thread, but Lisp's macro system keeps part of it alive.

[Oscar Vermeulen]

Glenn,

I was not aware of any disparaging remarks by you at all! You were voicing sensible thigns.

Partly because the macro1_1 tool has nothing to do with Angelo or me, we 'found' it in the simh Lisp software pack for simh. I believe that assembler was only written to compile Lisp, so it is simply what we have. Until Angelo releases his own assembler - he's procrastinating though :-)

I only write the fiodec en/decoder tools and the tape_visualizer, which I badly needed to make sense of the few hundred paper tapes that are on bitsavers. 

It is early days in recovering software for the PDP-1, at least from my perspective. There's tons of tapes out there (and more, apparently, unpublished in the CHM archives). Curating that all into the tapes archive of the PiDP-1 is great fun. I'm currently banging my head against the defenses of the Kalah game. Then, FORTRAN should be next - but I fear that it needs the DECAL compiler, and that one I have also not tried yet.

I understand that talking me out the rabbit hole is not in your interest, but talking me off the ledge is important...at least to my mental health.  I may have prematurely wound myself up about the state of the development tools without fairly investigating the behaviour myself.  I'll have to get things running and take it a step at a time.

I'm on the ledge as well, and rather enjoying it ;-)

Now that the PiDP-1 is finally done (granted, we'll need to polish up the software a bit, Angelo and I spend a few nights per week on that), I am finally delving into the machine's guts myself. Rather than fret about PCB fittings and parts supply.

Though the parts supply is a headache, Jose is handling all that (sorry for the headache, Jose!). It is interesting to see how much worse thing have become since Covid: shipping parts is less reliable, of course now we have the US tariff situation, and also, parts from China are less trouble-free than they were a few years ago. We already learned to buy chips from the Digi-Keys and Mousers only, but we have a lot more quality issues with all sorts of parts. Testing parts is taking up huge amounts of time now. Very odd to see the world regressing in this respect.

Kind regards,

Oscar.

[Glenn Babecki]

Bradford,

I've used Lisp, but probably not since my computer science classes (i.e., lambda calculus and all that jazz) in the early '70s.  I get the whole "everything is a list" paradigm in Lisp and thus instructions, data, and everything else is fair game when writing a program.  Certainly this paradigm was fundamental to early AI development.  I lived through that period and some related classes and probably still have the problem sets somewhere.

However, I assumed the context of my apparent mini-rant was understood to be centered on the (PDP-1) machine level instruction set architecture and associated assembler behavior.  The PDP-1, and other related computer architectures, were not organized as list processors (e.g., Lisp Machines).  My issue was with the encoding of data as an instruction in this specific context.  Just because you can do something doesn't mean it's a good idea or practice to do so, especially if it obfuscates the intent.  I would be more than happy to hear the rationale for the example instruction statement in question.

Regards,

Glenn

--
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/fba713ed-09f5-4d3b-b554-3378163d95c8n%40googlegroups.com.

[Glenn Babecki]

Oscar,

Thanks for acknowledging my intent; I was just hopeful that the tone didn't come off as combative, adversarial, or the like.

I understand the problems that arise trying to find complete sets of historical programs and tools, especially when delving way back in time.  You and Angelo were lucky to find the materials you did.  Certainly the convoluted evolution of the PDP-1 makes it harder to zero in on a comprehensive set of development tools that are compatible with all the varieties of software in the archives.  The various tools you and Angelo have come up with, like the tape visualizer, and Bill E's disassembler are very cool and helpful.  I'm sure it's quite a challenge to fill in the gaps while staying true to all the original software, but whatever it takes to keep the project alive.

I gather you're having a good time living on the (l)edge, as witnessed by all the herculean PiDP efforts; otherwise you wouldn't have gotten this far.  Living on certain (l)edges is okay for an adrenaline rush from time to time, but for me, "I am uncomfortable with heights" Detective Del Spooner (I, Robot 2004 movie). 😉

Keep up the good work, but pace yourself.

All the Best,

Glenn

[Bradford Miller]

Glenn,

Well I certainly can’t speak to what was in Minsky’s mind, but he was a Lisp programmer so may have just wanted to echo stuff he could do in Lisp. Or he was exploring different programming paradigms - there was actually a lot of science in computer science in the early days (by which I mean experimentation because nobody yet knew the best way to deal with these machines). I was a research programmer myself, so if you look at some of my code you’d probably see me do the same thing 15 different ways which is terrible engineering, but was actually 15 experiments in trying to determine which was best from a variety of different evaluation criteria. Space optimization, for instance, requires a lot of (fun) work but generally gives opaque code.

Also I think you’re judging this old code based on modern standards. There wasn’t yet Dijkstra’s “Go to statement considered harmful” or suggestions that self-modifying code (common in the device drivers for many machines) could be anything other than improved efficiency. Even Knuth recommended substituting goto for a tail subroutine call when you knew the object subroutine didn’t recurse (so when it did a return, it just returned to your caller saving all that stack pushing and popping!). Of course nowadays tail recursion folding is a thing too, but we don’t expect the programmer to do it, just the compiler writer.

And not that long before the -1 were machines that programmers would optimize for where the read head would be on the drum at the time the prior instruction had finished. Talk about spaghetti code… but those kinds of efficiencies were very much in demand, even if the code was unmaintainable by others. Most expected everything would have to be rewritten when the next model came out (unless perhaps you were an IBM customer). Job security!

So using instructions as data in the assembler probably didn’t trigger anyone’s fear or loathing at the time. Bridges used to fall down if you marched on them too. Engineering is learned through failures. Minsky’s code worked!

Best,

Brad

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/CAL1sX6niRSQVZ2yjOmMi03BVO63Ed4zb-8-MUvdhTPYqHvpz7g%40mail.gmail.com.

[Adam Thornton]

And indeed the most famous example of THAT kind of machine is going to be the next Oscar production (or maybe next-but-one).

[Bill E]

And just to keep wandering into software history, Minsky was fundamental in killing AI research for years. He proved mathematically that what we now call neural nets (he called them perceptrons) couldn't deal with anything but a small subset of problems. I have his original book on perceptrons around somewhere, I think I might even have had him sign it.

Of course, it turned out that the small subset is exactly what is needed in the real world. He blew this one.

Bill

[Oscar Vermeulen]

It is odd that there's so little attention given to the early roots of AI in computer history. But I guess that field is in such a growth spurt at the moment that the time for looking back has not come yet.

I hope that someone finds the Lisp tape of doctor (the Eliza predecessor, IIRC). It did exist for the PDP-1. Trying to port that from another machine's Lisp is a bit beyond my skill set.

[Glenn Babecki]

Yeah, I sort of remember Minsky's position against perceptions/neural nets.  I suppose that's how languages like Lisp got started.

Now AI has augmented deep neutral nets with all kinds of other architectures like CNNs, RNNs, transformers, diffusion, etc.  Ha, not only did Minsky miss the boat on these aspects of AI, he encoded data as instructions!  🤭 (couldn't resist lightening the mood).

--
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/304c5b6d-66f8-40d2-ab4f-6a0f920897f4n%40googlegroups.com.

[Bradford Miller]

Keep in mind that perceptrons didn’t have a “hidden layer” so really were too weak to do much useful. Minsky demonstrated this by showing they couldn’t model XOR. 

--
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/304c5b6d-66f8-40d2-ab4f-6a0f920897f4n%40googlegroups.com.

[Charles Ess]

Hi Oscar,

Re. your first comment: I'd be really grateful to know more about the sources you have in mind for computer history. First of all for purely selfish reasons. I've been delving lately into early Wiener, Dreyfus, Licklider, Engelbart, Weizenbaum, and Minsky (as a start), and how what Dreyfus articulated as the object/field distinction as a problem for Minsky's rule-based / heuristics approaches - that Jerry Fodor later articulated as the frame problem: and then how these problems (and Dreyfus' suggested solutions - human judgment as computationally intractable - unfold into the era of GenAI (an area I've explored a bit more fully, FWIW).

I have some good help with all of this, including colleagues in CS, Informatics, and AI development who also have good to superb grounding in the ethics and philosophy of technology. But as with most things, I need all the help I can get. So any additional suggestions for resources, etc., would be highly appreciated!

(And, yes, there are deep connections with all of this and what I've learned in the PiDP worlds, as prefaced by what I've learned - and still learn - from building, troubleshooting, and maintaining a Ben Eater 8-bit breadboard computer. But those reflections are likely not of general interest / relevance in these worlds / communities. That said, the various tidbits about history from the folk who cut their teeth on these machines are especially invaluable: thanks to all for those.)

Many thanks in advance for this and all the rest!

- charles

[Oscar Vermeulen]

Charles,

On Friday, October 3, 2025 at 5:20:18 PM UTC+2 charl...@gmail.com wrote:

Hi Oscar,

Re. your first comment: I'd be really grateful to know more about the sources you have in mind for computer history.

Well, that is the point actually: when Googling, I hardly see any pages describing the early AI (Lisp-Eliza/Doctor-PDP10-SHRDLU). They get mentioned, but that is about all. Which on the one hand is surprising because in 2025, everything with the letters AI gets huge attention. But on the other hand, the AI from the PDP-1 to PDP-10 era has little to do with the AI of today.

Still, you'd think that some historical perspective would be an interesting read, and there is plenty of hands-on code preserved through retrocomputing to experience that. It is just that nobody writes about it.

Just the slight regret that there's no doctor/Eliza for the PDP-1 yet :-)

Kind regards,

Oscar.

[John Blankenbaker]

The original ELIZA was written in MAD-SLIP, a different list processing language, running under MIT CTSS on a 7094. The original source was recently rediscovered and an emulated version is running. See https://www.computer.org/csdl/magazine/an/2025/02/11030922/27sQDLuL7Uc 

As an aside, the ELIZA program was set up in such a way that different “personalities” could be encoded via a kind of a script. Doctor just happened to be the one that was described in the paper — it faked being a “Rogerian” psychiatrist who was very non-directive and thus gave space for the human in the conversation to imagine that more was going on behind the scenes than actually was. If you read the original paper, it is clear that what Weizenbaum did this deliberately:

            This mode of conversation was chosen because the psychiatric interview is one of the few examples of categorized 

            dyadic natural language comnmnication in which one of the participating pair is free to assume the pose of knowing 

            almost nothing of the real world. If, for example, one were to tell a psychiatrist "I went for a long boat ride" and he 

            responded "Tell me about boats", one would not assume that he knew nothing about boats, but that he had some purpose 

            in so directing the subsequent conversation.

I heartily recommend reading the paper itself and Weizenbaum’s subsequent book Computer Power and Human Reason. Especially for what they have to say about the current generative AI hype.

Shortly after the academic paper describing ELIZA was published, Bernie Cosell at BBN created a LISP version from just reading the paper, not Weizenbaum’s code,  which spread widely, leading to the mistaken belief that ELIZA was written in LISP originally. He was known as the “czar of the PDP-1 timesharing system”, and the cited reference says it was written in BBN-LISP, which as I understand is an evolution the Deutsch LISP that was developed at MIT for their PDP-1. 

There are apparently tapes and listings from several versions of Cosell’s code which have been (minimally) updated to run under more modern LISPs, but I’m not sure anyone has every tried to port it back to Deutsch LISP. 

[Bradford Miller]

Did you see this? Not in depth, but an OK overview.

Also Parry (the paranoid) had a famous chat with Eliza at one point. The source for Parry is here, but while it should run on a PDP-10 you’d need Meta-Lisp, WAITS, and probably other tools to compile it.

That CMU archive is where a LOT of old AI sources are kept (Even some of mine! :-), mostly from the 80s though as the collection was started in the late 80s, IIRC. 

--
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/2ccfa86f-b76e-4521-b24e-5242e23796ddn%40googlegroups.com.

[Oscar Vermeulen]

On Monday, October 6, 2025 at 9:04:15 PM UTC+2 bradford...@gmail.com wrote:

Did you see this? Not in depth, but an OK overview.

No - that is exactly what I was looking for!

[Oscar Vermeulen]

John,

Oh yes, MAD. I forgot that little show-stopping detail.

I had the honour/pleasure of an email conversation with Bernie Cosell, when looking at how feasible it is to resurrect an IMP connection. The time-sharing software (well, a scan of the sources, I should not be overoptimistic here) is on the Walden site, alas, the code that does the job of talking to the IMP is not. Mr. Cosell did not give us much chance of finding that anywhere.

Kind regards,

Oscar.

[Bradford Miller]

Just glad my 40 years in GOFAI occasionally has some use :-)

--
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/7d3b3aef-7695-4685-85c7-358cf55efff8n%40googlegroups.com.

[Norbert Landsteiner]

Dear Glenn,

first, please excuse my delayed reply.

Regarding the Minskytron and its – at times – odd notation:

> Forgive me for circling back to Norbert's entry in this thread dated 9/25/2025 11:18 PM, but I've been pondering the description of instructions/data and it took some time to wrap my head around my disbelief.  So I just had to look up the related minksytron source listing to see for myself, and sure enough it was my worst nightmare.

> (…)

> It actually states:  "constants for initial values...encoded as instructions, but used as numerical values."  WHAT?!  This deserves some more explanation as to why such an arcane approach was necessary rather than just putting the (calculated) numerical value in the constant declaration.

Please mind that what you were citing, is actually a version of the source code with additional comments by me, trying to explain what's going on, which is anything starting with a double slash ("//"). So this comment is actually by me and not an original statement.

As for possible nightmares, please relax and don't blame your night cap, as this isn't an original source, at all. The original program was probably written in Ed Fredkin's FRAP assembler, and this one is written in Macro, a strong hint at this being derived from a disassembly. (The Macro version is probably by Peter Samson, who packaged 3 of these "dpys", Munching Squares, Snowflake and the Minskytron, into a single tape for the purpose of CHM demos.) So this instruction/value is just an artefact of the disassembly, which extracted any known symbols from the instruction code. Apparently, it wasn't worth cleaning up this line, or it just slipped the attention.

But, for the sake of the argument, I was trying to make, this still does work, as Macro will happily add up any values provided, just like the disassembler used in this case, happily extracted any symbols it could find. But, be reassured, you're not supposed to obfuscate any data this way… ;-)

Best,

Norbert

PS: Here's a program, which actually contains a somewhat obfuscated address part (in the instr. "law i-7762"). It's a short program, I've to designed as a possible test for any LLM-based AI. (I don't think that a LLM can solve this.) Otherwise, this program has no purpose or meaning.

Q: What does this PDP-1 program do?

4/
szs i 10
lac i 12
law i+3
jmp i+4
law i-7762
lio i 14
dio i 11
lac i+5
adc i 15
dap i 13
hlt

start

(What this actually does is left as an exercise to the reader or the LLM prompted by this.)

[Oscar Vermeulen]

Delicious! 

I'm been struggling for 30 minutes but I think I figured it out after having been completely on the wrong track..

Now I will test my PDP-1 AI tutor on Claude and ChatGPT to see what they make of this on their own.

Then on to running it under DDT, to verify my suspicion. I'll send to you privately so as not to spoil the fun.

Thank you!

[Norbert Landsteiner]

You're welcome!

I've made this a topic of its own, including the solution and the motivation (i.e., why I think that this may be important.)

In case any LLM should succeed on this, we may turn this into a sport: coming up with new PDP-1 riddles… :-)

Best,

Norbert

[Oscar Vermeulen]

I was not disappointed about the LLMs choking on this.

I was disappointed that after one hour, I have not figured it out.

Continuing...

[Glenn Babecki]

Norbert,

Thanks for the clarification of the history behind the particular version of the Minskytron code.  I, for one, appreciated your efforts to document the code.  Your explanation of how this particular incarnation came to be clarifies the strange coding pattern that most likely resulted from disassembly.  I know from recent first-hand experience of trying to disassemble some PDP-9 code that interpretation even with the symbol table intact can be tricky to interpret.

Best Regards,

Glenn

--
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/0bc4a994-7fbb-4632-8651-59035fa99363n%40googlegroups.com.