qbone not writing to memory

[taylor]

hey all! having a slightly odd issue with my new qbone; KDJ11-BF CPU and an H9278-A backplane. i've crafted the following command file to boot my 11M+ image:

# wooyoo 11m+
d                       # device test menu
sd dl11
p p ttyS2
en dl11                 # enable serial console
pwr
.wait 3000              # wait for PDP-11 to reset
m i
m ll du.lst
en uda                  # enable UDA50 controller

# mount RSX in MSCP drive #0
en uda0                 # enable drive #0
sd uda0                 # select
p type RD54
p image wooyoo.dsk  # mount image
p useimagesize  1

.print Disk drive now on track after 5 secs
.wait   5000            # wait until drive spins up

p                       # show all params

.print MSCP drives ready.
.print UDA50 boot loader installed.
.print Start 10000 to boot from drive 0, 10010 for drive 1, ...
.print Reload with "m ll"

from what i can tell this should be working, however the "m i" and "m ll" commands hang. strangely enough this is happening both when using qbone's emulated memory, and when using real physical memory. when the script reaches the "m i" command i have to manually tap the CPU reset button to get it to progress to "m ll", where it hangs here until i ^C:

Loaded MACRO-11 listing from file "du.lst" into memory: 69 words from 000000 to 010200.
  No entry address at "start" label is 17777777777.

the CPU detects both the emulated and physical memory and is able to successfully test both. a little more about my setup, just in case:

slot 1: PMI memory
slot 2: KDJ11-BF
slot 3: GRANT continuity
slot 4: qbone

appreciate your help!

[Joerg Hoppe]

Hi,

error on "m i" mean usual: QBone can not perform DMA to CPU.

Seems you have  11/73.
Your module locations look wrong to me:

slot 1: PMI memory
slot 2: KDJ11-BF
slot 3: GRANT continuity
slot 4: qbone

The CPU should be in slot 1,  as of

bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks\EB-24944-18_Micro_PDP-11_Handbook_1983-84.pdf

page 24.

Or do you have different docs?

Joerg

--
You received this message because you are subscribed to the Google Groups "UniBone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unibone+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/26228185-3751-4725-b9b6-7a73dfc260d6n%40googlegroups.com.

[taylor]

this is an 11/83, sorry for not being more specific. my understanding is that PMI memory should be installed before the CPU, and non-PMI memory after. page 2-8 here: http://www.bitsavers.org/pdf/dec/pdp11/microPDP11/EK-MIC11-TM-002_MicroPDP11_Systems_Technical_Manual_Sep85.pdf

"Always install the KDJll-BF CPU in slot 2 or 3 of a BA23 enclosure backplane.
The MSVll-JD or MSVll-JE memory module(s) MUST be installed immediately
in front (lower slot number) of the CPU. There can be no open slot between the
CPU and memory, nor can there be an open slot preceding the memory module."

to clarify a little more, in slot 3 i have GRANT continuity on a/b, but not c/d. i've been talking on and off with mark matlock and he suggested to try nixing the du.lst and booting from the MSCP device directly as my CPU has boot ROM support for MSCP disks, but this is still not ideal- i haven't been able to get my system to boot yet by using "pwr" in between attempts at booting DU0, but i'm still trying as he said it may take some time. the system either hangs on "trying DU0" or gives a controller error, but as i already mentioned mark said it may take a while, so i need to keep trying at it.

[ma...@matlockfamily.com]

Joerg,

   As Taylor said I'm giving him some advice based on my use of QBone in an 11/83. One quirk I've experienced with it is that getting the QBone's MSCP

controller to be recognized by the KDJ11-BF CPU boot code for MSCP DU0 is tricky. I have to reboot multiple times, most of which say "controller failure"

but as I execute either pwr commands to the QBone or hit the boot button multiple times eventually I get past the "Trying DU" message to "Starting DU0"

and everything comes up fine. If I have to reboot again it works fine reproducibility until I power off the system. Then I have to go through the retries.

I usually stop the 1 2 3 4 5 6 7 8 9   with a ^C and then tell it to boot. Taylor's system makes it all the way through the boot up CPU and memory tests fine as

does mine. I normally do not use your du.lst to boot as it didn't seem to work on the 11/83. I started reading du.lst and one thing that struck me was what state are

the memory mapping APRs? If APR7 is not pointing to the I/O page du.lst might be pointing at some other part of memory.

   Perhaps hitting the ^C at some part of the memory test leaves the APR7 pointed at the I/O page (to output a character on the console DL11 port?)

and that is what is causing this behavior. I'd really like to see what the KDJ11-BF boot code is doing because I don't remember seeing these problems

on a 11/73.

Best,

Mark

[taylor]

i'm getting a little more clarity on my issue, i think. just to satisfy my curiosity i decided to try booting the XXDP RL02 images, but these don't seem to want to boot either. i don't get a controller error here, just a hang. one thing worth noting is that with both the RL02 and MSCP images, my CPU can see the devices, but they are unintialized:

I/O page Map
Starting   Ending
Address    address

17765000 - 17765776     CPU ROM or EEPROM
17772100                Memory CSR
17772200 - 17772276     Supervisor I and D PDR/PAR's
17772300 - 17772376     Kernel I and D PDR/PAR's
17772516                MMR3
17773000 - 17773776     CPU ROM
17774400 - 17774410     <- RL device should be here
17777520 - 17777524     BCSR, PCR, BCR/BDR
17777546                Clock CSR
17777560 - 17777566     Console SLU
17777572 - 17777576     MMR0,1,2
17777600 - 17777676     User I and D PDR/PAR's
17777744 - 17777752     MSER, CCR, MREG, Hit/Miss
17777766                CPU Error
17777772                PIRQ
17777776                PSW

I/O page Map
Starting   Ending
Address    address

17765000 - 17765776     CPU ROM or EEPROM
17772100                Memory CSR
17772150 - 17772152     <- MSCP device should be here
17772200 - 17772276     Supervisor I and D PDR/PAR's
17772300 - 17772376     Kernel I and D PDR/PAR's
17772516                MMR3
17773000 - 17773776     CPU ROM
17777520 - 17777524     BCSR, PCR, BCR/BDR
17777546                Clock CSR
17777560 - 17777566     Console SLU
17777572 - 17777576     MMR0,1,2
17777600 - 17777676     User I and D PDR/PAR's
17777744 - 17777752     MSER, CCR, MREG, Hit/Miss
17777766                CPU Error
17777772                PIRQ
17777776                PSW

i'm wondering if this is a DMA issue like you had mentioned, joerg? the CPU seems to behave fine, but without a booting OS i can't say that with a whole ton of certainty.

[Joerg Hoppe]

Hi,

one more observation: you enabled QBone serial port emulation, but the M8190 already has a console onboard.

sd dl11

p p ttyS2
en dl11                 # enable serial console

Or is your CPU UART disabled?

For the "M i" problems:

- first suspect is always a broken NPG chain between CPU and QBone, so DMA is no working
I'd assume you can't do an "examine" from QBone either:
try "e 0".

- I think the G9047 is sitting at the correct position for your slot usage.
However the card/backplane contacts may be bad (more often than you would think), try jiggle your cards.

- can you sent a picture of your QBone's jumper settings?

Joerg

[taylor]

yep, the serial console bit was used while i was testing with a CPU without an onboard console, so it's just kinda there. i tried an "e 0" after reseating the cards and still got nothing, unfortunately- they're as far in and as straight on as i can get them. jumpers below:

[taylor]

sorry to double post but i swapped GRANT cards as well- unless i got 5 duds, it looks like something else is going on.

[Joerg Hoppe]

Am 27.03.2022 um 17:43 schrieb taylor:

yep, the serial console bit was used while i was testing with a CPU without an onboard console, so it's just kinda there. i tried an "e 0" after reseating the cards and still got nothing, unfortunately- they're as far in and as straight on as i can get them. jumpers below:

Please remove the two black jumpers below the 4 red ones. They're shortcutting the GRANT lines, only use case so far is board selftest.

Joerg

