Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 29

Thread: PDP-11/34A interrupt problem

  1. #1

    Question PDP-11/34A interrupt problem

    Hi all, long time reader first time poster. I probably met some of you at VCF East this year, I attended for the first time.

    I recently came into a few PDP-11/34A systems, and I'm bringing the first one up. A lot of things seem to be going well, but I've run into some problems that I am not sure how to address, as this is my first non-emulated PDP experience.

    First, a summary of the problem: I cannot boot XXDP images (from AK6DN, using tu58em) from an emulated TU-58 disk to begin vetting the system. However, basic operations seem to work. I am starting to suspect an interrupt controller problem.

    What works:
    • The system boots and displays a ROM monitor prompt on an attached serial terminal.
    • Simple machine code programs can be entered and run via either the serial console or the KY11-B programmer's console.
    • I can punch in a TU-58 boot loader (I don't have a DD PROM) and load the boot block starting at address zero, it jumps to the address and begins execution.


    However, the boot does not continue; the system halts either somewhere in the image (sometimes at address 540 as I recall, on AK6DN's 1134_1.DSK image) or often at address 10(?).

    In trying to diagnose this, I kept reading that it was critical that the second serial port was at address 176500 (it is) and vector 300 (it [I]should[I] be). I decided that since I could [I]see[I] that it was at the right address, I should [I]test[I] the vector. I pulled a quick program from Diane Neisius's page that causes a successful serial read interrupt to halt the machine at address 300o. However, it doesn't halt! When I run the program, it loops forever and never seems to receive the interrupt. The program is very simple, and I will reproduce it here so people don't have to jump back and forth:

    Code:
    1000 / 012700
    1002 / 176500
    1004 / 012760
    1006 / 000100
    1010 / 000000
    1012 / 000777
    This is coupled with an interrupt vector at 300 that contains the address of a word containing 000000, to cause the machine to halt if the interrupt fires.

    Because I know backplane configuration is critical to interrupts, I will present the configuration of my machine as it currently stands. The NPG pins are jumpered on every slot except 7 and 8 (although I do not believe NPG comes into play here) on the backplane. The backplane contains the following modules (where more than one module is in a slot, it is marked as SUB/MUB; SPC), starting with slot 1:

    1. M8266 CPU control plane
    2. M8265 CPU data plane
    3. M9312 terminator/boot ROM; M7859 programmer's console interface
    4. M7891 MS11-LD 128kW MOS RAM
    5. (empty); M7856 DL11-W serial console/line clock
    6. (empty); M7856 DL11-W serial console/line clock
    7. (empty); grant continuity/NPG continuity card
    8. (empty); grant continuity card
    9. M930 bus terminator; grant continuity card


    Thus I am aware that the NPG chain is broken at slot 8; if this is the problem here, someone let me know and I'll stick an RX211 or RL11 card in there to patch up the chain, but a) as I understand it, that doesn't matter here, and b) I'd rather not complicate things any more than I have to!

    The two DL11-W modules are, if I understand their configurations correctly, both configured for 9600/9600/8N1, with all current loop functionality set to passive. The first module (slot 5) is at address 177560 and vector 60, and the second module (slot 6) is at address 176500 and vector 300.

    As far as debugging goes, I do not have a logic analyzer, although I am able to get access to one if it becomes necessary; I will also buy a UniProbe if I need to. I have lots of other test equipment, though, including several oscilloscopes (one DSO, several analog), piles of multimeters, and a one-bit chirp-and-flash logic probe. If other test equipment seems helpful, ask, I might have it (or have access to it).

    As far as modules, I have access to: four more CPUs, half a dozen more DL11-Ws, different RAM modules of varying sizes, alternate M9312 and M9302 (note that the M930 is not a typo above; it's a little 2" high module that says M930 on the back) modules, and a variety of other I/O modules (disk controllers, other serial/parallel I/O, etc.) for substitution. I hate to substitute willy-nilly, though, because I'd rather not mix up more than I have to before I get things rolling. I would be very happy to perform substitutions that appear to be relevant; I have, for example, already tried an alternate DL11-W in the second position.

    So ... where should I go next? Do I really have an interrupt problem, or am I testing it wrong? Do I need to take some additional steps first? Does the TU-58 boot even [I]need[I] interrupts, or is its boot failure an indication of some other problem that I need to be tracking down? What tools should I be bringing to bear here?

  2. #2

    Default

    I want to clarify (I don't seem to be able to edit my post?) that I modified the interrupt test program to test the console DL11-W at 177560/60, and it also did not appear to interrupt, which is why I believe I may have an interrupt problem.

    I have been wondering this morning if the PSW priority might be set too high, but I haven't had a chance to check that due to Real Work. Diane's page doesn't say anything about needing to check or configure it, but perhaps that's a function of the 11/04 monitor versus the 11/34 monitor?

  3. #3
    Join Date
    Nov 2014
    Location
    Chicagoland
    Posts
    219

    Default

    Enable the LTC using just the Console DL11-W board.

    Use address 177546 instead of 176500 and vector 100 instead of 300. Enable the RTC switches.

    That should tell you if the basic interrupt hardware on BR6 is working. It should halt immediately.

  4. #4

    Default

    Some random thoughts.

    * The 11/03 in Diane's page is somewhat different from the 11/34. The PSW is not accessible directly in the 11/03. It using special instructions for accessing it. In the 11/34 you can write directly to 177776.

    * I am not sure what the default interrupt level is for the system when powering up. Maybe you need to set it so that interrupts occur.

    * As far as I know XXDP doesn't use interrupts.

    * It is very common to jumper the NPG chain on the wire-wrap side of the backplane. So it very likely that your NPG chain is OK. In fact my understanding is that the 11/34 programmers console wouldn't work if it cannot acquire the bus. It uses NPR/NPG to modify memory.

    * I would use PDP11GUI and run a few CPU tests and memory tests to verify that the CPU is working OK. You can download absolute binary files (binary paper tapes) directly into memory and run them from address 200.

    * I actually had a case where the where the interrupt circuitry on a M7856 was broken and had to be fixed to it could be a source of a problem too.

  5. #5
    Join Date
    Nov 2014
    Location
    Chicagoland
    Posts
    219

    Default

    Quote Originally Posted by MattisLind View Post
    Some random thoughts.

    * The 11/03 in Diane's page is somewhat different from the 11/34. The PSW is not accessible directly in the 11/03. It using special instructions for accessing it. In the 11/34 you can write directly to 177776.

    * I am not sure what the default interrupt level is for the system when powering up. Maybe you need to set it so that interrupts occur.

    * As far as I know XXDP doesn't use interrupts.

    * It is very common to jumper the NPG chain on the wire-wrap side of the backplane. So it very likely that your NPG chain is OK. In fact my understanding is that the 11/34 programmers console wouldn't work if it cannot acquire the bus. It uses NPR/NPG to modify memory.

    * I would use PDP11GUI and run a few CPU tests and memory tests to verify that the CPU is working OK. You can download absolute binary files (binary paper tapes) directly into memory and run them from address 200.

    * I actually had a case where the where the interrupt circuitry on a M7856 was broken and had to be fixed to it could be a source of a problem too.
    The 11/34 should clear PSW after power startup or Control - INIT from the programmers console. FYI - the 11/34 has both the addressable PSW and the MTPS/MFPS instructions.

    I suggested the test of the LTC because it uses a different interrupt line (BR6) than serial communication (BR4). These are located on different columns of a standard Unibus. If neither is working and if you use a different DL11-W, then that points to a common problem. The most likely candidate for the fault would then be the CPU.

    You can also try to use a unused (bogus) CSR address. That should Bus Trap to Vector 4 to quickly test that function.

    Jerry

  6. #6
    Join Date
    Aug 2010
    Location
    Silicon Valley USA
    Posts
    775
    Blog Entries
    4

    Default

    XXDP should be able to be loaded, booted, and run without using interrupts at all. So the issue that you can't do that should be #1 on the list right now. Chasing interrupt logic that may not be working is a bit of a red herring at this point.

    I would suspect more of a bus and/or memory issue. As suggested I would try and get PDP11GUI going and use it to download simple memory tests to validate memory, first.

    Once memory works reliably boot XXDP and run the simple 11/34 CPU diagnostics, and then follow with the traps test to validate/test the interrupt logic.

    Just my 2c.
    Don

    PS if you need any boot proms for your M9312 I can provide DD (TU58) as well as my ZZ (embedded simple diagnostic/memory tests) or any other required boot PROMs.
    I bought a boatload of blank 256x4 compatible boot prom devices a long time ago and have the required device programmer. $5 each plus shipping.
    Last edited by AK6DN; June 12th, 2019 at 12:14 PM.

  7. #7

    Default

    Quote Originally Posted by wa2flq View Post
    Enable the LTC using just the Console DL11-W board.

    Use address 177546 instead of 176500 and vector 100 instead of 300. Enable the RTC switches.

    That should tell you if the basic interrupt hardware on BR6 is working. It should halt immediately.
    This is an excellent suggestion, and the results confirmed that I was not seeing an interrupt. However, I checked the PSR and it was set to priority 7; prepending the program with 000230 to set the processor priority to 0 solved that problem, and the line interrupt triggered immediately.

    I have been having trouble triggering the serial interrupt, however. I think the problem is in the code I'm writing, though, at this point. I've tried to get a little more creative to get more output out of each run, and I think I'm making errors assembling in my head. I need to hook up some way to load programs over the console (perhaps PDP11GUI, although I don't have Windows; I'll have to see if I can get it working in WINE) to write my tests more effectively and efficiently.

    I have seen what I believe is a bus trap, and I have definitely seen a line clock interrupt after setting the processor priority to zero. I have verified that the PC and PSW are pushed down onto the stack when this occurs.

    I saw in a later comment that you suggested that the PSR should be cleared on init; is it possible that it is being set by the 9312 console PROM, or does this likely indicate an error that I need to locate?

    I have some more replies to other messages, but let me inline those before I get lost.

  8. #8

    Default

    Quote Originally Posted by MattisLind View Post
    * As far as I know XXDP doesn't use interrupts.
    You and Don have both mentioned this; this means that my XXDP boot problem is elsewhere, and I am inclined to agree with you and Don that I need to set the interrupt problems aside and look at the bus. I cannot find any bus problems in regular operation of the console or the serial console emulator, so I need to run more substantial programs and tests at this point. I had fallen down the interrupt rathole just because I wasn't sure what else the problem might be!

    * It is very common to jumper the NPG chain on the wire-wrap side of the backplane. So it very likely that your NPG chain is OK. In fact my understanding is that the 11/34 programmers console wouldn't work if it cannot acquire the bus. It uses NPR/NPG to modify memory.
    This is not my understanding, although I also don't think this is related to the problem. I need to clarify some things on my own part if this is true. A few points:

    • The KY11-LB manual says nothing whatsoever about the NPG line, or modifying the backplane to remove the NPG jumper if present. I would expect it to mention this under INSTALLATION. All it says is to put the M7859 "in any SPC slot".
    • I know that my NPG line is broken in slots 7 and 8, because I've rung it out. I assume that these contained drive controllers (or perhaps one or more of the data collection modules that I received with the unit) in its previous life. The backplane jumpers are intact for slots 1-6 and 9.
    • I have only ONE grant continuity card that bridges the NPG pin; my other grant continuity cards are the small cards that fit only into slot D.
    • I tried moving the M7859 to slot 7, with the NPG/grant continuity C&D card in slot 8. This made no difference in any behavior that I can find.


    * I would use PDP11GUI and run a few CPU tests and memory tests to verify that the CPU is working OK. You can download absolute binary files (binary paper tapes) directly into memory and run them from address 200.

    * I actually had a case where the where the interrupt circuitry on a M7856 was broken and had to be fixed to it could be a source of a problem too.
    This has occurred to me. I need to see if the machine will boot at all with the M7859 removed. Unfortunately I have three BA11-Ks with programmer's consoles, and (at least that I have identified so far) only one M7859, so this is a bridge I will have to cross sooner or later! I strongly suspect there was more than one M7959 with these machines at one time, but only one made it into my hands. The fourth BA11-K has a KY11-LA operator's console on it, where I don't think this will be an issue.

  9. #9
    Join Date
    Nov 2014
    Location
    Chicagoland
    Posts
    219

    Default

    Quote Originally Posted by elb;

    ….

    [CODE
    1000 / 012700
    1002 / 176500
    1004 / 012760
    1006 / 000100
    1010 / 000000
    1012 / 000777[/CODE]

    Note: In addition to placing 0 in the vector and status word for any interrupt you are testing, place a 0 starting at address 0.


    That will insure the machine will halt when the interrupt under test is serviced.

  10. #10
    Join Date
    Aug 2010
    Location
    Silicon Valley USA
    Posts
    775
    Blog Entries
    4

    Default

    Your code:
    Code:
    1000 / 012700
    1002 / 176500
    1004 / 012760
    1006 / 000100
    1010 / 000000
    1012 / 000777
    which translates to:

    MOV #176500,R0
    MOV #100,0(R0)
    BR .


    which points R0 at your second DL11-W control registers, sets the interrupt enable in the receive register, and then branches self.

    So, where has the stack pointer been setup? Not legal to have an interrupt without a valid stack pointer.

    If it does interrupt, it will pull the new PC/PS from locations 300/302. Does 300 have a valid PC in it?
    If the loaded PS from 302 does not set the IPL in the PS to an appropriate level, you may allow another interrupt to occur inadvertently.

    So just that little code sequence is not enough info to predict the behavior of the system.

    Don

    PS: Here's the full sequence I just pulled from Diane's page, with the stuff highlighted in red that needs to be setup beforehand:

    Code:
    Same way it's easy to check for correct interrupt vector. On the '11, toggle in a short program:
    
    1000 / 012700         <--- r0 = receiver csr
    1002 / 176500
    1004 / 012760         <--- set in rec. csr "interrupt enable"
    1006 / 000100
    1010 / 000000
    1012 / 000777         <--- endless loop
    
    Of course, as was in a preceding chapter, some housekeeping is necessary here, too:
    
    276 / 000000
    300 / 000276
    302 / 000000
    304 / 000302
    
    R6 / 000700
    
    
    Last edited by AK6DN; June 12th, 2019 at 04:20 PM.

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
  •