Image Map Image Map
Page 2 of 12 FirstFirst 123456 ... LastLast
Results 11 to 20 of 112

Thread: PDP 11/45, Part 6

  1. #11
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    I seem to remember your 11/45 ended up 'in the weeds' last time...

    A little 'teach in' for the microcode - but I may be wasting your time if you know this already...

    First of all, I will be using the 11/45 System Engineering Drawings dated June 1974 (found at the usual place here http://bitsavers.informatik.uni-stut...ings_Jun74.pdf).

    If you go to to KB11-A FLOW DIAGRAMS (FLOWS 14) you will see (right at the top of the page) CON.00 (170). This is the console wait loop. The microcode is quite happily sitting at address 170 (octal) waiting for you to do something with the keys. It will be constantly executing the 'logic' within the square box - and you can see certain data transfers happening at times t1, t2 and t6.

    when you hit the START key, the microcode will branch to KST.00 (address 076); execute the logic within the box and then 'jump' to symbol RES.00 on FLOWS 3. The sheet number is within the diamond symbol.

    When you hit the CONT key, the microcode will branch to CON.10 (address 077); execute the logic within the box and then 'jump' to symbol BRK.10 on FLOWS 12.

    Repeat as many times as necessary...

    It would appear as though the CONT key eventually ends up in SVC.00 (address 355) via BRK.10 (address 130), BRK.20 (address 120), BRK.30 (address 152) and then to SVC.00 on FLOWS 13. It then ripples all the way down to SVC.90 (address 300) and then branches to the INSTRUCTION FETCH microcode at FET.00 on FLOWS 1 (address 217).

    If you remember - logic within angle brackets contained within the microcode boxes indicates diagnostic information provided to help trace problems - but which do not have any meaning for the microcode step itself. The reason may be to display something on the front panel lights that would ordinarily not be monitor-able (e.g. a 'hidden register' not displayable on the console by means of the rotary switches).

    Some logic boxes show multiple 'escape routes' (e.g. CON.00 can go to one of many boxes - or itself - depending upon which key is pressed (if any)). The 'escape route' may be dependent upon logic (e.g. particular bit settings of a register). In this case, the logical expression should be identified on the branch to the various states.

    If you look at state BRK.00 (address 154) on FLOWS 12 - you should see that it would branch to CON.00 (the CONSOLE microcode) if the signal CONF is SET or to BRK.10 if the signal CONF is RESET.

    Hope this is of some help in reading the microcode?

    Dave

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

    Default

    Hi All;

    Dave, Thank You for the Information..

    When I did the above, I did it with a different Timing card, that I had Modified to run at slower speed(s)..
    I have since changed it back to an Un-modified Timing card to see if it shows the same thing..

    I have started another Notebook, with the complete flows Diagrams for the Front Panel switches and possibly later for the rest of the Flow Diagrams..

    I have left the Front Panel in u Addrs /CPU Display mode, and I am single stepping it..
    I have confirmed that Examine is OK..
    I am going to see IF the 'CONT' switch does as it did before, and report what it shows in a few minutes below..

    "" It would appear as though the CONT key eventually ends up in SVC.00 (address 355) via BRK.10 (address 130), BRK.20 (address 120), BRK.30 (address 152) and then to SVC.00 on FLOWS 13. It then ripples all the way down to SVC.90 (address 300) and then branches to the INSTRUCTION FETCH microcode at FET.00 on FLOWS 1 (address 217). ""

    It follows Your posting (which I have charted all the way through),

    So my best guess is either the Prom Output is Correct and it is further down the Logic line OR

    I blew it and the PROM is not blown correctly..

    I will need to do some checking..

    Tomorrow I will be out, so I won't get anything done then, We'LL see what I can find today..

    First, I will check the Prom !! Prom 89 is correct..

    I put the ROM Board on an Extender.. I have lowered the clock speed and see if that Helps, it still does the same thing..
    So, it's a hard error problem..
    When I can I need to trace it back through the gates to see where the problem seems to exists..

    THANK YOU Marty
    Last edited by Marty; July 19th, 2017 at 04:54 AM.

  3. #13
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    Marty,

    Just looking where to go next...

    Here is what I should do.

    Enter a program of condition code modification instructions (e.g. Clear Condition Codes = CCC = 000257; and Set Condition Codes = SCC = 000277). I would alternate CCC with SCC as follows:

    000257
    000277
    000257
    000277
    ...

    The reason I have chosen these instructions first is it should be easy to trace them through the microcode:

    ; From diagram FLOWS 1

    FET.00 (217) Fetch instruction.
    FET.10 (260)
    IRD.00 (343) Decode instruction.

    We then end up doing a 'mega microcode branch' depending upon the instruction decode - which should take us to diagram FLOWS 3.

    CCP.00 (044) Execute instruction.

    Back again to FLOWS 1 at FET.00 (217) for the next instruction.

    This should pickup where you start to go into the weeds if it all goes wrong somewhere...

    Dave

  4. #14
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    Dave, I don't quite understand, in Your FLOWS, how You get what you get..

    I am assuming that what You are saying is that with the Instructions 257, 277, etc., that it will show 217, 260, 343, 044, 217 and so forth..
    But, when I look up what it shows in the Proms, I see, for Fet 00, 217, 240, 154, 130, 100 etc., and for Fet 10 I see 260, 343 , 377, 377.. And for CCP I see 044, 217, 240 154, etc...
    And so with a possibly broken CONT Switch Logic Circuitry, I would need to make that work, to see the correct sequence for Your Simple Problem..
    Now what I do see is after Entering Your Program in Memory for 16 memory Locations and them 16 memory locations with all '000000..
    I Load the Address, doing an Examine, and then Depressing the CONT Switch, It counts in Binary (both the same) in the Address and Data fields, up for those 16 places..

    THANK YOU Marty

  5. #15
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    Sorry Marty, let me explain further and (hopefully) things should be more clear? My bad for my poor explanation to start with.

    If you look at diagram FLOWS 1 it shows the following:

    FET.00 (217)
    FET.01 (331)
    FET.02 (332)
    FET.03 (334)
    FET.04 (164)
    ...
    FET.09 (265)

    The item "FET.00" is the symbolic name assigned by DEC to a specific microinstruction. The number in the parenthesis indicates the microinstruction address that this microinstruction resides at. The number in parenthesis is not the data to be found at that address (so looking in the microcode PROM is of no use).

    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.

    The next microinstruction of the FETCH cycle can be found at any of of the four locations assigned to either (FET.10, FET.11, FET.12 or FET.13).

    The INSTRUCTION decode microinstruction (IRD.00) will only be found at microaddress 343.

    You then end up at this mega branch which will only take you to CCP.00 (at microaddress 044); and then back to FET.00 at microaddress 217.

    I went back and re-read your post again. Sorry, I think I got the wrong end of the stick (Dooo).

    Microaddress 240 is BRK.90 (i.e. the exit point - ultimately - back to the console microcode).

    Sorry, I meant to run the program of CCC, SCC, CCC, SCC not to single step it (if that is what you are doing).

    Dave

  6. #16
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    Dave, No Problem, "" Sorry, I meant to run the program of CCC, SCC, CCC, SCC not to single step it (if that is what you are doing). ""
    Yes, I was Single stepping..
    The Addresses I was giving were the UAD Addresses from the Prom for the next address for the next Micro-Instruction, without any modification..
    I will get back to things in a bit, after I re-read Everything again.. I will also compare each of the FET Micro-instructions to see if they are the same, I am not sure that they are..

    THANK YOU Marty

  7. #17
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    Single stepping my program will definitely cause some results other than what we want.

    The important thing is what microaddresses are executed in what order - not necessarily what the unmodified UAD code is at that point.

    I randomly checked a few of the FET.0X microinstructions and they 'should' contain the same data. If not - Houston we have a problem!

    Dave

  8. #18
    Join Date
    Jul 2009
    Location
    Boulder , Colorado USA
    Posts
    2,994

    Default

    Hi All;

    "" I randomly checked a few of the FET.0X microinstructions and they 'should' contain the same data. If not - Houston we have a problem! ""
    Dave, that is something I didn't know !!!

    What should I expect when I use "RUN" for what I see on the Front Panel ?? And How the '45 re-acts ..

    THANK YOU Marty

  9. #19
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,006

    Default

    >>> What should I expect when I use "RUN" for what I see on the Front Panel ?? And How the '45 re-acts ..

    There will be nothing to 'see' regarding the execution of the program as such (apart from the PC incrementing). I also forgot to say put a HALT at the end of your CCC, SCC sequence didn't I?

    The important thing (at this stage) is - what microcode addresses are being executed.

    If the correct microcode states are being executed - it partially demonstrates that instructions are being fetched and partially decoded and executed (for the simple case of the CCC and SCC instructions at least). I picked these because they are a single word instruction, have no operands and end up in a single, neatly defined microcode state for execution (CCP.00 at microaddress 044).

    If this looks good (and doesn't go off into the weeds) we can look at a more complex instruction that we can use to see something happen on the front panel...

    You could monitor the condition code bits of the status register of course - whereupon you should see the flags being alternately set and cleared of course.

    Are you single microcycling or have you slowed the clock down?

    Dave

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

    Default

    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?

    Dave

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
  •