To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/f23e6af3-7cba-4f5f-9472-eca7f873aaa3n%40googlegroups.com.

[taylor]

aha, thank you for clarifying! removed those jumpers and i'm testing now, will report back if i have any success.

[taylor]

still the same issues after removing those jumpers, unfortunately- "m i" and "e 0" still hang, and nothing will boot.

[Joerg Hoppe]

Hum.

I'm currently out of ideas.

Do you have opportunity to exchange components with a working system?

Joerg

To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/31f5e731-4f33-4b2d-8829-3d23ab9b8d19n%40googlegroups.com.

[taylor]

i have a KDJ11-A and a couple non-working memory cards, but that's about it at the moment. i threw the spare CPU in there, and i'm still seeing the same behavior. could it be an issue with the backplane?

[taylor]

something else worth noting- when i go to start up a qbone script, it complains about the following:

"NO QBUS memory installed ... device test limited!"

as i mentioned before, the CPU can see and test both real and emulated memory just fine, so it looks like the qbone for whatever reason can't detect it.

[taylor]

one more thing i forgot to include: i can successfully examine memory addresses via the ODT and get results, but attempting to do the same from the qbone results in a long (~1hr) hang followed by an incorrect result and "bus timeout on 00000000"

[amp...@gmail.com]

On VCFed you said this is how you set it up:

 

BA23 chassis, H9278-A backplane
1 - QED1 PMI memory
2 - KDJ-11BF
3A/B - GRANT continuity
4 - Qbone
5 - DLV11-J (for testing with an 11-A)

 

If I’ve been following things right, you’re actually seeing a problem with the QBone not being able to see the memory.

 

And you seem to not be able to get from the QBone to PMI memory on the other side of the QBUS from the KDJ11-BF (11/83 CPU card).

 

Should that even be expected to work?  Isn’t the 11/83 CPU card using all four connectors (QQ/CD) to talk to the PMI memory?  And the QBone is plugged into non-PMI QQ/QQ connectors, which is where it should be.  And the QBone wouldn’t know how to talk to PMI memory that needs the CD connectors in the front QQ/CD part of the QBUS.

 

In case you’re thinking of trying it, I am very sure you should never plug a QBone into the QQ/CD section  of a QBUS backplane.  A QBone definitely wants to be plugged in to QQ/QQ sockets.

 

I’ve not yet plugged my bits and pieces for an 11/83 (KDJ11-BF) w/ two 2MB KDJ11-BE memory cards into a BA23 chassis.  But my reading is telling me that

 

1 QQ/CD PMI memory card

2 QQ/CD grant card

3 QQ/CD KDJ-11B CPU card

 

Is going to use do PMI memory transfers between the CPU and memory using the extra not-regular-QBUS lines on the CD pairs of connectors.

 

My reading also made me think it’s best to put the PMI memory card(s) right before the CPU card.  I don’t know if that grant card in the QQ part of the QQ/CD row number 2 is sufficient to get the PMI signals on the CD connectors to make their way from slot 3 to slot 2.  I AM SURE that you wouldn’t ever want to put a grant card in the CD part of any QQ/CD slots, but nothing you’ve written makes me think you did that.  I would think that this is how you’d want things set up to use PMI memory with only one PMI memory card:

 

1 QQ/CD PMI memory card

2 QQ/CD KDJ-11B CPU card

3 QQ/CD grant card (grant card in QQ part of row, not in CD part of row)

 

I also understand that some memory cards such as KDJ-11BE can work as either a PMI memory card when installed as above, or work as slower QBUS memory when installed like this:

 

1 QQ/CD KDJ-11B CPU card

2 QQ/CD PMI memory card

3 QQ/CD grant card

 

But I don’t know if your QED1 memory card is able to do plain QBUS memory transfers or if it can only work as a PMI memory card.  If your Clearpoint QED1 card can work as QBUS memory, setting it up that way might allow a QBONE in a QQ/QQ row (I _THINK_ row 4 and up for your backplane) to talk your QED1 as regular QBUS memory over just a QQ pair of QBUS connectors.

 

