Vers. 2024-07 changes

[Timberwoof Lupindo]

hi! I completed assembling my new QBone. I took lots of notes and made a Heathkit-like set of instructions including some subtle things to watch out for. (The alternative is to read the QBone web page three or four times before beginning. Checklists are important.) 

I got through some of the the initial tests. The Beaglebone talks over ethernet and it mostly updated itself. There were errors in some updates, 404 errors at 202.61.233.51. 

I discovered badness in the connections: two of the LEDs are flaky, which means a lot of the connections are probably flaky. Everything beeped out okay, but I will try to fix up the header pin joints. I suspect I need a hotter soldering iron for this solder. 

My biggest concern right now is the jumpers. The online instructions say that some of them are only needed for debugging, but there's no guidance on which ones those are. I'm stuck at "set loopback jumpers onto the IAKI-IAKO and DMGI-DMGO lines (yellow in the image below)" . The jumpers on this new revision are different from what's pictured. There are only two, labeled BDMGI/BDMGO and BIAKI/BIAKO. Whether these are in or our makes no difference: I don't know whether that's because I've missed something else or because the backplane (H9278 in a PDP11/23+) isn't terminated. 

demo tl, * r results in 

6 of 8 tests failed, error rate = 75.00000% = 750000ppm)

0) buslatch[0] = 0xff (bits = 0xff)

1) buslatch[1] = 0xff (bits = 0xff)

2) buslatch[2] = 0x6b (bits = 0xff, R/W bits = 0x3f)

3) buslatch[3] = 0x0e (bits = 0x8f, R/W bits = 0x00)

4) buslatch[4] = 0x7f (bits = 0x7f, R/W bits = 0x7f)

5) buslatch[5] = 0x0f (bits = 0x3f, R/W bits = 0x1f)

6) buslatch[6] = 0xdf (bits = 0xff)

7) buslatch[7] = 0x00 (bits = 0x00, R/W bits = 0x00)

[Timberwoof Lupindo]

I looked closely at all the failure reports and saw that the failures have to do with all but two of the driver chips. I swapped those two with their neighbors and ran the test again. The failures moved. I see some possibilities: 10 of the AM26S10 chips are bad, or it's puking because there's no termination. (Does the H9276-A have its own termination? The CPU seems to run ok with the memory board, but the docs suggest that the KDF11-B has terminators.) Should I get a M9400-YB TEV11 and run the tests again, or pop for the cheaper replacement driver chips? 

[Joerg Hoppe]

Hi,

strange. it's unlikely a 26S10 is bad, but if the error moves with the chips?

Termination is a "must".

You can test single QBUS signal line levels in the "bs" menu of demo.sh.
Toggle a line, and measure on QBone testpoints wether you have 3.4V for "0" level and about 0V for"1" level.

I also updated the image with DMG and IACK test jumpers in https://www.retrocmp.com/projects/qbone/320-qbone-acceptance-test for the recent PCB.

kind regards,

Joerg

[Timberwoof Lupindo]

Thank you for the newer photo. I should post a photo of my board so I can verify that I have all the required jumpers installed. There's one blue jumper that has no home and I have 27 extra pins. One of the resistor-pack jacks was missing, so I soldered that one (10k) directly to the board.  

The terminator arrived this morning and the DAL line tests now pass. Mostly. BDAL 19 is still unhappy. Since the 23+ is a 22 bit machine, I thought I might have to add 6 terminators for the top 6 bits of address space to the M9400YB. But if it ain't broke, don't fix it. 

BHALT depends on the position of the front panel HALT switch, which makes sense. BEVNT always fails when clock switch is off and sometimes fails when the clock switch is on. I guess this means that the clock signal is intermittently on. ;-) Red switch #2 needs some love. It is always "down". 

All that said, my PDP-11/23+ is up and running with the Bone. It takes a while to test 2MB of RAM (without failure report, so I don't understand the BDAL 19 failure. Is it from lack of termination?) so I turned that off on the dip switch. If I respond Y to START? it halts with error code 173654 which means it's unhappy with the switch settings. 7 is on which should make it boot from an RL02. But if I respond with DL0 it can boot RT11. I successfully booted RT11v5.5fb_dl0.sh and poked around in the monitor, looking at available files. Es klapt!

I had no luck booting RSX-11 or Unix. Maybe I'll suss out the magic spells on those. I've got Unix on my Mac, so I want to investigate RSX-11. 

Just curious: is there a real-time clock in Qbone that the OS can get time and date from? (It would have to subtract 1940 years or so to get a year that won't make RT-11 puke, but Unix should be okay, right?)

[pbi...@gmail.com]

The nine-slot H9276-A has no provisions for self-termination.

The eight-slot H9278-A does, and there the four R-packs are located below slot 8 / C and D.

--
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 visit https://groups.google.com/d/msgid/unibone/37c018a7-e42e-4389-81a6-27e2b3472fd9n%40googlegroups.com.

[Timberwoof Lupindo]

I figured out the incantations for the different operating systems. 

run the script for the system you want. The file name encodes the boot rive. Most need just "DL0" to tell the boot loader which drive to load from. Unix wants one more command. Type the sh on the unibone ssh link. I have to reset my system. Then I type DL0 on the PDP11 console and hit enter. Unix then wants UNIX. 

rsx11mp46_dl0.sh -aw 22 / DL0 / 

rt11v5.5fb_dl0.sh -aw 22 / DL0 / 

unixv6_dl0_23.sh -aw 22 / DL0 / UNIX

xxdp2.2_dl0.sh -aw 22 / DL0 / 

Now I get to relearn the text editor (I have forgotten so many text editors!) and work the MACRO textbook. 

Who wants a library of Tektronix 4010 graphics commands? I have one in Pascal for my Osborne One. Might be useful for various PDP11 operating systems. 

[Jay Jaeger]

PDP-11's do not generally have "Time of Day" type clocks like might be found on a mainframe.  Instead, one sets a date and time during initialization, and the operating system then counts 50 Hz or 60Hz "ticks" to keep track of time.

BEVENT provides such ticks and as I recall that is sufficient for RT-11 and I *suspect* would be sufficient for RSX-11.  HOWEVER, it is NOT sufficient for Unix V7m.  Unix V7m also requires that a KW11-L or KW11-P compatible type clock status/control word be available.  The Unix operating systems that run on a PDP-11 are all old and some applications might have a y2K problem, but the Unix clock epoch started in 1970 (so it would not know what to do with a date earlier than that), and though I have not tried, I suspect that Unix V7m itself would be OK with a post 2000 date, until 2038 when it "rolls over".

There was for some 11/23's a bootstrap module which contained a (possibly write-only?) clock status/control register, but without looking at manuals, I don't remember what module did that.  For my 11/23, I am considering hacking a DLV11-E to provide that clock control.

If you try to boot V7m with the clock enabled by the switch, it will typically panic or hang during boot because it gets an interrupt for which it is not yet prepared.  If the switch behind the front panel has disabled the clock, it will panic indicating there is no clock.

JRJ

[Jay Jaeger]

Unix 6th edition (v6) will not run on an 11/23.  ;)

JRJ

[Timberwoof Lupindo]

Yes, it will. 

$unixv6_dl0_23.sh -aw 22

loaded all the stuff. The on the console… 

START? dl0

!UNIX

worked for me. It responded with

unix v6 11/23

mem = 100 KW max = 63

ADVENT did not want to run during business hours.

[Jay Jaeger]

Ah.  That is a "hacked" version.  Original 6th edition came out long before the LSI/Q-Bus machines, and would absolutely not run on them without kernel modifications.  It also didn't know anything about RL01/RL02 drives.

V7m might be a better choice for folks.  Much better C compiler, for one thing.  The V6 C compiler is a very early C compiler.

JRJ

[Alexander]

Hi all,

Almost finished testing my Qbone (version 2024-07) in a MicroPDP-11/73 (H9278-A backplane). All cards removed, Qbone in top slot (Q/CD), grant jumpers removed, BEVNT/50Hz jumper removed.

The test in demo.sh fails on:

TL>>>* r

Highspeed random values in register latches (including demuxed ADDR), stops on error or by ^C.
Error buslatches_test_simple_pattern_multi(pattern=5), pass 0, PRU exerciser pattern=0:
  register 5: wrote 0x12, read back 0x16, error bit mask 0x04
  No prev addr/val history
Signal path for bus latch 5, bit 2 (mask 0x04):
  Write: P9.30 -> J24.3 DATOUT_2 -> CPLD2 -> U18.11 -> U18.12 -> BEVNT
  Read : P8.43 <- J29.3 DATIN_2 <- CPLD2 <- U15.13 <- U15.07 <- U18.10 <- U18.12 <- BEVNT
1 of 1 tests failed, error rate = 100.00000% = 1e+06ppm)

I can't see/measure a connection between P9.30 and J24.3 also not between P8.43 and J29.3. Is this as expected?

The BEVNT pin is connected to U18 pin 9 on the AM26S10. Pin 9 is connected to pad 12 so is the pin numbering in the demo tool based on DS8614?

Swapped AM26S10 with other positions so defective IC is ruled out. Am I overlooking something obvious?

Op woensdag 18 december 2024 om 20:15:57 UTC+1 schreef cub...@gmail.com:

[Joerg Hoppe]

Hi,

the error image is typical for an active BEVENT/50Hz signal. Is the Power supply generating the LTC signal?

do you have a passive terminator installed ? M9400 or QProbe?

are other register working? Try isolated tests with

0 r
1 r
2 r
...

7 r

happy xmas,

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 visit https://groups.google.com/d/msgid/unibone/5d347352-7eb9-4105-b7ac-c9359c8f6d7dn%40googlegroups.com.

[Alexander]

Hi Joerg,

With dipswitch 1 on the BA23 front panel to the on position I measure no clock on the BEVENT pin and the 5 r test shows:

TL>>>5 r

Highspeed random values in register latch 5, stop with ^C.
pass 1 test_register_simple_pattern(5, 5): wrote 0x13, read 0x17

Signal path for bus latch 5, bit 2 (mask 0x04):
  Write: P9.30 -> J24.3 DATOUT_2 -> CPLD2 -> U18.11 -> U18.12 -> BEVNT
  Read : P8.43 <- J29.3 DATIN_2 <- CPLD2 <- U15.13 <- U15.07 <- U18.10 <- U18.12 <- BEVNT

0) buslatch[0] = 0x23 (bits = 0xff)
1) buslatch[1] = 0x4d (bits = 0xff)
2) buslatch[2] = 0x23 (bits = 0xff, R/W bits = 0x3f)
3) buslatch[3] = 0x04 (bits = 0x8f, R/W bits = 0x00)
4) buslatch[4] = 0x12 (bits = 0x7f, R/W bits = 0x7f)
5) buslatch[5] = 0x17 (bits = 0x3f, R/W bits = 0x1f)
6) buslatch[6] = 0xa9 (bits = 0xff)

7) buslatch[7] = 0x00 (bits = 0x00, R/W bits = 0x00)

With switch 1 in the off position I measure a perfect 50Hz on the BEVENT pin, 5 r shows the same result though:

TL>>>5 r

Highspeed random values in register latch 5, stop with ^C.
pass 1 test_register_simple_pattern(5, 5): wrote 0x3, read 0x7

Signal path for bus latch 5, bit 2 (mask 0x04):
  Write: P9.30 -> J24.3 DATOUT_2 -> CPLD2 -> U18.11 -> U18.12 -> BEVNT
  Read : P8.43 <- J29.3 DATIN_2 <- CPLD2 <- U15.13 <- U15.07 <- U18.10 <- U18.12 <- BEVNT

0) buslatch[0] = 0x00 (bits = 0xff)
1) buslatch[1] = 0x00 (bits = 0xff)
2) buslatch[2] = 0x00 (bits = 0xff, R/W bits = 0x3f)
3) buslatch[3] = 0x00 (bits = 0x8f, R/W bits = 0x00)
4) buslatch[4] = 0x00 (bits = 0x7f, R/W bits = 0x7f)
5) buslatch[5] = 0x07 (bits = 0x3f, R/W bits = 0x1f)
6) buslatch[6] = 0x00 (bits = 0xff)

7) buslatch[7] = 0x00 (bits = 0x00, R/W bits = 0x00)

I don't have a M9400 or Qprobe, the backplane has a row of terminators below the bottom 8th row.

The chassis is of a working 11/73.

Frohe Weihnachten

Alexander

Op dinsdag 24 december 2024 om 17:57:58 UTC+1 schreef ioerg...@gmail.com:

[Joerg Hoppe]

Hi,

in the "bs" menu, you have an isolated test, wether BEVENT is really under QBone control.

When you set BEVENT to 0 and 1 and measure the voltage on QBone test point, you can
identify wether BEVENT moves, and wether the error is on the transmitter or the receiver path.

Joerg

To view this discussion visit https://groups.google.com/d/msgid/unibone/703c1dd5-c13d-4e0b-be53-a77f6d51f5d9n%40googlegroups.com.

[Alexander]

Hello,

Just did some test.

With dipswitch to down position (on?) 0Hz on BEVNT pin:

In BS>> I'm unable to set 22 to 0. It returns EVNT=1. Same when I'm reading back EVNT.

With dipswitch to up position (off?) 50Hz on BEVNT pin:

In BS>> I'm unable to set 22 to 0. It returns random 0 and 1.

Reading EVNT signal gives also random results, a few EVNT=0 followed by a few EVNT=1.

Do I understand correctly that when I measure the 50Hz signal on the BEVNT pin the EVNT status follows the 50Hz square wave?

