• Please review our updated Terms and Rules here

PDP 11/45, Part 5

Hi All;

Dave, Thank You for Your Exposee..
I know I will need to read it over a few times, but it looks like the Last Paragraph is the most important.. And which I need to implement..

THANK YOU Marty
 
I don't do 'short' do I?!

Just looking at FASTBUS at the moment and chasing out the pins of the M8110 slots. I am thinking of building a combined NVRAM/EPROM card consisting of a Douglas Electronics 11-DE-HEX prototyping board and a mezzanine card (holding most of the chips) as the Douglas card will only accommodate 14/16 pin DIP parts. When I have got my spreadsheet together for the slot pin-out it will be interesting to compare it to the work you have been doing.

I am looking at 2 off 128K*8 NVRAM chips and 2 off 27256 EPROMS with various mapping options (switchable from the card). I could put various bootstraps and test code in the EPROM and map sections of it into the I/O area as appropriate (e.g. to mimic the M9301 console emulator and bootstrap card). I could also place parts of the NVRAM into I/O space (as well as or instead of the EPROM) so I could change the contents 'on the fly'. I was thinking of just the FASTBUS interface though - not the UNIBUS-B interface at this point in time (as not including the UNIBUS interface would mean that I don't need to procure bus drivers).

It'll give this a think whilst I am on vacation...

Dave
 
Last edited:
Hi All;

Dave, I am interested in Your Board.. "" Just looking at FASTBUS at the moment and chasing out the pins of the M8110 slots. ""
I have the board pin out (M8110) on a sheet of paper, (somewhere), but Not where they Go to/from on other boards..

"" I was thinking of just the FASTBUS interface though "" I Understood..

Also, on a different note Guy sent my two Boards out Yesterday, so I hopefully should get them later this week.. (KM11 and UA11)..

I am in the process of copying into a NoteBook Post #140, I can then Understand it better then..

"" Performing a HARD reset (HALT and START simultaneously from the console) should load a fixed default value into the PSW. I can't quite remember what the value should be though at the moment. I will go and hunt it out... EDIT: OCTAL(000340). Perform a HARD RESET; set the LOAD ADDRESS to 177776; EXAMINE - should give you 000340. LOAD ADDRESS and then EXAMINE should give you the same result (when cold and working). I am assuming the address and data will go 'berserk' when the machine warms up... "

Doing a Hard Reset and doing a LOAD ADDRESS to '177776 and then an EXAMINE gives me on the DATA Led's Nothing !!!
!!! should give you 000340. !!!
on DataPath switch '000000,
on Bus Register '777776,
on micro cpu '170
on display register '000000..

At this point I am NOT sure that it is the fault of The PSW, but that Our EXAMINE Isn't working correctly . ? . ?
OK, I Deposited part of a program at '001000, and it shows up with Examine..
So, something with (Maybe) the upper I/O Addresses isn't correct..
I faintly remember that with the 11/45 I need to Not use Examine for '777776, but Display Register set to the Correct Register which I am going to check out before going on a tangent..
Looking at the Doc's, I think, it's only the 'R' Registers that use the Display Register mode..
So, If that is the case then, I need to Look at the TRAP Board (M8105) and see what happens when I access '777776 or any in this Range..

OK, I have made some Progress..
I have checked out my Trap Board, and in the Address Range '777770 thru '777776 it is OK, I followed each IC through and at Address '777570 it is OK as well..
I also tried accessing address '777776 with a Deposit and then an Examine, and that works, I could put '000340 in and Examine it and it was there..
So, after a Hard Reset, I need to Find and Locate where the '000340 that Dave mentions is Deposited into the PSW Register.. As it's not there..

I Just did something else, I did an Examine of '777776 and it showed '000000, so I Deposited '000340 into it and then went and Examined that address and '000340 was there..
I then did a Hard Reset and went back and Re-Examined '777776 and it was '000000, so with a Hard-Reset it Clears PSW..


THANK YOU Marty
 
Last edited:
I have just rechecked the PSW register schematic and now convinced myself that the PSW does get initialised to zero on a CONSOLE RESET!

So your 11/45 is probably telling the truth - although I could have sworn that to disable all interrupts you would set the PSW to 340 (and I would have thought that interrupts should be disabled on a CONSOLE RESET).

I may need a vacation :)...