I really hope I’m not adding confusion.  And again, everything I added above is just from reading and not taking, not from real world experience.

 

-- Ron Pool

 

 

On Sunday, March 27, 2022 at 2:17:07 AM UTC-4 ioerg...@gmail.com wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/7e90fbef-51ce-4361-bf9c-fd29dcfd4062n%40googlegroups.com.

[amp...@gmail.com]

I probably should have show more rows in my example H9278-A backplane layouts.  I think you know rows 1-3 are QQ/CD and 4-8 are QQ/QQ, but for those who don’t know and come across this in a search:

 

1 QQ/CD

2 QQ/CD

3 QQ/CD

4 QQ/QQ

5 QQ/QQ

6 QQ/QQ

7 QQ/QQ

8 QQ/QQ

 

Only:

1) quad-wide PMI cards should be plugged into all four sockets of rows 1 to 3, or

2) double-wide QBUS cards can be plugged into the QQ pair of connectors in rows 1 to 3.

 

If any of rows 2-3 are empty, you need a grant card in the QQ pair of sockets in that/those row(s), and then nothing in the CD pair of sockets in that row.

 

Plugging anything that isn’t PMI into the CD connectors of rows 1-3 is likely to do electronic damage to something.

 

Plugging PMI cards into (non-PMI) rows 4-8 won’t work and is likely to do electronic damage to something.

[taylor]

i don't know that the backplane configuration is at fault here- like i said i've been working with mark who owns a similarly configured 11/83, and that seems to be working. i had a call with him earlier today and ran through the configuration, and according to him it is valid. i'm also a little confused (and concerned), as qbone documentation states that it can be used in slots 1-3 on an H9278 as long as the CD GRANT jumpers are open. if that's not the case then i might be in a bad place, as i tried running it in slot 3 directly beneath the CPU during my testing... :/

[amp...@gmail.com]

> i don't know that the backplane configuration is at fault here- like i said i've been working with mark who owns a similarly configured 11/83, and that seems to be working. i had a call with him earlier today and ran through the configuration, and according to him it is valid. i'm also a little confused (and concerned), as qbone documentation states that it can be used in slots 1-3 on an H9278 as long as the CD GRANT jumpers are open. if that's not the case then i might be in a bad place, as i tried running it in slot 3 directly beneath the CPU during my testing... :/

Like I said, what I know is only based on reading, not real experience. Mark Matlock has actually used this stuff and knows what he is doing.

I think you're right that quad boards can be designed to go into QQ/CD rows. And I think you're right about the QBone without those jumpers being installed is OK.

What I was really trying to point out is that PMI memory installed in front of a CPU can probably only talk to the CPU via PMI (not QBUS). And that a QBone installed after a CPU can probably not talk to PMI memory that is in front of the CPU.

Since my last message I've been trying to find info on Clearpoint QED-1 cards. So far what I've gathered is that they can be used as PMI (with jumpers installed at the pins adjacent to the CD connectors) when installed in a QQ/CD row that is before a PMI CPU's QQ/CD row. And can also be used as non-PMI memory if placed after the CPU. And that if placed in a QQ/QQ row the jumpers by the QED-1's CD connectors should be removed.

