Image Map Image Map
Page 3 of 12 FirstFirst 1234567 ... LastLast
Results 21 to 30 of 112

Thread: PDP 11/45, Part 6

  1. #21
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    Dave, Thank You for Your Posts..
    "' Before I 'reinvent the wheel', you have tried running the tests contained on pages 2-9 through to 2-17 of http://bitsavers.trailing-edge.com/p...45-MM-007.pdf? ""
    No, and Yes, with Looking at the pages, I can do some things, Like Deposit and Examine, But, I need to go thru these and check them out..

    "" Are you single microcycling or have you slowed the clock down? ""
    I have done Both and each one, one at a time..

    Using the Power Supply, in my Heathkit Microcomputer Learning System, and after I have removed all of the socketed Parts, Which I now can use to test some Parts..
    I have wired up a circuit for the 74S04, and I have put in a Signal and made sure it showed up after wiring it up through all of the Inverters on an Led..
    And they all pass, the ones that I have Socketed on the Board, so six of them are OK..
    Next I will test the 74LS174's and lastly the 74LS74's that I have socketed..
    After that I will wire up a 74S64 to mimick what I see in the Schematic and then I will see what pins I can toggle with my Digital Pulser and with an Led see the Output, I can then go the the PDP 11/45 and make an attempt to toggle that same IC Circuit and see if the Part shows the same behaviour, then change the wiring for the next 74S64, in the 11/45..
    That way I can lessen what 74S64's I will possibly replace.. Since this Board has a boatload of them..

    THANK YOU Marty
    Last edited by Marty; July 20th, 2017 at 11:24 AM.

  2. #22
    Join Date
    Dec 2011
    Location
    Oakland, CA
    Posts
    125

    Default

    Quote Originally Posted by daver2 View Post
    The reason for the multiple entries of (for example) FET.00, FET.01, FET.02 etc. (and Fritz can correct me here if I am wrong) is that there are multiple addresses in the microcode PROMs containing the same micro instruction (something to do with how the microcode branching is achieved - i.e. it uses logic to manipulate the bits in the lower part of the microcode). So, the first microinstruction of the FETCH cycle can be found at any of the 10 locations specified in the parenthesis.
    Yup, exactly so! The branching mechanism for the microcode is pretty limited -- for a multi-way branch, the offsets between the various possible target addresses are fixed. So the microcode is fit together like a bit of a jigsaw puzzle in order to set up available target addresses without conflict. Sometimes this means duplicating a microinstruction at multiple addresses, particularly when it must be targeted from lots of different source locations.

    Also, +1 on the sequence of tests that Dave mentioned in the maintenance manual -- they are easy to do and when done in sequence can give a good idea of where to look. I found this sequence very useful when I was bringing up my CPU.

  3. #23
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    Thank You, FritzM for Your Verification..

    On my Testing of the Various Ic's that I have socketed, it looks Like (so far) I have found Four of them that are Possibly No Good.. And one of those didn't Respond at all.. The Others just didn't Look Correct in their Response to my Test, they Responded different than the Good ones..

    THANK YOU Marty

  4. #24
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    Yep,

    Dead ICs - no good...

    Dave

  5. #25
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    Dave, Your snoposis is correct, and my tests are not conclusive, but, I would rather be on the safe side..

    It did not make any difference, while using my "CONT" switch, and that still Bugs me.. And this Error could cause other Micro-code problems..

    Anyway, FritzM Could You do me a Favor, If You have an Extender Can You Extend the Rom Board (M8103), and put in Dave's Program
    starting at Address '000000 put in 000257, 000277, 000257, 000277, 000000, 000000..
    Can You Single step the Micro-code ?? If You can then Press Load Addr and then Examine and then switch to Single Step and Hold down the "CONT" key, while pressing the Stepping switch multiple times while in UAddrs/FPP/CPU and when You get '130 displayed, stop Single Stepping..
    Get out Your Scope, and Tell me what each pin of IC E80 is showing on the scope (high or Low, 1 or 0), and hope fully I can tell which pin is wrong for the output to be a '0 instead of a '1.. And follow that back to its Gate..
    So far on IC E80, pin 1 is H,
    pin 2 is H,
    pin 3 is L,
    pin 4 is L,
    pin 5 is H,
    pin 6 is H,

    pin 8 is H,
    pin 9 is H,
    pin 10 is L,
    pin 11 is L,
    pin 12 is H,
    pin 13 is H..

    And I need pin 8 to be Low.. That is unless my way of thinking is WRONG !! But with pin 8 High then the Next Micro Address is '120 Instead of '100..

    THANK YOU Marty

  6. #26
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    I don't understand why you want it to go to micro address 100 (PUP.00) from micro address 130 (BRK.10)? The correct place for it to go (assuming you are pressing CONT) is to micro address 120 (BRK.20) - which is where it does appear to want to go to...

    Just because the UAD field contains 100 doesn't necessarily mean that is where the next micro address will be. The value stored in the UAD field may be modified by external influences (i.e, it is a form of 'base' micro cycle address). For example, BRK.10 (130) on FLOWS 12 can end up in 1 of 4 locations : 100, 120, 140 or 160.

    Dave

  7. #27
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    Dave, Thank You for Your Setting me straight !!!
    "" I don't understand why you want it to go to micro address 100 (PUP.00) from micro address 130 (BRK.10)? The correct place for it to go (assuming you are pressing CONT) is to micro address 120 (BRK.20) - which is where it does appear to want to go to... ""

    I Don't Understand How You got Micro address 120, since when I looked at it, I thought it was supposed to go to 100..
    I am More than Happy to find out that Micro Address 120 IS Correct, and I don't have to worry about it any Longer..

    So, back to my basic Question, How do I know IF something is working Correctly or Not ?? Since I am not able to figure out How to follow the FLOWS Diagrams Correctly.. Not Your Fault !!

    "" Just because the UAD field contains 100 doesn't necessarily mean that is where the next micro address will be. The value stored in the UAD field may be modified by external influences ""

    Which is where I can't seem to get the when and the where this happens..

    "" (i.e, it is a form of 'base' micro cycle address). For example, BRK.10 (130) on FLOWS 12 can end up in 1 of 4 locations : 100, 120, 140 or 160. ""
    OK, I didn't Understand this from the Descriptions before..

    So, PLEASE give me some program that I can see whether it truly IS or IS not working correctly..

    OK, I have taken the ROM Board OFF of the Extender and put it Directly into the machine, I await Your Input..

    THANK YOU Marty
    Last edited by Marty; July 21st, 2017 at 01:37 PM.

  8. #28
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    No problem!

    The simplest way is for you to just post which micro addresses are being executed when you step through my noddy program. I will be quite happy to work through what should (and shouldn't) be happening. But (of course) this doesn't expand your knowledge - so let me try and explain a bit further...

    Looking on FLOWS 14 you will see CON.10 which is at address 077 (the number at the top right-hand corner of the box in brackets). The number in brackets at the bottom right-hand corner of the CON.10 box is 130.

    This will be the value that should be in the UAD field of the microcode at address 077. In the microcode field BEN (which sometimes seems to be called BEF in the documentation just to confuse everyone) for address 077 you will see a value of 00. This means that no modifiers are to be applied to the address held in UAD and (therefore) it follows that the next micro address (after 077 that is) is contained in the UAD field (which is 130). I am getting all of this from the OCTAL microcode dump on PDF page 77 of the 11/45 system engineering drawings dated Jun 74.

    Back to FLOWS 14 and you will see that the exit from CON.00 (address 077) just contains one line and it goes to the diamond shape containing the text "BRK.10 12" meaning there is only one exit from this state to BRK.10 on diagram FLOWS 12. Let's go there...

    So, on FLOWS 12 we come in at BRK.10 (address 130).

    The text at the bottom of the box states "BEN13(100)". What this means is that the microcode field BEN/BEF should contain the value 13 and UAD should contain the value 100. Also note that there are multiple 'boxes' connected to the output of this state (at addresses 100, 120, 140 and 160). Basically, there are four ways out of BRK.10, to one of the four boxes to which it is connected.

    Let's have a look at the microcode dump on page 78 of the 11/45 System Engineering Drawings at address 130 (BRK.10). You should see that the field headed BEN contains the value 13 and the field headed UAD contains the value 100.

    This indicates to me that the next microcode is formed by modifying the value found in UAD (100 in this case) according to some algorithm defined by BEN=13.

    Right, flip over to the KB11-A Maintenance Manual on PDF page 179 Section 7.6.3.3 titled "Branch Enable 13 (BE13)". This sounds very similar to BEN=13 doesn't it?! In here it describes the logic that defines how we modify the value of UAD=100 to get to 100, 120, 140 or 160 depending upon the state of the logic defined by BEN=13.

    You may need to read this description a few times for it to make sense... Why DEC didn't make it more complex I don't know !

    The trouble I have at the moment to give you a program that 'does something' is that I will have to work out how the instruction stream is actually decoded so that we can trace it through the microcode.

    From a quick look at the IRCH drawing (M8102 sheet 8 of 9); the Processor Status Word (PSW) N, V and C status bit flip flops are here (E79/E94). If you monitor the output from these flip-flops - you should see them toggling as the program executes CCC and SCC (clear and set the flags respectively). Monitor (say) E79 pin 6 (the CARRY flag) and it should toggle.

    It is somewhat late here so I will turn in for the night shortly and leave you to mull over this.

    Dave
    Last edited by daver2; July 21st, 2017 at 02:19 PM.

  9. #29
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    Dave, have a good night's sleep and or rest..
    You are a Genious !!!
    I can almost make out what You are saying, But I will Look up Your References and see if reading around what You have quoted..
    Have a good night and see You tomorrow..

    I have gone through all of Your Description and I have all of the Documents, Except I don't have FlOWS 1.. I will need to take that file on a Stick and go to my Copy Center and have one made..

    I think if we go through it on a few more examples, I will get the Hang of it.. (Hopefully)..

    "" From a quick look at the IRCH drawing (M8102 sheet 8 of 9); the Processor Status Word (PSW) N, V and C status bit flip flops are here (E79/E94). If you monitor the output from these flip-flops - you should see them toggling as the program executes CCC and SCC (clear and set the flags respectively). ""

    "" Monitor (say) E79 pin 6 (the CARRY flag) and it should toggle. ""

    Yes, it does toggle..

    Dave, another thought, You Don't need to work out the Micro-code flows for a small Program, unless it doesn't work, otherwise, we could for at least now, check that Instruction of of the list of all instructions..
    Why create more work for ourselves than we need..

    FritzM, You Don't need to do as I have asked above, as Dave pointed out, that all is Fine..

    THANK YOU Marty
    Last edited by Marty; July 21st, 2017 at 05:20 PM.

  10. #30
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    So, success?!

    Firstly, did you find any dead chips that you had to replace?

    My approach to debugging is to start off with no knowledge at all and to build up knowledge as we go (i.e. start off with something simple and make it more complex). If you start off with something complex, you end up going mad trying to debug it...

    Yes, I agree that we don't need to work out the microcode flow for the program to start with, but (if the program fails) we don't know what microcode is at fault. If I have a rough idea what should be happening with the microcode - if something stops doing what we expect, we can use a microcode breakpoint and micro single step to find where it goes into the weeds (as used to happen last time).

    We have found out that CCC (000257) and SCC (000277) appear to work by storing these instructions alternately in memory and single stepping through them using the console switches.

    My proposal would be to always store our test program starting at memory address 1000 (OCTAL) - i.e. away from the TRAP vectors.

    So, if you could load something like the following into memory:

    1000 / 000257 ; CCC
    1002 / 000277 ; SCC
    1004 / 000257 ; CCC
    1006 / 000277 ; SCC
    1010 / 000257 ; CCC
    1012 / 000277 ; SCC
    1014 / 000257 ; CCC
    1016 / 000277 ; SCC
    1020 / 000000 ; HALT

    If you single step the program again from the console it should toggle the flags as it did before.

    Next, try and execute it (without single stepping it) with the 'Marty slow clock'. You should see a 'flurry' of activity on the flags (as they are alternatively set and cleared) and the processor should HALT.

    If this is good, try executing the program at full speed. The flurry of activity on the flags should be much quicker - but the CPU should still halt where you expect.

    Next, let us replace the HALT with a JMP instruction so that we can keep repeating the flag toggling program by modifying it as follows:

    1020 / 000127 ; JMP #1000
    1022 / 001000 ; ...
    1024 / 000000 ; HALT

    Single step this program from the console and make sure it jumps back to 1000 at the end rather than going into the weeds!

    The microcode state for executing the condition code instructions SCC and CCC is CCP.00 at microcode address 044 on diagram FLOWS 3.

    The microcode state for executing the JMP instruction is JMP.00 at microcode address 035 on diagram FLOWS 11 (however, I suspect there is a 'tortuous' route before it gets to microcode address 035 - so let's address that if we have to later if the test does not work)...

    If single stepping from the console is OK, try the 'Marty slow clock' and see if it runs reliably over (say) and hour. Then try the same program at full clock speed over (say) a further hour.

    What we are trying to do here is identify clock-related (speed) issues and/or temperature-related issues. If we can rule both of these out with my simple program we can move on to a more complex program by adding further instructions.

    Of course, you could 'go for broke' and try Fritz's light chaser from http://fritzm.github.io/cpu-debug-5.html. I would (however) relocate it to memory address 1000 rather than 0000 (thus avoiding the TRAP vectors as mentioned above). Fritz's program is relocatable anyhow, so just enter the instructions as defined starting at memory address 1000 instead of 0000.

    Don't forget to set the front panel rotary switch to "DISPLAY REGISTER" and the switch register is used to define a delay between shifts. Too fast and you will just see a blur. Too slow and you may think it is not working... You may have to experiment a bit.

    Don't worry if this goes into the weeds. It will be interesting to know though - as we can build up my simple program from the constituent instructions in the light chaser to see where we have a logic fault. I (personally) would not try to microcode debug the light chaser at this point in time.

    Hope this makes sense?

    I am off to do some assembly for my SBC6120 card (https://www.retrobrewcomputers.org/d...-edition:start) now most of the parts have arrived from Digikey.

    Dave
    Last edited by daver2; July 22nd, 2017 at 04:47 AM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •