• Please review our updated Terms and Rules here

pdp-8/a build from parts

Actually... this is fantastic. Direct - thoughtfully diagnosed - and it is conclusive.

How I wish every fault were so solid and apparent when found.

Is it too early to ask if damage resulted - or are we operational again?
 
I didn't put it all back together yet. I'll start in a few minutes.

I will point out though that having, reading, and understanding the documentation helped me find this. The diagnostic, the listing (thanks Dave and Bob V.), the print set, and the operator's manual (which is really more like the 8/e maintenance manual than an "operator's manual") were instrumental.

Lou
 
Hi All;
Lou, are You trying to pick up my Bad habits.. ""I pulled the backplane out and saw AU2 pin bent over at one of the slots near a standoff - it must have been touching that standoff. I obviously screwed this up when I put the machine back together after cleaning.""
It just sound like something I would do and have done..
THANK YOU Marty
 
So I started putting this back together and realized I should write up the lesson learned:

My 8/a is in an H9300 chassis. The backplane is attached to the rear of the chassis with female threaded standoffs. One side of the standoff is held against the chassis with phillips head machine screws with star lockwashers under the heads. The other side of the standoffs either attach directly to the backplane PCB by a phillips head machine screw with split lockwasher and flat washer OR pass through clearance holes in the PCB and sit against the H803 blocks, and are held in place with socket head cap screws with no washers.

When disassembling, the phillips head screws with star LW on the back of the chassis can be difficult to remove, and so the easy route may be to remove the cap screws or phillips head screws from inside the chassis. I remember I left a mix - if I couldn't get the screw out of the back, I took the screw out of the inside. Of course then some spacers stayed with the PCB/H803s and some stayed with the chassis. I bent the pin on one of the spacers that stayed with the chassis when I put it back together.

The lesson learned is that all the spacers should be removed from the chassis and attached to the PCB/H803 side before reinstalling in the chassis. That will prevent any pins from geting hung up and bent on anything. So this time, I went to the trouble to put all the spacers on the board side before reassembling.

Lou
 
Hi All;
So, now the Big Question, Does it work ??
Just because I fixed something, doesn't mean that it is all fixed.. I should know !!!
THANK YOU Marty
 
I've often wondered why the card sockets on the 8/A should have such long tails when the actual bus wiring is done with a printed circuit. The "standard" omnibus (8/E,F,M) backplane has minimal stubs and is much more robust. Has anyone ever seen any point-to-point wiring on one of these backplanes?

Jack
 
Good to hear you found the fault, we'v all been there, my c**k ups sometimes result in a hot smell, magic smoke , or on one occasion the sound of an RK05 rotating platter touching a head , OUCH
Dave
 
Folks, I can now report that nothing actually got fried. I am VERY lucky. The 8/a is here next to me happily running DJKKA with no halts. Tomorrow I will run some memory maindecs, and then go back to trying to boot OS/8 off RX01.

Thanks again for all the help / encouragement!

And Jack, it looks like the bussing for the KT8A option support was wire wrapped on the E slots on this backplane. Otherwise there is no other hand wiring.

Lou
 
Last edited:
Good progress tonight, we've got OS/8 running! With the 8/a on the "bench", I hauled inside the rack mount RX02 I usually use on the 8/e. There is no room for the teacart RX02 near the bench. http://www.vintage-computer.com/vcforum/album.php?albumid=182&attachmentid=17036

It's set up in RX01 mode with an RX8E in th 8/a. http://www.vintage-computer.com/vcforum/album.php?albumid=182&attachmentid=17035 It booted nicely using the bootstrap on the M8317 (156 and 157 DS310 roms). I then loaded (from floppy) and ran DHKMC (extended memory address test) for three passes with no trouble, and have left it running DHKMA (checkerboard extended memory test - the acid test for memory) for the last half hour. Between these and DJKKA, it's in pretty good shape now.

The next big leap is to put the RL8A in there. There's already a RL02 under the bench from the earlier RL emulator testing on an 11.

The more I play with this 8/a the more I like it. The programmer's panel isn't *that* bad. And this machine is really small and light compared to the 8/e. Why though did they make the KK8A slower than the KK8E? Was it to support old slow mos memory (when mos was slower than core)? Can I overclock the 8/a to bring it to 8/e speed?

Lou
 
Lou - N2MIY said:
Why though did they make the KK8A slower than the KK8E? Was it to support old slow mos memory (when mos was slower than core)? Can I overclock the 8/a to bring it to 8/e speed?
Click to expand...

I *believe* (please verify :->) that the processor speed is determined exclusively by the installed RAM. It runs synchronously. If you have core-only then you'll run at core-speed. The standard configuration, however, is MOS and thus you'll run (only) at MOS speed. Try your modern-memory board in it (currently in your 8/e? presumably faster than the native 8/A MOS?) and see what you get :->.

It is my understanding that the TD8E controller for the TU56 is, in fact, dependent on having core-memory in the 8/A else the CPU is too slow and fails to meet the necessary tight software timing requirements. I have seen documentation, somewhere, indicating that an 8/A plus core memory plus TD8E was a supported configuration.

The Eyes of Texas are upon you ...
 
The PDP-8e 4 quad board set runs at a 1.2us (read-write) or 1.4us (read-modify-write) major cycle.

The PDP-8a 1 hex board CPU runs at a fixed 1.5us major cycle.

So the PDP-8e CPU is 10-25% faster than the PDP-8a hex CPU.
 
pbirkel@gmail.com said:
Must be something about the TD8E then. Needs further investigation ...
Click to expand...

So I did some (more) homework to refresh my memory (ha!). The 8/A Operators Handbook, Table 3-1 & accompanying text, describe the 8A600 and 8A630 configurations (among others) -- which use the KK8-E (plus core memory). Those are the configurations in which the KE8-E (EAE) and TD8-E work. Not the configurations that use the KK8-A.

This statement is made: "Also, note that only the 8A computers that use a PDP-8/E CPU can be expanded."

A bus-load thing? A bus-termination thing? A point for exploration at a later date ...
 
pbirkel@gmail.com said:
This statement is made: "Also, note that only the 8A computers that use a PDP-8/E CPU can be expanded."

A bus-load thing? A bus-termination thing? A point for exploration at a later date ...
Click to expand...


I suspect that it may have to do with bus termination. KK8A does not use an M8320 at the end of the bus. Also, KK8A goes in the topmost slot of the H9300. But, KK8E in an H9300 is supposed to go in the lowest elevation slot and M8320 goes in the top slot. I suppose I should look at the schematic for the H9300 backplane.

I would save my one question for Charles Lasner to be something more substantial.

Lou

PS. There is an ECO that must be done when putting M8320 in an H9300 vs. when in a standard 8/e chassis.
PPS. I like this document very much : http://bitsavers.trailing-edge.com/...01_PDP-8_Family_Configuration_Guide_Apr78.pdf
 
Last edited:
I was actually referring to the "clock" issue in the 8 as a Lasner question, but since Paul commented about termination before I finished my comment and since forum replies are linear (no skips or branching here!) my reply was out of sequence. I _would_ like to hear Charles discourse on how timing is implemented and interpreted in the various family-of-8 machines. Don's comment is helpful but doesn't explain what actually determines the major cycle interval.

Jack
 
The 'major cycle interval' is determined by the logic design and implementation of the various different CPUs. In the PDP-8a logic print set are a couple of good timing diagrams of the minor state timing pulses, and what memory operations (read, write) are expected to occur during what timing pulses. There is a PDP-8e timing diagram as well, for comparison.

For the PDP-8e/f/m quad board set, the design of the bus timing is intimately tied to the capability of the core memory system available at the time. It basically determined how fast the CPU could run, as the PDP-8 does more or less one or two memory accesses per major cycle (ie, an instruction fetch read and a data read or write), or a data read-modify-write. The PDP-8 is basically a completely memory bound architecture (as are RISC based designs) but without a cache.

The PDP-8a is similar, it timing design is based on its memory system, and how fast the logic paths in its data/control paths could reliably run. I'm sure DEC would have made it run a lot faster if they could, but the restriction to one hex card, and the lower cost TTL logic of the day, dictated the 1.5us major cycle. I suppose DEC could have done a faster completely 74Sxxx schottky logic design, but it would have likely been power/cost uncompetitive in its design space.
 
AK6DN said:
snip...

For the PDP-8e/f/m quad board set, the design of the bus timing is intimately tied to the capability of the core memory system available at the time. It basically determined how fast the CPU could run, as the PDP-8 does more or less one or two memory accesses per major cycle (ie, an instruction fetch read and a data read or write), or a data read-modify-write. The PDP-8 is basically a completely memory bound architecture (as are RISC based designs) but without a cache.
Click to expand...
I agree, I think the current drivers and sense amps for the core memory bound the memory cycle time and, therefore, the practical speed of the entire system. As you say, "memory bound."

The PDP-8a is similar, it timing design is based on its memory system, and how fast the logic paths in its data/control paths could reliably run. I'm sure DEC would have made it run a lot faster if they could, but the restriction to one hex card, and the lower cost TTL logic of the day, dictated the 1.5us major cycle. I suppose DEC could have done a faster completely 74Sxxx schottky logic design, but it would have likely been power/cost uncompetitive in its design space.
Click to expand...
This part I'm not so sure about. I did a fair amount of TTL design back in the day (early '80s, tail end of the TTL era) and even straight TTL (e.g. 7474) could be clocked at 20 MHz, IIRC 'LS was good for 25-30MHz, 'S maybe 40 MHz. Set-up times and propagation delays were on the order of 10ns. We struggled with board layouts and buss speeds more than the parts themselves. I suspect that between those issues and the cycle time of the memory there just wasn't any point to running the TTL at its full potential.
IMHO, of course:)
 
AteEm said:
This part I'm not so sure about. I did a fair amount of TTL design back in the day (early '80s, tail end of the TTL era) and even straight TTL (e.g. 7474) could be clocked at 20 MHz, IIRC 'LS was good for 25-30MHz, 'S maybe 40 MHz. Set-up times and propagation delays were on the order of 10ns. We struggled with board layouts and buss speeds more than the parts themselves. I suspect that between those issues and the cycle time of the memory there just wasn't any point to running the TTL at its full potential.
IMHO, of course:)
Click to expand...

Both the 8e and the 8a use a 20MHz oscillator (50ns) as their master timebase. These drive the timing chain that generates all the pulses and edges that form the major clock period. On the 8e it is normal TTL, on the 8a the master timing is mostly 74S logic.

If you look in the PDP-8a schematics: http://bitsavers.trailing-edge.com/pdf/dec/pdp8/pdp8a/PDP8A_Schems_Apr81.pdf on page 90+/-5 there are the block diagrams of the PDP-8a CPU implementation and the bus timing diagrams. The PDP-8 architecture has a lot going on in one major cycle (adders, shifters, etc) that serialized the results. The CPU design could do this because memory was so slow.

Evolving PDP-11 designs of the time took a different approach, and decoupled the processor from the memory using the async UNIBUS (the PDP-8 OMNIBUS was synchronous). So the PDP-11 implementers could run the processor major period based on what a 16bit ALU, or the microcode ROM lookup / register setup, could run at. This was typically on the order of 100-200ns, and this is what you see in the 11/40, 11/45 implementations being done at that time.

A PDP-8a maybe could have used this same design approach, but it would have been much harder, as the OMNIBUS is very intimately tied into the guts of the PDP-8e CPU implementation. It may have even been evaluated by the PDP-8a designers; or not. Hard to say.

Don
 
Last edited:
Lou - N2MIY said:
PPS. I like this document very much : http://bitsavers.trailing-edge.com/...01_PDP-8_Family_Configuration_Guide_Apr78.pdf
Click to expand...

I "tripped" over this just an hour after my last post, and do kick myself for not having discovered it previously. It is, indeed, a jewel. Wish that I had discovered it earlier!

I had heard of "variants" with a KKBE in the 8/A chassis but had always assumed that it was the customers (or collectors :->) playing Dr. Frankenstein, rather than a planned evolution. I also hadn't realized that there was a 20-slot version of the 8/A chassis (power supply in rear of a deeper chassis). I infer that at the time customers preferred the 8/A front panel over the 8/E front panel; was this for functional, cosmetic, durability, cost, module-access, or some other reason?

8/E front panels seem to be "all the rage" these days (blinkenlights), but it's not so clear that was the case at the time ...
 
You must log in or register to reply here.
Back
Top