PS: I'm new to PDP-11, just got my first real one a few months ago.

Op woensdag 25 december 2024 om 09:09:58 UTC+1 schreef ioerg...@gmail.com:

[Joerg Hoppe]

Hi,

>
> With dipswitch to down position (on?) 0Hz on BEVNT pin:

Huh? The 4 DIP switches do not control the generation of BEVENT by the
QBone.

>
> In BS>> I'm unable to set 22 to 0. It returns EVNT=1. Same when I'm
> reading back EVNT.
>
> With dipswitch to up position (off?) 50Hz on BEVNT pin:
>
> In BS>> I'm unable to set 22 to 0. It returns random 0 and 1.
> Reading EVNT signal gives also random results, a few EVNT=0 followed
> by a few EVNT=1.
>
> Do I understand correctly that when I measure the 50Hz signal on the
> BEVNT pin the EVNT status follows the 50Hz square wave?

Yep.
And most QBUS signals are inverted, so for "inactive" = "logic 0" you
measure a high voltage of about ~3.4V, if properly terminated.
And QBUS signals are "wired-OR", can be pulled to GND ("Logic 1") by
multiple sources.
If you see a permanent ""logic 1", then BEVENT is tied to GND.

Before QBone selftest, you must see it permantely at "logic 0" = ~3.4 V.

Joerg

[Joerg Hoppe]

Hi, I think I understand now what you've done to disable BEVENT:

Either on your Hxxxx backplane or on an PDP11/23-like frontpanel you set an "AUX control" or "LTC disabled" switch.

(not sure about the controls on your Heathkit).

DECs way is then to overwrite the 50Hz from powersupply with a constant GND (logic 1) level.

Anyhow, its been always a challenge do do full QB one "* r" selftest on a DEC QBUS machine, as it's difficult to disable the LTC generation
(and not: erasing by forcing it to GND). I now wonder why this topic didn't pop up here more often.

kind regards,

Joerg

[Alexander]

Hi,

With dipswitch I meant the LTC or BEVENT Enable switch on the BA23 control panel. With this switch on disable I see a logic 1 on the BEVENT pin, so I assume this works as it should be.

The result of TL>>>5 r is the same in both switch positions, e.g. Signal path for bus latch 5, bit 2 (mask 0x04) fails

TL>>>5 r

Highspeed random values in register latch 5, stop with ^C.

pass 0 test_register_simple_pattern(5, 5): wrote 0x9, read 0xd

Signal path for bus latch 5, bit 2 (mask 0x04):
  Write: P9.30 -> J24.3 DATOUT_2 -> CPLD2 -> U18.11 -> U18.12 -> BEVNT
  Read : P8.43 <- J29.3 DATIN_2 <- CPLD2 <- U15.13 <- U15.07 <- U18.10 <- U18.12 <- BEVNT
0) buslatch[0] = 0x00 (bits = 0xff)
1) buslatch[1] = 0x00 (bits = 0xff)
2) buslatch[2] = 0x00 (bits = 0xff, R/W bits = 0x3f)
3) buslatch[3] = 0x00 (bits = 0x8f, R/W bits = 0x00)
4) buslatch[4] = 0x00 (bits = 0x7f, R/W bits = 0x7f)

5) buslatch[5] = 0x0d (bits = 0x3f, R/W bits = 0x1f)

6) buslatch[6] = 0x00 (bits = 0xff)
7) buslatch[7] = 0x00 (bits = 0x00, R/W bits = 0x00)

The LTC switch was in the off position before I start testing the Qbone, in this position my 11/73 works flawlessly (from a noobs prospective that is).

If this * r test only fails on BEVNT in an otherwise good functioning 11/73, did my Qbone "pass" the test? The other test on the website (TG>>> etc.) did pass. :)

Op vrijdag 27 december 2024 om 12:37:06 UTC+1 schreef ioerg...@gmail.com:

[Alexander]

And to finish my contribution to this thread, I can report that my Qbone is working as is. I can boot RT11, now see if I can also get RSX11 and 2.11BSD working :)

Op vrijdag 27 december 2024 om 21:49:22 UTC+1 schreef Alexander:

[Joerg Hoppe]

Hi,

And to finish my contribution to this thread, I can report that my Qbone is working as is. I can boot RT11, now see if I can also get RSX11 and 2.11BSD working :)

success ... nice. I planned to make the "* r"  test optionally to ignore the BEVENT line ... maybe later.

kind regards,

Joerg

To view this discussion visit https://groups.google.com/d/msgid/unibone/a935bea2-37a2-4036-a75c-5a945ca8ea4bn%40googlegroups.com.