I'm sure Mark or Joerg will speak up onn whether or not I'm not completely wrong about the QBone not being able to talk to PMI memory cards (unless they're configured to use plain-old QBUS, not PMI memory transfers).

-- Ron Pool

[Joerg Hoppe]

Hi,

one more topic popped up this night:
- Is the RUN/HALT switch on the panel in the RUN position?

- For backplane tests:
You can test individual QBUS signals in the  "bs" menu.
To verify the DMA  protocol between QBone and CPU:
- verify DMR, DMGI and SACK are inactive
- set DMR (request DMA from CPU)
- check DMGI, must be active. (CPU should acknowledge DMA)
- set SACK  (take QBUS)
- verify: DMGI inactive now (CPU released the DMA ack)
- set SACK inactive (release QBUS, back to idle config)

Warning: I give this sequence from memory, not yet verified.

Joerg

[taylor]

it is set to RUN. tried the "bs" menu, after setting DMR=1, DMGI still shows 0. paused here since it seems like i shouldn't proceed.

[taylor]

something else- when showing all values from "bs", EVNT was only set to 1 once out of five or so times. related, maybe?

[Joerg Hoppe]

taylor,

it is set to RUN. tried the "bs" menu, after setting DMR=1, DMGI still shows 0. paused here since it seems like i shouldn't proceed.

I verified the manual DMA sequence on my 11/73-like system.

See input and output of the "BS" menu below

"bs"
"r"     clear all output
"a" =>  DMR = 0, DMGI= 0, SACK= 0
"7 1"    set DMR
"a"  =>  DMR = 1, DMGI= 1, SACK= 0
"10 1"     set SACK
"a"  => DMR = 1, DMGI= 0, SACK= 1
ODT console not responsive now as CPU lost QBUS access
"7 0"    clear DMR
"a" => DMR = 0, DMGI= 0, SACK= 1
"10 0"    clear SACK
CPU has QBUS access again, ODT responsive again
"a" =>  DMR = 0, DMGI= 0, SACK= 0

So if your DMGI stays 0 after setting DMR=1 your DMA GRANT chain seems to be broken.

Time for a multimeter check:
The DMGO pin of KDJ11-B *MUST* be connected to the DMGI pin of QBone, through the backplane and over the G9047.

Joerg

[taylor]

i'll have to order some qbus extenders then, i'll follow up once i have those and have had a chance to test. thanks again for all your help, everyone!

[taylor]

this was user error... :) mark helpfully pointed out that i forgot to close the grant lines on the cards themselves, and now i'm able to boot xxdp. slightly embarrassing but i'm happier to have the machine booting.

[Joerg Hoppe]

Hi taylor,

this was user error... :) mark helpfully pointed out that i forgot to close the grant lines on the cards themselves, and now i'm able to boot xxdp. slightly embarrassing but i'm happier to have the machine booting.

Congrats!

On which cards you had open jumpers ... don't see them on KDJ11-B M8190?

By the way, my "manual DMA sequence" may not work on KDJ11-B ... according to docs the CPU removes DMGO 10µs after DMR when no SACK is coming:
"No SACK Timeouts". So you can see DMGI only shortly with a scope, not with a multimeter.

Joerg

On Tuesday, March 29, 2022 at 10:56:33 AM UTC-4 taylor wrote:

i'll have to order some qbus extenders then, i'll follow up once i have those and have had a chance to test. thanks again for all your help, everyone!

On Tuesday, March 29, 2022 at 2:50:50 AM UTC-4 ioerg...@gmail.com wrote:

taylor,

it is set to RUN. tried the "bs" menu, after setting DMR=1, DMGI still shows 0. paused here since it seems like i shouldn't proceed.

I verified the manual DMA sequence on my 11/73-like system.

See input and output of the "BS" menu below

"bs"
"r"     clear all output
"a" =>  DMR = 0, DMGI= 0, SACK= 0
"7 1"    set DMR
"a"  =>  DMR = 1, DMGI= 1, SACK= 0
"10 1"     set SACK
"a"  => DMR = 1, DMGI= 0, SACK= 1
ODT console not responsive now as CPU lost QBUS access
"7 0"    clear DMR
"a" => DMR = 0, DMGI= 0, SACK= 1
"10 0"    clear SACK
CPU has QBUS access again, ODT responsive again
"a" =>  DMR = 0, DMGI= 0, SACK= 0

So if your DMGI stays 0 after setting DMR=1 your DMA GRANT chain seems to be broken.

Time for a multimeter check:
The DMGO pin of KDJ11-B *MUST* be connected to the DMGI pin of QBone, through the backplane and over the G9047.

Joerg

--

You received this message because you are subscribed to the Google Groups "UniBone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unibone+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/d0df86c5-d1cd-4e26-b617-ae56867d90e3n%40googlegroups.com.

[taylor]

i had wrongfully assumed that the G9047 GRANT cards would function in a similar plug-n-play manner to the DEC cards, so i didn't close the grant lines before installing them- lesson learned! :D