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

Thread: DEC PDP1123 Boot failure Rt11SJ-V5.03

  1. #1
    Join Date
    Apr 2014
    Location
    Dordrecht , Netherlands
    Posts
    118

    Default DEC PDP1123 Boot failure Rt11SJ-V5.03

    I have my PDP1123 up and running again.
    On the M8047 the console port was/Is defective (Think a serial buffer IC 9036/9037) It does not receive keyboard strokes from the Vt420 terminal.
    So put a G304 (4x Serial card) and strapped Ch3 for console, TOP working again.
    GTSC 304 quad serial Qbus Interface-DLV11J-Style

    Also put the M8059-KF MSV11-LK MEM 128K And strapped it after adress 200000 of the of Both the M8047's (2x 16k).
    With XXDP V2.5 i now see 124kW instead of 32kW.

    Also there is the M7555 (RQDX3) and M9058 breakout card with a home made switch board and 2x ST225 Harddrives.
    The drives 1 loaded with RT11SJ V4.00 and 1 drive loaded with RT11SJ V5.03.

    Problem: System often does not boot the RT11SJ V5.03.
    Not from TU58-Emulation, Not from RX02 Flopdrive not from the Harddrive.

    Sometimes it does boots the V5.03 from all the devices with no problems to run other programs.

    RT11SJ V4.00 is not a problem to boot every time from all the devices.

    The code I get is when trying to boot V5.03:
    @005200
    @


    Someone knows that code and where to look for?

    The total setup, pc case at the left contains the 2x ST225 and M9058 , at the right a PC with TU58 emulation.
    20190508_014649-Compleet2.jpg

    Boot from RX02 with a RT11SJ V5.03 boot, fail code 005200
    20190519_PDP1123-Bootfail_V503.jpg

    M8186, M8047
    M7555, M8047
    G304 , M8029
    ........, M8059
    Note: extra wires are to boot from RX02 or TU58 Bootstrap, with a select switch at the back I made.
    20190510_211128-PDP1123-Compleet-Kaarten.jpg
    Last edited by MauriceH; May 19th, 2019 at 02:08 AM.

  2. #2
    Join Date
    Nov 2014
    Location
    Chicagoland
    Posts
    204

    Default

    Quote Originally Posted by MauriceH View Post
    I have my PDP1123 up and running again.
    On the M8047 the console port was/Is defective (Think a serial buffer IC 9036/9037) It does not receive keyboard strokes from the Vt420 terminal.
    So put a G304 (4x Serial card) and strapped Ch3 for console, TOP working again.
    GTSC 304 quad serial Qbus Interface-DLV11J-Style

    Also put the M8059-KF MSV11-LK MEM 128K And strapped it after adress 200000 of the of Both the M8047's (2x 16k).
    With XXDP V2.5 i now see 124kW instead of 32kW.

    Also there is the M7555 (RQDX3) and M9058 breakout card with a home made switch board and 2x ST225 Harddrives.
    The drives 1 loaded with RT11SJ V4.00 and 1 drive loaded with RT11SJ V5.03.

    Problem: System often does not boot the RT11SJ V5.03.
    Not from TU58-Emulation, Not from RX02 Flopdrive not from the Harddrive.

    Sometimes it does boots the V5.03 from all the devices with no problems to run other programs.

    RT11SJ V4.00 is not a problem to boot every time from all the devices.

    The code I get is when trying to boot V5.03:
    @005200
    @
    This is not a code, but the PC address when the processor halted - in octal. Its low in the 28KW range that RT11SJ would use. Its a bit hard to debug from this information, so I will suggest you try a few other things to try. Since V4.00 works fine we can assume your hardware working sufficiently for a single job monitor. I'm also assuming that if you do a directory of the disk where V5.03 is stored (DY1:) the files list normally. Keep in mind however that disk drives from that era do tend to develop problems over time.

    The command BOOT DY1: tries to picks the secondary bootstrap from blocks 2,3,4 and 5 of the device where the volume information is stored. Try instead BOOT DY1:RT11SJ. This will pick up that bootstrap from the file DY.SYS instead. If that works, the wrong bootstrap is stored on the disk and that can be easily fixed.
    If booting from TU58, use DDn (were n is a device number 0 or 1) instead of DY1: in the above.

    If this doesn't work, then the next step is to check the DY.SYS and RT11SJ.SYS files against known good copies.


    Jerry

  3. #3
    Join Date
    Apr 2014
    Location
    Dordrecht , Netherlands
    Posts
    118

    Default

    Jerry.
    Thanks for the reply,
    I'll go check with the option BOOT DY1:RT11SJ

    Before (some years ago) I had no problem booting V5.03 from Tape TU58 emu and back then made several boot tapes.
    Now I finaly have both the MFM ST225 up and running and copied the org Rt53.DSK (10mB) through TU58-emu to1 drive.(other is a V4.00 boot)
    Even so I made a RX02 boot flop RT11 v5.03.
    Doen't matter drive DY0 or DY1 both drive boots the V4.00 disk.

    Sometimes I can even 4-5 times Boot v5.03 from all devices, than suddently from not even 1 device.
    The V4.00 from all devices with no exeption boots.

    Today I got working a RX33 drive (a TEAC FD-55GFR -193 U) with the RQDX3 card.
    Made also a Rt11-V5.03 flop on a DOS PC from a complete other Boot.dsk file I used a few years back and
    that boots also some times even so as the other devices.

    Also XXDP V2.5 on the TU58 emu boots in XM-Monitor with the 124kW with no problems.

    I'll check your options,
    RED: Could be a Memory failure again...
    I already had to replace a 4116 back in 2009 on the M8047 due to a bad IC.
    I'll go check the memory again.

    Maurice

  4. #4
    Join Date
    Apr 2014
    Location
    Dordrecht , Netherlands
    Posts
    118

    Default

    The option "BOOT DU0:RT11SJ" did not solve the problem.

    Pulled out the M8059-KF MSV11-LK MEM 128K card,
    and:

    RT-11SJ V5.03 now boots every time from all devices ( MFM Harddrive, RX02 disk or TU58-emu)

    So there is some problem with the extra M8059.
    Maybe the location or still some wrong strapping on that card.

    Typical the Boot XXDP v2.5 recognise the extra Mem till 124kW.

    I'll go look in to that, or try relocating the card in the backplane.

    Or I go find in XXDP a MEM test routine for this card.
    Could that be VMJAB0 ? for this card?

  5. #5
    Join Date
    Aug 2010
    Location
    Silicon Valley USA
    Posts
    758
    Blog Entries
    4

    Default

    Quote Originally Posted by MauriceH View Post
    The option "BOOT DU0:RT11SJ" did not solve the problem.

    Pulled out the M8059-KF MSV11-LK MEM 128K card,
    and:

    RT-11SJ V5.03 now boots every time from all devices ( MFM Harddrive, RX02 disk or TU58-emu)

    So there is some problem with the extra M8059.
    Maybe the location or still some wrong strapping on that card.

    Typical the Boot XXDP v2.5 recognise the extra Mem till 124kW.

    I'll go look in to that, or try relocating the card in the backplane.

    Or I go find in XXDP a MEM test routine for this card.
    Could that be VMJAB0 ? for this card?
    TU58 diagnostic XXDPv25 bootable images are here: https://www.ak6dn.com/PDP-11/TU58/
    But you probably already know that...

    I have a TU58 image with some 11/23 memory tests on it. Use image 1123_1.DSK and run VMJAB0

    And/or you could try my home grown memory test.
    Boot from 11XX_9.DSK and run the MEMX program. It will test all memory w/ECC & cache off and uses relocation.
    The program listing is here: https://www.ak6dn.com/PDP-11/DIAGNOSTICS/memx.lst
    It uses the 'extended march c-' testing algorithm.
    I use it on my 256K 11/34 and 4M 11/44 routinely.

    Here is what a console log looks like:

    Code:
    Memory Exerciser v1.32
    
    Detected memory size is 3840KB (17000000)
    
    Memory Control registers:  <none>
    
    Test1: constant data patterns
    Test1a: data pattern 000000 (0000000000000000)
    Test1b: data pattern 177777 (1111111111111111)
    Test1c: data pattern 000377 (0000000011111111)
    Test1d: data pattern 177400 (1111111100000000)
    Test1e: data pattern 007417 (0000111100001111)
    Test1f: data pattern 170360 (1111000011110000)
    Test1g: data pattern 031463 (0011001100110011)
    Test1h: data pattern 146314 (1100110011001100)
    Test1i: data pattern 052525 (0101010101010101)
    Test1j: data pattern 125252 (1010101010101010)
    
    Test2: unique physical block select
    
    Test3: unique physical block address
    
    Test4: extended march c- data test
    Test4a: u(w0) - address ascending; write zero
    Test4b: u(r0,w1,r1) - address ascending; read zero, write one, read one
    Test4c: u(r1,w0) - address ascending; read one, write zero
    Test4d: d(r0,w1) - address descending; read zero, write one
    Test4e: d(r1,w0) - address descending; read one, write zero
    Test4f: d(r0) - address descending; read zero
    
    End pass 1. errors 0.
    
    Program relocated to 100000(8) - 177777(8) physical
    
    Test1: constant data patterns
    Test1a: data pattern 000000 (0000000000000000)
    Test1b: data pattern 177777 (1111111111111111)
    Test1c: data pattern 000377 (0000000011111111)
    Test1d: data pattern 177400 (1111111100000000)
    Test1e: data pattern 007417 (0000111100001111)
    Test1f: data pattern 170360 (1111000011110000)
    Test1g: data pattern 031463 (0011001100110011)
    Test1h: data pattern 146314 (1100110011001100)
    Test1i: data pattern 052525 (0101010101010101)
    Test1j: data pattern 125252 (1010101010101010)
    
    Test2: unique physical block select
    
    Test3: unique physical block address
    
    Test4: extended march c- data test
    Test4a: u(w0) - address ascending; write zero
    Test4b: u(r0,w1,r1) - address ascending; read zero, write one, read one
    Test4c: u(r1,w0) - address ascending; read one, write zero
    Test4d: d(r0,w1) - address descending; read zero, write one
    Test4e: d(r1,w0) - address descending; read one, write zero
    Test4f: d(r0) - address descending; read zero
    
    End pass 2. errors 0.
    
    Program relocated to 0(8) - 77777(8) physical
    Don
    Last edited by AK6DN; May 21st, 2019 at 07:16 PM.

  6. #6
    Join Date
    Nov 2014
    Location
    Chicagoland
    Posts
    204

    Default

    Quote Originally Posted by MauriceH View Post

    ...Also put the M8059-KF MSV11-LK MEM 128K And strapped it after address 200000 of the of Both the M8047's (2x 16k).
    The M0847 (MXV11-A) being a multifunction card provides including memory, 2 x serial ports, crystal clock and rom devices. Make sure you don't have two (or more) devices responding to the same address. Only 1 clock is allowed..

    Is your 11/23 18bit or 22bit capable? If the former, then you are limited to 124KW addressable.

    Jerry

  7. #7
    Join Date
    Apr 2014
    Location
    Dordrecht , Netherlands
    Posts
    118

    Default

    The M8059 MSV11-L checking wraps.
    I have 2x M8047 (16k) makes it 32k Words total.
    1x M8047 has 16k-1 Bit RAM (16x 4116P)

    Adding the M8059 with full Memory installed should be 128k total.
    Document of the M8059 : M8059 from EK0LSIFS-SV-005_LSI-11_Systems_Service_Manual_Volume_3_Jan85.pdf PAGE 838.

    Starting address: PSA = MSA - FAR => MSA = 32k
    So first address starts in the range FAR = 000 - 124k (all jumpers P,N,M,L are OUT) (00000000 - --760000) (Page 843)

    The PSA = 32 k (00200000 (8 ) ) => Jumpers Y - to - U (GND) (page 844)

    CSR selection 18-Bit
    I Think It should be the first address 772100 (C,B,A All OUT)
    I Only have 1x MSV11-L card,

    As wired now:
    M8059-MSV11-l-JUMPERS2.jpg

  8. #8
    Join Date
    Apr 2014
    Location
    Dordrecht , Netherlands
    Posts
    118

    Default

    I can't remember that Switch setting SW= 00000000 NEW:
    Wrote down in the printout back in 2014 "00000200" don't recall why.

    I run the XXDP program VMJA0 with installed: and with that SW= 200.
    2x M8047 and M8059
    It boots in XM Monitor with 124k
    20190524_xxdp-124kW_start.jpg

    Result is an error
    20190524_124KW-Test_VMJAB0.jpg

    Then run your program MEMX
    It halted
    20190524_MEMX-Met 128k-Install.jpg

    As a check I run the MEMX again without the M8059 card.
    And now it keeps running without Errors and switches between the 2 cards.
    0 (8 ) - 77777 (8 ) and 100000 (8 ) - 177777 (8 )
    20190524_MEMX_2xM8047_001.jpg
    20190524_MEMX_2xM8047_002.jpg

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

    Default

    Quote Originally Posted by MauriceH View Post
    I can't remember that Switch setting SW= 00000000 NEW:
    Wrote down in the printout back in 2014 "00000200" don't recall why.

    I run the XXDP program VMJA0 with installed: and with that SW= 200.
    2x M8047 and M8059
    It boots in XM Monitor with 124k
    20190524_xxdp-124kW_start.jpg

    Result is an error
    20190524_124KW-Test_VMJAB0.jpg

    Then run your program MEMX
    It halted
    20190524_MEMX-Met 128k-Install.jpg

    As a check I run the MEMX again without the M8059 card.
    And now it keeps running without Errors and switches between the 2 cards.
    0 (8 ) - 77777 (8 ) and 100000 (8 ) - 177777 (8 )
    20190524_MEMX_2xM8047_001.jpg
    20190524_MEMX_2xM8047_002.jpg
    Getting clean results on 32KW of memory is great progress.

    I do see that MEMX program reports 292KB (146KW) before it halts which is >18bits, but that is size outside the combinations of memory boards you have (128KW, 144KW or 160KW). It is hard to use this information by itself.

    If your cpu is an KDF11-A Rev A, it only does 18 Bit addressing on the Qbus. Alternately the QBUS might only be wired for 18bit - see h
    ttp://web.frainresearch.org:8080/projects/pdp-11/dcf11.php and http://web.frainresearch.org:8080/pr...backplanes.php. This CPU board has all the registers for 22 bit addressing, but 4 bits worth of electrical connections might be missing. Test the 128KW board alone, even it means changing the configuration. I don't remember exactly what the behavior is when you have 128+32KW of memory (>18bits worth) when you can only address 18 bits. It might be that addresses wrap around on the larger board and you have two memory boards (trying) to put data on the bus at the same time. That also may explain the halts you are seeing.

    In 16 bit mode, XXDP and RT11 usually will only see 28KW of memory, as they both keep the 4KW IO page addressable. This is the default power on state. You don't get the top 4KW on 18bit and 22 bit systems in a similiar fashion. You can squeeze the IO page down to 2KW on the M8059 memory board if your controllers aren't mapped between in that space. I have run RT11SJ or FB in that configuration. I don't recall completely, but it may require a patch or tweek to enable 30K memory
    .

    Jerry

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

    Default

    Quote Originally Posted by MauriceH View Post
    I can't remember that Switch setting SW= 00000000 NEW:
    Wrote down in the printout back in 2014 "00000200" don't recall why.

    I run the XXDP program VMJA0 with installed: and with that SW= 200.
    2x M8047 and M8059
    It boots in XM Monitor with 124k
    20190524_xxdp-124kW_start.jpg

    Result is an error
    20190524_124KW-Test_VMJAB0.jpg

    Then run your program MEMX
    It halted
    20190524_MEMX-Met 128k-Install.jpg

    As a check I run the MEMX again without the M8059 card.
    And now it keeps running without Errors and switches between the 2 cards.
    0 (8 ) - 77777 (8 ) and 100000 (8 ) - 177777 (8 )
    20190524_MEMX_2xM8047_001.jpg
    20190524_MEMX_2xM8047_002.jpg
    XXDP will always report at most 124KW of memory at boot, even if there is a full 2MW present.

    MEMX reporting 292KB of mory is very strange ... over the 18b limit, much less than the 22b limit of 4088MB.

    With the M8059 card in both test programs return to ODT with a stop address of 000002. So this means each one was executing a HALT at location 000000. Many ways for this to happen, can be a double bus fault, or somehow PC got forced to zero by a bad memory read that returned zero for data when popping PC from stack, etc.

    The last run is the 'normal' MEMX behavior, it will run endlessly until stopped. The program fits in 32KB, so it will swap (and remap) the program between physical locations 0-077777 and 1000000-177777, always remapped to virtual 0-077777. This way it can test the full range of physical memory.

    In the last successful run of MEMX you don't show how much memory MEMX detected. It requires a minimum of 64KB to run up a max of 512KB(18b) or 4096KB(22b).

    As to the cause of the failure, I suspect that the address mapping of the M8059 board is setup such that either two boards have conflicting/overlapping addresses, or the mapping is setup with hole(s) in the address space where no card responds.

Tags for this Thread

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
  •