Does anyone have the driver schematic for the lamps?

[alank2]

I am tempted to get one of the 28V lamps from Digikey and measure its turn on and turn off time with a light sensor to see how quickly it changes state.

[Warren Young]

According to the PDP-8/I blueprints, the lamps are driven by a low-side buffer.

So, what is a buffer, in this context? It could just be an open-collector BJT, it could be a 7407 — which had just come out a few years before the PDP-8/I, thus allowing the "I", for "IC" — or it could be a DEC R201 thru R205 series buffer register Flip Chip card.

The Digital Logic Handbook from 1967 does not give detailed schematics for the latter, but before chasing that down, I'd want to know whether this was indeed DEC's solution. The other two options seem equally plausible to me.

Then the question becomes one of accuracy. If you're going to measure response time, now you need ICs or transistors with the same current vs time characteristics as the originals, because that goes directly to brightness. And if it's just a bare transistor driving the lamp, what was its current input, since you need that to back out the proper hFE value to test with.

Or you could just try the 7407 option and call your results "plausible." Digi-Key still sells them.

My best argument that it wasn't a 7407 is this picture of the back of the PDP-8/I front panel, where I don't see any clear 14-pin DIP footprints.

[Ian Schofield]

Dear Alan,

 A totally cool idea as this would give an accurate view of the original system. However, following on from Warren's point below, the lamps were driven with open collector drivers and took about 40ma each (see http://so-much-stuff.com/pdp8/repair/bulbs.php). However, with all the bulbs lit, the current required is about 3.5 amps ... ouch! This would require some serious power management. As a result, software solution for the leds!!!!

Regards, Ian.

[Warren Young]

On Tuesday, January 31, 2017 at 3:19:07 PM UTC-7, Ian Schofield wrote:
>
>  A totally cool idea as this would give an accurate view of the original system. However, following on from Warren's point below, the lamps were driven with open collector drivers and took about 40ma each (see http://so-much-stuff.com/pdp8/repair/bulbs.php). However, with all the bulbs lit, the current required is about 3.5 amps ... ouch! This would require some serious power management. As a result, software solution for the leds!!!!

I didn't take the original request as the start of a plan to replace all the LEDs with incandescent lamps, but instead as a research project intended to generate a set of brightness curves at various duty cycles so we can calibrate the incandescent lamp simulator to real hardware, instead of just doing whatever looks nice.

So is that what you're going to do for us, alank2? :)

[Ian Schofield]

Ooops pressed post while thought was still in mind. We built a colour led array display a long time ago using tri-color leds just after they appeared. These can be programmed to give the correct spectral output for a bulb as the brightness varies. Warren; do you fancy multiplexing 3 times as many leds!!!!

Best of, Ian.

[alank2]

>So is that what you're going to do for us, alank2? :)

Absolutely.  One lamp with hopefully the original driver or something similar to see what it does!

[Warren Young]

On Tuesday, January 31, 2017 at 6:30:03 PM UTC-7, alank2 wrote:

>So is that what you're going to do for us, alank2? :)

Absolutely.  One lamp with hopefully the original driver or something similar to see what it does!

Sounds great. I await your results.

Some thoughts:

1. The accuracy of the measuring system is not important. You only need relative metrics here: put the sensor over the lamp, drive it like so, put the sensor over the LED, drive it the same way, and compare.

2. What is important is a repeatable test method. Incandescent lamps radiate equally in all directions except where blocked by the base of the lamp, whereas LEDs have a ~20° cone where they're brightest. You also have to deal with varying thicknesses of the glass with some bulb types, all of which is why old style flashlights threw odd patterns of light and dark, whereas many modern LED flashlights give nice even patterns. It does no good to gather data from one part of this pattern this time, then a different part another time. A diffuser may be a good idea.

3. I expect that duty cycle will affect the results greatly. I'd like to have a set of curves at many points in the design space, so we can interpolate behavior as we change the software design.

[alank2]

The bulb page says 15V for the PDP-8/I and so does the blueprints, so the 28V bulb I was looking at isn't exactly right though they probably are similar.

I also found this:

http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/log2015a.shtml#2015-02-17

Which shows a circuit, but isn't the same as the PDP-8/I, though it may give a hint.

I emailed the guy with good front panel pics to see if he could tell us the components used.

[Warren Young]

On Wednesday, February 1, 2017 at 10:31:19 AM UTC-7, alank2 wrote:

I also found this:

http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/log2015a.shtml#2015-02-17

Which shows a circuit, but isn't the same as the PDP-8/I, though it may give a hint.

I emailed the guy with good front panel pics to see if he could tell us the components used.

It's the very sort of thing I imagined when I mentioned the BJT definition of "buffer", but you'd have to flip it around, since the PDP-8/I engineering documents show the lamps being driven from a +15 rail (presumably toward ground), not from the ground rail toward a -15V rail.

The NTE103 looks like a plausible modern complement: germanium NPN, same package type.

The NTE103 won't tolerate as much voltage as a 2N257, but that's fine for this application if you can find a ~12V bulb. (Keep in mind the voltage drops: the bulb won't have all 15V across it.) 

The NTE103 has higher hFE than the 2N257, but that's expected for a modern transistor, and for NPN vs PNP.

The NTE103 also has considerably higher bandwidth, but that's fine. The original transistor wasn't bandwidth-starved, so we don't need to emulate that to get equivalent appearance.

Since they're shown using it as a simple switch — wide open when "on" — I'm not sure the hFE and other such characteristics matter.

[alank2]

I've got a  lamp in finally.  It is surprising how much dimmer it is at 15V then it is as 28V.

I need to find a photocell, but I know I have a few laying around here somewhere.

[alank2]

I am using a photocell I scrounged up along with a PN2222A NPN transistor as a low side driver.  I connected the base through a resistor to a 0.5 Hz waveform generator and am measuring the voltage of the photocell connected to ground via a 1K resistor.  Using 24V.  The rise time is 30.5 milliseconds and the fall time is 68.5 milliseconds.  I'll have to try measuring some of the LED's on the PiDP-8 tomorrow or when I get a chance.

[Warren Young]

On Thursday, March 9, 2017 at 7:30:57 PM UTC-7, alank2 wrote:

The rise time is 30.5 milliseconds and the fall time is 68.5 milliseconds.

It is good to have that confirmed and quantified. Thanks!

 

It'll be a good excuse to get back into the code and match those values. Perhaps this weekend.

Care to share a CSV version of the curves?

I'll have to try measuring some of the LED's on the PiDP-8 tomorrow or when I get a chance.

 It should be possible to work out the correct constants purely mathematically, but don't let me discourage you. :)

Where that experiment would be useful is once the constants in the code are adjusted to confirm the accuracy.

[alank2]

 

Rise PNG
Fall PNG
Rise CSV
Fall CSV

[Obsolescence]

Alan, Warren,

sorry for being offline rather a lot - just one thought re rise times etc: you are aware that the 8/I kept the lamps fed with a small voltage even when the lamp is supposed to off, right? The lamps were too slow in lighting up all the way from 'off' to 'on', so the way I understand it, the lamps were kept under some voltage all the time to improve response time.

Kind regards,

Oscar.

[Chris Smith]

Oscar -- could you take a look at the refurb details here ....

http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/log2015a.shtml

I could not find an exact model number. I don't have enough familiarity to judge how close it is to the 8/I, but the faceplate ( http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/2015/02/11-PDP8panelFace.JPG ) is very similar. I suspect it is an original PDP-8 (no suffix).

The reason for mentioning all this is that they reverse engineered the light driver circuitry, and show it.

http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/log2015a.shtml#2015-02-17

In addition, they explicitly state that there is no "keep warm" current on their model. Given many engineers wise preference to stick with known working solutions, it would not surprise me if the lamp circuitry was common until they switched to LEDS (PDP-8/F?). I have also looked - and continue to look - for details of the lamp drivers in the later models, judging that if they are using the same circuitry before the 8/I and after the 8/I, then that would likely be the circuitry used in the 8/I.

You are quite correct that the "keep warm" technique is the best way, and the rebuild blog above seems to be a bit surprised that the technique was not in use on their machine.

If you already have PDP8/I circuits -- well then, given the level of testing that Alan is doing - it sounds like he might be prepared to construct a single 8/I original lamp circuit for the sake of testing and accuracy.

[Chris Smith]

Okay -- by the time they get to the 8/F, they are using keep-warm.

This document, http://dustyoldcomputers.com/pdp-common/reference/drawings/cpus/docs/DEC-8E-HR1C-D_8eMaint_Feb73.pdf

... page 3-102, describes the display circuitry in detail, with a simplified circuit diagram on the following page. The 8/E has both lamps and TTL ICs which is (if I can read correctly) what the 8/I has as well.

If anyone has any indication as to what the single resistor value is in the circuit diagram, this would be very easy to build - one resistor, one TTL inverter as buffer. That value could also be suggested by experiment - use a variable resistor, and, while the lamp is driven "off", gradually lower the value until the lamp is visible, then backing off just enough the make the on-state un-noticeable.

I recall that stage lamps used this feature, not only for speed, but to avoid damage from in-rush current on cold filaments. If you were far enough forward in some theaters or auditoriums, you could look back and see the barely glowing filaments inside the "off" stage lamps. That might be a rough guide for where to tune the resistor that is shown in the front panel diagram.

[Chris Smith]

Further down the tunnels ...

See ...

http://dustyoldcomputers.com/pdp8/pdp8i/restore11.html#20031123

and

http://dustyoldcomputers.com/pdp8/pdp8i/restore5.html

So -- this *is* a PDP8/I. The first note speaks of replacing transistors on the front panel board. This is reinforced by a picture on the second note of an actual 8/I front panel board. It has lamps, and transistors - but not a TTL chip in sight.

This, to my thinking, suggests that although the core processing was migrated to TTL on the 8/I, the front panel continued to use the original plain 8 design. TTL might have made the core more reliable and faster than discrete components, but there was no real benefit to a faster front panel. Unless you were actively programming using the front panel, even a couple of burnt out bulbs were not likely  to be a problem. They might not even have been noticed.

[Neil Higgins]

These are the outputs from an LDR or photocell, right? So they do not take into account either the spectral response or persistence of vision (POV) of the human eye. I suspect that POV may be as significant as lamp physics in determining the overall subjective outcome.

[Paul Birkel]

FWIW, the 8/L used bulbs, transistor drivers (base fed from TTL), +10v, and the pull-downs from bulb to GND were 1K 1/4w 5% CC.  When not running, the bulbs were discernible (you could tell that the machine was on from a few yards away – even if you could ignore the fan noise!), although inter-bulb brightness variation was quite noticeable with all in the nominal off-state – with some bulbs appearing to be fully “off” and others merely dim to a varying degree.

 

We actively programmed from the front panel so a bad-bulb was a real problem.  I cut my baby-teeth (this was in 1972) on that machine with bulb replacement …

 

Response time on TTL-high was hardly an issue; improving bulb life most definitely was.  It was non-trivial to extract the front panel, and then carefully desolder bulbs.  Never lost a pad that I can recall, but I’m sure that I lifted a few :-<.

 

Had much fun adding home-brew external 28Kw static memory (2102-arrays) + controller to that basic 4Kw core machine.  Since the 8/L is essentially a no-frills 8/I it was possible to directly leverage the 8/I design documentation, which I certainly did (and was very thankful for having it!).  In retrospect I’m rather amazed that it worked out so well; it was the first time I ever took a soldering iron to a computer …

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e5a884fd-87af-4de3-9181-4aa8ae48d722%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Obsolescence]