Perhaps Fritz can help out here with his machine?

The document "PDP-11_Mainframe_Troubleshooting_Guide_Dec76.pdf" on page 25 of 122 has the state of the PDP-11/45 CONSOLE LIGHTS after a CONSOLE RESET. This should agree with what you have found (thus showing that your 11/45 CONSOLE RESET is working as expected).

Dave
 
Last edited:
Hi All;

Dave, Thanks for the Correction..
I also found an Interesting thing, from EK-11045-MM-007.pdf, on Page 18 it shows for a KB11-D that it has the
M8132 IRC Slot 8,
M8123 RAC slot 9, and
M8119 UBC slot 12..
So these Boards could work in the 11/45, possibly either with each other OR with Slight Rewiring..
Also, I would like to find a Schematic of the M8119 Board.. OK, I found the Schematic MP00039_1155vol1..

THANK YOU Marty
 
Funnily enough I was just looking at exactly the same page of that manual thinking a similar thing!

It's the "slight re-wiring" that may be the key ---- to a completely non-functional machine that doesn't work with either board set :-(...

Does anyone know if the backplane wiring for the KB11-A and/or MF11-LP is available somewhere - or the pinouts of the 11/45 cards themselves?

Having almost finished my pinout diagram for the M8110; I am beginning to think this will be an indispensable debug aid for the future. If anyone knows of the whereabouts of any documentation - that would save me a job. If not, I would be quite happy to produce a spreadsheet for the cards in my 11/45 (KB11-A processor, FP11-B floating point processor and KT11-C memory management unit) as I have readable schematic drawings.

Dave
 
Hi All;

Dave, Interesting that we both had looked at the same page..

"" Does anyone know the pinouts of the 11/45 cards themselves? ""
Remember, I have these in my 11/45 PinOut NoteBook.. And the M8132 and M8123 PinOut in my 11/70 PinOut NoteBook..

"" Does anyone know if the backplane wiring for the KB11-A ""
That I Don't have, BUT, we can make it, I did that Partially with my Board Checker and my Digital Pulser, it would take some time to make, but it could be done.. Also there is a guide for the 11/70 that on some of the boards (the first six boards and the Timing board) and some checking out would be a guide..
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1170/KB11-C_signalIndex.pdf

I am starting a NoteBook with this information for the 11/45..
I have the information for the Data Paths Card copied (from the 11/70 list) down into the NoteBook, I still need to do an Actual check of the connections, tomorrow..
And if all checks out, I will continue on the GRA Board..
Dave and Fritz, I still need to make some PDF scans of what I have in my NoteBooks, and find a way to share the information with You..
The files would be quite Large and if I used my Email they would have to be broken up into smaller files to be able to be sent..

THANK YOU Marty
 
Last edited:
Hi Guys,

I'll check the after-console-reset value of my PSW when I get home tonight and update here. (Edit: confirmed that PSW is set to 000000 on console reset.)

Re. card pinouts and/or backplane wire-list for the KB11-A: I have never seen these, but would *love* to have them on hand. Maybe we could split the work of compiling these from the engineering drawings? (Edit: just noticed Marty says he has a head-start on the card pinouts in one of his notebooks.)

I would also really like to track down the DEC ECO's for the KB11-A cards and backplane, KT11-C cards, and FP11-B cards... I think Al said a while back he might have some of these in his scan queue?
 
Last edited:
Thanks for the feedback on the PSW.

I have started a spreadsheet and added the M8110 for starters (only a few pins that are unreadable from the schematics). I will have a look at some of the other cards when I get back from vacation. Perhaps if I enter them and you verify what I have done? That way we might eliminate some of the 'stupidity errors' that I introduce! It would also be useful to check what I have done against the actual cards to see if what I have as "not connected" is really not connected! I have 'guessed' at a few places - but these are logically deduced guesses...

I remember the hard work I did trying to resolve the schematics for the Apollo Guidance Computer to produce an FPGA implementation. It took me a while - but I got a working Apollo Guidance Computer out of it. Most of the errors were misspellings (e.g. using the letter 'O' instead of the number '0'). Ditto for I and 1 and Z and 2. There was also some confusion between the logical inverse (with a '/' in front of the symbol) that got magically changed to '1' on some of the schematics. Because signals left and entered at random onto the schematics - there was no consistency about how a signal was cabled up at all. They used three-input NOR gates throughout - but in open collector or pull-up type. This means that to synthesis (say) an 8-input gate - they used a pull up gate and open-collector, WIRED-OR gates for the others. To resolve all this 'mess' I entered all of the 5000 odd gates into an EXCEL spreadsheet - complete with their wiring or symbol names, and wrote an EXCEL BASIC macro to parse the data identifying inconsistencies. This worked beautifully and (once the logic issues were resolved) I used it to automagically generate the VHDL code for me. Simples!!! Mind you, it took me a few years to get right - as gates had been used as signal delays and the VHDL synthesis tools 'got rid' of them! But that's a whole other story. I must get round to documenting this saga one day...

Anyhow - I would plan to use some much simpler EXCEL BASIC to checkout what has been entered at the pin level to make sure it makes sense. The first pass will be to just get the slot and pin numbers in plus their signal descriptions and whether they are an INPUT, OUTPUT, OPEN COLLECTOR, TRISTATE or BIDIRECTIONAL and see how it goes from there.

I think I may have a copy of the ECO stuff I obtained from somewhere. I have just had a look on the web but can't find it again. I will have a look at my 'ever-expanding' 11/45 directory on my home machine when I get back home.

Dave
 
Hi All;

Thank You Dave and Fritzm for what You have done..

"" I have started a spreadsheet and added the M8110 for starters (only a few pins that are unreadable from the schematics). ""
I had the same problem when I did mine and with No Board to verify an connections and any NC's.. I had to leave it at that for now..

"" I will have a look at some of the other cards when I get back from vacation. Perhaps if I enter them and you verify what I have done? That way we might eliminate some of the 'stupidity errors' that I introduce! It would also be useful to check what I have done against the actual cards to see if what I have as "not connected" is really not connected! I have 'guessed' at a few places - but these are logically deduced guesses... ""
I have already found a few mistakes, and I will use the tester to find what is correct, as I fill in my WireList sheet in my NoteBook..

Today I have three things to try and get done or partially done.. One is finish copying Dave's Post #140.. Second related to that is to copy down the MicroBreak sequence code when the machine is working and again when it is broken, and compare the two.. Since it is (I think) a closed loop.. And Third work on copying the Signal/WireList and verifying it..

I need to get going on to my thursday morning Bible Study so I will be back in about 3 hours and then can start working on what has to be done..

THANK YOU Marty
 
... This worked beautifully and (once the logic issues were resolved) I used it to automagically generate the VHDL code for me. Simples!!! Mind you, it took me a few years to get right - as gates had been used as signal delays and the VHDL synthesis tools 'got rid' of them! But that's a whole other story. I must get round to documenting this saga one day...

Do tell more :->. Is your VHDL documented/published anywhere?
 
Fritzm wrote: (Edit: confirmed that PSW is set to 000000 on console reset.)

I thought I remembered reading that somewhere, that at least some PDP-11's come up with interrupts enabled. But my rememberer isn't as good as I remember it being and I spent some time trying, unsuccessfully, to find that web entry yesterday. As a result I decided to butt out.

"Even a fool, when he holdeth his peace, is counted wise: and he that shutteth his lips is esteemed a man of understanding." -- Proverbs 17:28 (Marty did mention Bible study. ;-)

The particular reference IIRC was to the exciting and unpredictable things that can happen if an interrupt occurs after RESET but before the PSW has been loaded to disable interrupts and no interrupt handlers have yet been established. Note that some of the "quickie" code on the web that is intended to diagnose and test at a minimal level goes to the trouble to initialize the interrupt and trap vectors, and some does not, possibly resulting in a machine that can "go into the weeds" in an unpredictable and often non repeatable way. Something for you guys to keep in mind while the rest of us are reading over your shoulders.
 
Hi All;

Pbirkel and Dds Thank You for Your Questions and input..

"" I thought I remembered reading that somewhere, that at least some PDP-11's come up with interrupts enabled. But my rememberer isn't as good as I remember it being and I spent some time trying, unsuccessfully, to find that web entry yesterday. As a result I decided to butt out. ""
Actually, I would Rather that You Speak up, not only from the Stand Point that I know what You have to say, and sometimes, it triggers a thought that I would not already have thought of without Your input..
And I also know that others of You out there are actually following along.. So, Please speak up..
DDS Thank You for the Bible Verse..

"" The particular reference IIRC was to the exciting and unpredictable things that can happen if an interrupt occurs after RESET but before the PSW has been loaded to disable interrupts and no interrupt handlers have yet been established. Note that some of the "quickie" code on the web that is intended to diagnose and test at a minimal level goes to the trouble to initialize the interrupt and trap vectors, and some does not, possibly resulting in a machine that can "go into the weeds" in an unpredictable and often non repeatable way. Something for you guys to keep in mind while the rest of us are reading over your shoulders. ""
Sometimes I/we need the thinking whether out of the Box or not from the rest Of You.. Even if it goes into the weeds, If I know why or have an explanation, I am just as happy with that..

"" Do tell more :->. Is your VHDL documented/published anywhere? ""
I would Love to see a VHDL of the 11/45.. It would be Interesting to see what that program comes up with in it's implementation.. Just like Dave did with the 8i it did the same thing, using different IC's..

THANK YOU Marty
 
Apollo Guidance Computer - AGC.

I don't want to hijack Marty's 11/45 thread - but for a bit of light relief from PDP-11's...

I have always been interested in the Apollo moon landings ever since I was a youngster back in 1969 - being woken by my father and wrapped in a blanket so we could watch the moon landings live on some grainy black and white TV at some unearthly hour of the morning (if I remember correctly).

So, my interest was woken many years later when I came across this website http://www.ibiblio.org/apollo/ containing a software emulator of the AGC complete with the actual software for the command module (Colossus) and Lunar Lander (Luminary) that had been reconstructed from old listings.

The schematics are also online at http://klabs.org/history/ech/agc_schematics/.

I was looking for an 'excuse' to learn VHDL for programming FPGA's (up until that point I had been using schematic capture) so I decided to try and implement the AGC on an FPGA. Sounds simple - bad move! The AGC is basically combinatorial logic with the registers, counters etc. arranged as cross-coupled 3-input NOR gates. This works find if you are using basic NOR gates - but bring it anywhere near an FPGA (which is a sequential logic device) and you get problems. So, after many false starts and long nights toiling away with large drawings and EXCEL, I managed to succeed in getting a hardware implementation that worked and would run Colossus, Luminary and the AGC equivalent of the MAINDECS. Whether it does really work or not - we haven't yet found out as we haven't built a rocket large enough to test it out!!!

Interestingly, when I ran the AGC equivalent of the MAINDECS, I was getting errors. After a few e-mails to the software emulator author - we pin-pointed some deviations in the software emulation from the real hardware. The MAINDECs had been modified by the author to run with the software emulator (on the assumption they were in error). Interestingly, when I reverted the code back to what it was, it passed muster on my FPGA. So, I am fairly confident my FPGA implementation is pretty accurate.

Version 1 of the VHDL code can be found at http://opencores.org/project,agcnorm. There is a version 2 that I haven't published yet (I found a couple of areas where multiple inverters were connected in series to apply delays to certain clock signals).

You need a logon to opencores - but if anyone wants a copy I am quite happy to provide you with one directly. Just send me a PM.

OK - enough foolishness - back to Marty's 11/45...

Interesting about the PSW on a hard reset. I must admit - my train of thought was "this is how it must work so that must be what DEC did". However, when you actually check the schematics - it sets the PSW to 0 (and this is clearly not a documentation error as we have two 11-45's that actually do it!).

We are all 'fools' here - but trying to gain knowledge by learning together. Sure, we will make mistakes, go off the beaten track, get lost etc. etc. etc. but in the end we will get a few 11/45's back to health and learn an awful lot in the process. As with Marty's PDP-8 thread - there will be enough information in these threads on the 11/45 to write an entire book with...

Marty: If you want to see the (beta) VHDL for an 11/70 have a look at http://opencores.org/project,w11.

Dave
 
Last edited:
Hi All;

Dave, Thank You for Your Information..

On the AGC.. I had some years ago looked into this a little, but, I was not interested in it enough to go further with it..
BUT, it is Very Interesting Read, and I would like to know more of what You did.. And How You figured out what needed to be Done, these kind of things that various people do I and hopefully Others would very greatly like to hear about..
The How's and Why's of what You did, even if it is not 11/45 related..
The Story can not only entertain the rest of us, but give us some examples of the How's to do things..

"" Marty: If you want to see the (beta) VHDL for an 11/70 have a look at http://opencores.org/project,w11. ""
I had Found this a little while back, But as I Don't Remember my name nor my Password for it, I haven't pursued it any further at the Present..

"" OK, back to Marty's 11/45... ""
I have followed with a Very Slooooooooow clock the Microcycles, and for both Load Address and Examine, I get the Correct values..
So, now I need to let things warm up and see what I get for each of them..
Right now my main Problem is that it is a cooler day, and I can't get the Cards Temperature up to where it will fail, I even have my notebooks lying on top of the Boards to help hold in heat..

THANK YOU Marty
 
Last edited:
Hi All;

I found something, when my clock is 3.55 Mhz, (I don't think this has any effect on things) and I am in Single Pulse mode after I do my Load Address, so it is starting at address '170 (Con.00), I press EXAMINE and while doing that I press Single Step enough to get a Recognition of it being in Examine mode, and then release the Examine button so it should be '070 Exm.10, but instead it shows '073 (Dep.10) then '015 (Res.00) then '255 (Res.10) then '374 (Res.20) then '331 (Fet.01) then '240 (Brk.90) then '154 (Brk.00) then 170 (Con.00)..
I haven't tried this sequence Repeatedly , But I would say this is Weed Category..
I have Now Repeated this and it Does do the same thing over and over..

THANK YOU Marty
 
Last edited:
"Right now my main Problem is that it is a cooler day, and I can't get the Cards Temperature up to where it will fail, I even have my notebooks lying on top of the Boards to help hold in heat.."

Our #1AESS processors were qualified before acceptance to run 24 hours with no faults in an "oven" heated to 105F. The idea was to have the ability to keep switching phone calls if the building's HVAC failed and couldn't be fixed right away. Very few processors are required or expected to run at that kind of elevated temperature. I know for a fact that the gear that replaced the #1A's won't. Contrast that with DEC's instructions not to run a PDP11/23 without all 3 fans running. At SERDAC our DEC hardware was fed cooled air from under the floor at all times.

As an example horror story, a few months back I was running an XXDP routine to exercise the drives on an RX02 when my wife called me to come to dinner. After we ate and I returned to my garage office the smell of "magic smoke" was almost overpowering. It seems that there was a paper label inside the RX02's plenum that chose that particular time to become detached from its 30 year old adhesive and jam the fan. Result..... dead RX02!

So be very careful heat stressing your 11/45. You may be causing causing problems faster than you can find & repair them. ;-)
 
Last edited:
Hi All;

Thank You DDS, for Your Informative answer..

I am not letting them get too hot, Just slightly warm, to cause the offending chips to fails..
I know about Running Boards Hot and all that it involves..
Where I worked many Years ago, We "Burned in" our Boards after a first fixing/testing of them to have then run..
Then they Were "Burned in" for a few Days, at an elevated temperature Running all the Time, We had a few small fires But over all it made sure that the Ic's in there would take the abuse.. We then Re-tested all Boards and Fixing any that had died..
This was the Approved Method of the Day, We found that If this was not Done we would get all kinds of Returns for Dead Boards, after this We Very rarely got returns for Dead Boards..

THANK YOU Marty
 
So, that information is really interesting!

The reason the EXAMINE microcode is not working properly is that it is never being executed!

Even after the DEPOSIT microcode word is executed - it is still not going to the correct word after that - but bombing out to RESET...

If you leave your machine until tomorrow and repeat the test does it consistently go wrong again?

The reason for the fault could be one (or more) of the following which you will have to look at one at a time.

With the microcode address set to 170 what output is coming from the microcode ROM (and the associated inverters) attached to the UAD field (E89 and E90 on drawing RACD)? The value (according to the microcode ROM listing) should be 070.

The next question I am going to ask myself is: is the console panel and the associated logic on drawing UBCH working correctly? The console generates the EXAMINE signal - but the logic on UBCH identifies what the previous console command was and 'merges' it with the current console command. So if the last command was "LOAD ADDRESS" and you then press "EXAMINE" you get EXAMINE, but if the last console command was "EXAMINE" and you press "EXAMINE" again you get the command "EXAMINE STEP" (i.e. a different microcode word is executed at 071 instead of 070 for the examine).

The next thing to look at (if the UAD field is wrong) is: are all the ROMs getting the same (correct) address? As I have mentioned before, there are multiple microcode address latches driving different banks of ROMS. One of the sets of address latches goes to the console microcode address display - but others don't. So 170 may be indicated as the microcode address on most of the ROMS - but the latch driving the UAD ROMs may (erroneously) have the wrong address latched into it (and hence presented to these ROMs) thus making the UAD field wrong - with the result that the microcode state machine dies a horrible death! Check the address lines on ALL the microcode ROMS to make sure they are 170.

The only other thing (apart from a faulty ROM somewhere) is the logic that determines which microcode address to 'branch to' based on the UAD microcode ROM field and the external logic (e.g. the EXAMINE or EXAMINE STEP stimulus from the console).

Perhaps a bit of bedtime reading on how the microcode state machine works is in order?

The microcode state machine branch logic is on drawings RACH, RACF and RACK (I think). This is not a nice bit of code - but the UAD output from microcode state 170 (070) should combine with the console signal for EXAMINE to produce the latched address 070. See which address lines (before the latch time) are 'wrong' and try and work back through the combinatorial logic gates to work out why.

If the next state after 170 is not 70 this is what you need to chase down - and using the microcode single step will be your friend. Your mission, should you chose to accept it, is to track the errant chip down... Which reminds me, I have the latest 'mission impossible' film recorded that I haven't watched yet...

Enjoy whilst I am vacation and I hope it is fixed by the time I get back :). Thanks for all your hard work Marty - you are an inspiration.

Dave
 
Hi All;

Thank You Dave for Your synopsys of the problem, have been slowly replacing each of the Microcode Address latches, and they are all done now..
I works for a little bit, but it goes to never never land..
My thought is I am going to look at what bits get changed in the Various Exm.xx codes. and check those out..
I earlier went and bent out any close traces, and it seemed to work slightly worse, so I will Recheck that, that I didn't accidentally short something out..
Post 159 needs to be added to the NoteBook..

On another note, I got my two boards from Guy, they are Great, and they were well packed..

THANK YOU Marty
 
Last edited:
Back
Top