Re: [PiDP-1] Digest for pidp-1@googlegroups.com - 4 updates in 1 topic

[Michael Cheponis]

"The CHM does

have a type 33 symgen and there's a pic somewhere of it working. It's not
installed now, though afaik.
Bill"

The type 33 cards were re-installed once we replaced the ~ 20  (!!!!) leaky 1N1719 transistors in the deflection amps -- you know the ones the manual warns you about, re the Sail Switch, that you can blow up and it'll be $ 600 in 1960 dollars to replace those parts alone ( $ 600 in 1960 dollars is $ 6,546 in today's dollarettes -- and given the near unobtainium of those things, the price is pretty much constant dollars! ).  

We've not used the Type 33 for any demos yet, nor have we figured out a compelling light pen demo.  I urged using the Type 33 for putting up the names of the contestants in the quarterly pdp-1 Spacewar! tournaments the CHM runs  (they are on the 5th Saturday of months that have 5th Saturdays --- yes, Peter Samson's suggestion, can't you tell?  You know, Mr. Music Program and also accurate Expensive Planetarium background stars -- that move! -- in Spacewar!) 

One of the guys has talked about creating a lightpen demo a la MacPaint or something.  But.... the Real Machine takes quite a bit of time just keeping it running - mostly peripherals, but also niggly stuff like front panel bulbs burning out, which causes Peter great consternation when something goes awry and he can't accurately log the PC or whatever.    

At the moment, there is some bit, I think, b13 in Core Bank 2 that is sometimes flaky, preliminary work so far doesn't have a root cause for that.  That has been put on hold.  Much recent work has been to get the Soroban console typewriter to work solidly; the typewriter part works OK  (IBM), but the add-on solenoids & mechanical leaf switches (Soroban) seem to still be flaky.  The cable to the pdp-1 is OK.   

I have talked about adding in an 18-bit UART-style interface to read / write memory from an external PC, which would allow program analysis without any peripherals; but there isn't enthusiasm to do it.   The main issue is there are very few of us that understand the machine well enough to have a good chance of fixing it when it breaks.  There are really only 3 people who work on it, and I ( 4th ) do only occasionally.    Pretty much, by the time some previous problem is fixed, a new one pops up!   So the team is always working on 'something'.   

In order of most to least reliable, it's been: pdp-1 CPU, paper tape punch, paper tape reader, Type 30, and Soroban.  I joked that we should not call it the pdp-1 restoration project, but rather, the pdp-1 peripheral restoration project, because the main pdp-1 came up pretty quickly, but the Rest of the Stuff?  Still working on it.   Ahh, the 'joys' of 1962 hardware!  ;-)

-Mike

On Mon, Feb 9, 2026 at 8:30 AM <pid...@googlegroups.com> wrote:

pid...@googlegroups.com

Google Groups

Topic digest
View all topics

• Bug in pidp1 emulator? - 4 Updates

Bug in pidp1 emulator?

Bill E <wjegr...@gmail.com>: Feb 08 02:16PM -0800 Ok, this mystery is back. As was discussed, the distributed pong source had dpy-i, ioh which would hang because there was no completion pulse. It was decided this was bad code (I think). Well, just came across the very same, this time in DEC's own diagnostics. I don't think their distributed and used diagnostics wouldn't work. There are dpy-i...ioh constructs all through the one I'm trying to get working. So, seems it shouldn't hang, but both of these will hang on the pidp1 emulation. I need to fix this, but it raises the question, just what is supposed to happen? Should dpy always issue a completion pulse regardless of the i and c bits? Or what? Help needed here.   Bill

Unibus <uni...@gmail.com>: Feb 09 10:43PM +1100 Hi, Don't think this is going to help. My guess is, and it is only a guess... PDP-1 options will normally generate a completion pulse whether they are needed or not. The processor can be stalled waiting for a completion pulse, or not stalled while the program takes responsibility for timing. Some options do not generate completion pulses and bad things happen if you stall the processor. Think there are specific warnings for some IOTs. You would have to go back to the manual to examine timing pulses and resets. Maybe CHM can answer, my understanding is they didn't have the Type 33 and were running bare bones Type 30.   Regards, Garry

Bill E <wjegr...@gmail.com>: Feb 09 03:50AM -0800 Mystery solved, and it was an unexpected source. I was looking down at the bit level and discovered the disassembler was misinterpreting dpy with the 'complete' bit set, not reporting that! So, dpy =i 40000 was just listed as dpy-i. And, since the disassembler was used to reverse-assemble the program back into macro, it wouldn't work when reassembled. Sigh. Sure wasted a lot of time on this one. Well, my excuse is that the disassembler was the first thing I did for the -1, didn't know about completion vs wait. I'll update the disassembler repo, which is linked to the main repo and my mod one, so everything will be in sync again.   BTW, it looks like the lightpen is passing DEC's digital-1-27-mb light pen diagnostic. I need to dig into the source to be sure, can't find any documentation. I have not checked in everything for that yet.   Bill

Bill E <wjegr...@gmail.com>: Feb 09 03:55AM -0800 Interesting. It doesn't seem to be implemented that way in pidp1, I'll dig into it. Yes, the 'never issues complete' is a nice trap. The symbol generator has one of those IOTs. It is documented at least. The CHM does have a type 33 symgen and there's a pic somewhere of it working. It's not installed now, though afaik. Bill

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to pidp-1+un...@googlegroups.com.