Chris,

I think you are right about the 8/e using keep-warm but the 8/I not... this link has the schematics, PDF page 20:

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/pdp8i/PDP8-I_CPU_blueprints_1969.pdf

Kind regards,

Oscar.

[Chris Smith]

I'm thinking that there is a bit of "internal notation" going on in those diagrams - which are fascinating!!

The registers appear on page 8, and in most of the registers, the 0 (not the 1) output of each bit drives the lamp driver. (The connecting bars are labelled in a way that suggests they are bundled, or jacks, or headers, connecting the main logic to the front panel).

The zero lines directly drive the non-inverting buffers on page 20, and then connects to the bulb, but opposite the +15V on the other leg of the bulb. So - when the bit is zero, the register zero bit output is high, which drives the buffer on, which suppresses the lamps. If the bit is a one, the zero bit output is low, the buffer switches off - and acts as the ground through which the lamp turns on. The lamp would likely see +15 volts less one diode drop (which depends on the type of transistor). I could not find any indication in the drawings as to where the transistor connects to, but it seems likely to be ground. These drawings also seem to encompass only the logic - with the exception of the memory control, there did not appear to be any power handling components drawn anywhere.
 
Although drawn as "non-inverting buffers", it seems likely that the implementation was just transistors. Looking back to an earlier post, I noticed in one of the photos that the front panel board of the 8/I has no resistors, just lots of transistors.

