I've Done All The Dumb Things - Mnemonic and Machine Code Reference List

[Unibus]

Hi,

I went hunting the sources for mnemonic and machine codes. Definitely an "I've done all the dumb things" exercise.Attached is a partial list as I haven't put much time into the PDP-1D and PDP-1X micro-program instruction sets. There are a relatively large set of IOT machine codes that don't appear to have mnemonics. A number of peripherals are poorly documented or undocumented. For every entry I've attempted to document sources.

The lists are divided into

• PiDP-1 instructions only. Will be subject to expansion
• PiDP-1 plus PDP-1C Instructions only
• PiDP-1, PDP-1C plus PDP-1D Instructions only
• PiDP-1, PDP-1C, PDP-1D plus PDP-1X Instruction sets

Given 

Regards,

Garry

[Bill E]

That is a great reference work!

There seems to be a number of reasons for all the apparent randomness.

First, the 3 letter limit that macro had meant it got very difficult to dream up new unique mnemonics as the number of widgets increased.

Second, the -1's were freely hacked, a number of random peripherals were added via IOTs, and apparently quite a few were unique to a particular -1, or had slight variants.

Changing the interrupt vector seems to have been popular, and even with the same IOT number, the behavior of the device could have been radically different.

An example is the IOT 32 clock. There were at least 3 variants I've found with different timing, different actions, etc. I ended up implementing the BBN version because it was the best documented I could find. Interesting note on that, why a 32msec interrupt? It seems like it might have been to synchronize with the time it took to set up and read a 4Kword track from the drum, which makes sense for the timesharing implementation BBN did. In the spirit of why do anything the same way twice, I added one new feature to it, a 1msec countdown timer settable to 1-8192 msecs.

Third, it's not entirely clear that all of these were ever implemented. While there are references to some instructions, I haven't been able to find any definitive implementations. It seems the handbook was written before the instruction set was finalized? An example is jfd, jump field. It's in the handbook but I can't find any actual use, and simh doesn't implement it.

Simh does implement quite a bit more than pidp does, such as all of the 1D instructions, some of which are useful. I've added the  missing1D instructions except for the ring mode and character manipulation instructions to my pidp mod variant. Ring mode is strange and it is a pretty intrusive change, so didn't bother.

Talking with a well-known PDP-1 expert at CHM, seems some don't even consider a 1X to be a PDP-1, just too many mods for the timesharing implementation.

So, the moral is, just have fun and use the -1 the way it was actually used, a hacker's delight.

For reference, I have added: cmi, sni, szi from the 1D set, as well as IOTs 22 - DCS, 32 - BBN clock, IOTS 61,62,63 - type 23 parallel drum, using the mnemonics I could find plus some extras.

DCS has some added instructions to handle socket setup, but the base instructions are the same and they fit in the IOT 32 space.

I've added one unique-to-me IOT 60, which just lets you enable and disable SBS16 mode since the stock pidp1 supports SBS16 but has no way to actually enable it. The other IOTs have added instructions to do the same.

My music and dynamic IOT mods are transparent to users, no visible instruction changes (there are some standalone C progs for controlling some aspects of the music mods, though).

I also added high-speed-channel support, but just the 'hardware' implementation, not the user-level IOTs since those don't make much sense for the pidp, although some mapping using sockets for the external 'hardware' might be possible, maybe even useful. I'll think about that. The drum uses the HSC implementation for realism. (timings are duplicated)

Final note - the 'true' way music was synthesized can't be duplicated with the pidp1. The program status lights aren't directly driven from hardware pins, which means no analog filters, which is why I had to implement digital filtering in the pidp1 code. That got a few upturned noses from the PDP-1 guys at CHM. :) I'm wondering about maybe building a little bit of external hardware, send the 4-bit music stream via a socket to yet another rPi whose only purpose is to recreate the 4 bit output with the correct timing and have the real analog filtering which CHM is sending me component values for. But, seems like a lot of work for not much return, and it's fun to be able to tune the filters in real time anyway. Well, the CHM version does have trimpots, so it can be changed in real time with a screwdriver.

Bill