Those drawings are quite interesting. It is especially neat to note that the front panel lights are directly wired to the registers -- something that vanished forever the moment the registers disappeared into LSI chips.

[Ian Schofield]

Dear All,

 If this is of any interest, I have attached an RGB colour file for a filaiment bulb that generates (more or less) the correct spectral output for a bulb at 64 levels of brightness. Each triplet does need to be pre-multiplied by a luminance value ( I use 0-1.0 over the range which is not quite correct.) Anyway, for a simulated display this does give quite a good appearance.

Regards, Ian.

On Tuesday, January 31, 2017 at 2:06:30 PM UTC, alank2 wrote:

[Chris Smith]

I think I need a little more explanation of what this is. I am getting lost at the point where the R value is permanently at 255 at every one of the 64 positions. I would have expected that at the bottom end, all three values would be at zero.

Or - maybe learning as I type - is it the case that the red value is going to be  255 * [0/64,1/64,... ,64/64] ? (to generate the range of values? Is this what you meant by pre-multiplying by a luminance value?)

I can see that maybe the levels have been normalized to maximize one of the 3 components ... but I confess that I find that odd, since it implies that the red component is precisely linear over the luminance range, which seems very unlikely.

And, ultimately - am I correct that using this would require an RGB LED at each position? So, this won't work with the PiDP8 as currently implemented?

[higgins...@gmail.com]

He did say "more or less".

It is consistent with physics for all components to ramp up, and for the colour to move closer to white, as the current increases. That's exactly what happens when you multiply by the luminance.

However a yellow LED is is indeed yellow (unless totally abused). The emphasis to date has been getting the illumination and (?) de-lumination (?) time constants consistent with subjective human perception. In another thread, it has been shown that the physical model for this is non-trivial, so ad-hoc time constants have been adopted.

I have never seen a real PDP-8, so I'm happy with the original code, even if convinced it doesn't look authentic.

[Chris Smith]

No disagreements here at all. I'm still fairly certain this only works for RGB-capable illumination sources, meaning the existing PiDP8 is not in the cards.

Even so, someone in the future might come looking and find this useful. And at that point, having a rounded out explanation in the thread will be helpful. For now though, it means my curiousity will be satisfied.  :-)

I did a quick image to mostly help myself, but maybe it explains my question better. I have attached it. The top band is the "raw" colours from the post above. The bottom band is the same colours, multiplied by a 0.0 to 1.0 value over the range. So - the lamp would actually look like the *lower* band, but the normalized colour is the upper band?

[Ian Schofield]

Dear All,

 Chris; spot on and you can see that it is not quite right in that the luminance multiplier should not be a simple linear ramp. Anyway, the reason for this note is a trivial aside I made to Warren at some stage. It might be possible to use an RGB led array for the PiDP8 rather than the current yellow. This is a bit of a technical challenge to drive this directly from the gpio port along with the requirement to vary the brightness. To this end, I suspect that a display driver processor is required on the panel to manage this needing only a low bandwidth update from the Pi. Any takers???? Having said that, maybe we should return to Alan's original suggestion of using a bulb anyway!!!!

[higgins...@gmail.com]

Sounds like we need a second Raspberry Pi in the box :-)