How to configure the Unibone for an 11/05 or 11/10

[Roland]

I recently got a PDP11/10 and I'm very happy with it. I did some work on it and showed that on

the vcfed forum. http://www.vcfed.org/forum/showthread.php?75940-Oh-dear-4-bits-extra!-PDP11-10

It is a basic machine with 8KW of memory. I found a defective M9301, fixed it, and now I can run the monitor program.

Because I knew this machine would come to me, I ordered a Unibone kit a while ago. My goal is to use it as a RAM

expansion and I liked the idea of the emulated RL01 disks. I have a real RX11 controller and a DL11 serial port.

I want to use these later in this machine. Probably need to fix the boards first...

Question 1: How do I setup the Unibone to only emulate the 8...56KW RAM and the RL01 disks?

Question 2: How do I setup the Unibone to start with this configuration automatically?

No need for the emulated M9312 because I have a real M9301 which I want to use.

I have a bunch of PDP8 computers which I can handle with my eyes closed. But I'm new to the PDP11

and also new to the whole Unibone world. So a bit help on the Unibone is highly appreciated.

Thanks in advance!

Regards, Roland

[Roland]

Since my M9301 does not support the RL01, I think it is better to emulate

the RK05 together with the 8...56KW RAM for my 11/10.

But please can anyone explain to me how I setup the emulator properly?

For the PDP11 / Unibone pros it is probably too obvious.

But for a newbee it is not...

[Joerg Hoppe]

Roland,

If you log-in to your UniBone (you did?) you see lots of *.sh scripts.

These start various OSses from various disks for various PDP-11 models, build your own from these.

All these scripts scan for installed memory and emulate missing to the max.

And these scripts also dump the required disk bootloaders into memory, to be executed mostly from address 10000 to boot drive #0.

For you '05 you may start with

./mini-unix_dk0_05.sh

or

./xxdp25_dl0.sh

./rt11v5,5sj_dl1_34.sh should also work, must be booted from drive #1 via the bootloader start addr 10010.

I .RUN ADVENT from these on VCFB shows regulary.

As these are indeed newbee questions, I hoped for some of the other guys to answer.

Shame on you!

Seems I need to add something to the startup-doku delivered on paper, any hints?

kind regards,

Joerg

[Roland]

Hi Joerg,

Thank you for your response! I did hook up a terminal emulator to the uart 1 of

the Unibone and also ran the update procedure to get the latest files from GitHub as well.

When I start the ./xxdp25_dl0.sh application it is waiting at: " Disable memory emulation, size physical memory ... "

I'm not sure what to do at that point. It seems that it wants to know how much core memory is really there.

When I hit the START button the Unibone continues and displays:

"Now emulating UNIBUS memory in range 000000..757776 with DDR memory."

Then it loads to the end at the message that the drives are ready, load from address 10000 etc...

But it doesn't seem to see the real memory in the system.

My machine has 8KW of core which I tested roughly trough the front panel and that works.

To prevent conflicts I thought lets pull the core memory out of the system.

When I repeat loading ./xxdp25_dl0.sh it is again waiting at the message:

" Disable memory emulation, size physical memory ... " Hitting START again on

the PDP11 lets the Unibone load the devices up to the disks ready part again.

But loading address 10000 and hitting start just makes the machine step to 10002. And that's it.

When I check the memory trough the front panel I can see the emulated memory working.

I can read and write outside the original 8KW limit as well. So that is good!

So I wonder, am I doing something wrong? Or is it time for some maindecs? :-)

I got the feeling that the waiting at the memory size is a test program which has to run in

real core and give the size info back to the Unibone? And because my 11 is not giving back

the info the Unibone waits forever there unless I hit the START button once? Just guessing here...

Regards, Roland

[Joerg Hoppe]

Roland,

Thank you for your response! I did hook up a terminal emulator to the uart 1 of

the Unibone and also ran the update procedure to get the latest files from GitHub as well.

Things are faster if you  login over ssh with a terminal like putty .

It sounds as if your CPU is HALTed ... HALT switch to RUN?

UniBones memory sizer  works via DMA, which requires an active CPU to perform the Request/Grant protocol with NPR/NPG/SACK wires.

It is also possible the DMA GRANT chain is not closed ... must be done on the backplane's pin side via wire wrap.
Make sure pins NPGIN/NPGOUT on pins CAB/CB1 are wrapped together on all slots not holding a DMA capable controller card.

For that task I designed

http://www.retrocmp.com/tools/unibus-spc-g7273-diagnostics

.. you could order a bunch of 5 or so at one of these cheap PCB makers.

Joerg

When I start the ./xxdp25_dl0.sh application it is waiting at: " Disable memory emulation, size physical memory ... "

I'm not sure what to do at that point. It seems that it wants to know how much core memory is really there.

When I hit the START button the Unibone continues and displays:

"Now emulating UNIBUS memory in range 000000..757776 with DDR memory."

Then it loads to the end at the message that the drives are ready, load from address 10000 etc...

But it doesn't seem to see the real memory in the system.

My machine has 8KW of core which I tested roughly trough the front panel and that works.

To prevent conflicts I thought lets pull the core memory out of the system.

When I repeat loading ./xxdp25_dl0.sh it is again waiting at the message:

" Disable memory emulation, size physical memory ... " Hitting START again on

the PDP11 lets the Unibone load the devices up to the disks ready part again.

But loading address 10000 and hitting start just makes the machine step to 10002. And that's it.

When I check the memory trough the front panel I can see the emulated memory working.

I can read and write outside the original 8KW limit as well. So that is good!

So I wonder, am I doing something wrong? Or is it time for some maindecs? :-)

I got the feeling that the waiting at the memory size is a test program which has to run in

real core and give the size info back to the Unibone? And because my 11 is not giving back

the info the Unibone waits forever there unless I hit the START button once? Just guessing here...

Regards, Roland

--
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/ce196098-597c-4f9f-93a8-735a19729094o%40googlegroups.com.

[Roland]

Hi Joerg,

 

It sounds as if your CPU is HALTed ... HALT switch to RUN?

Yes the HALT/ENABLE switch is enabled.

 

UniBones memory sizer  works via DMA, which requires an active CPU to perform the Request/Grant protocol with NPR/NPG/SACK wires.

It is also possible the DMA GRANT chain is not closed ... must be done on the backplane's pin side via wire wrap.
Make sure pins NPGIN/NPGOUT on pins CAB/CB1 are wrapped together on all slots not holding a DMA capable controller card.

Ah good to know how that works. Thanks, did some measurements.... See picture

 

I checked these signals. After executing the xxdp program the RUN LED turns on and NPR goes high.

After a second the RUN LED goes off again. The program runs until the "Disable memory...." and there the NPR goes low.

But I don't see any response happening on the NPG or SACK lines. I've cut the NPG wire between CA1 and CB1.

I thought lets check some connections with my multimeter. The weird thing is that there is still a zero ohm connection

between CA1 and CB1 while the wire is cut. Now that is strange to say the least! I think they made a direct connection

between both terminators... I think I have to investigate that first...

Oh, another question. can you PLOT the Unibone schematic to a PDF instead of printing it to PDF in Kicad?

It is in the same file menu but just under print. That will make the schematic searchable for

net labels etc. Far more convenient to use...

Thanks!

Regards,Roland

[Joerg Hoppe]

Hi Roland,

>
> I checked these signals. After executing the xxdp program the RUN LED
> turns on and NPR goes high.
> After a second the RUN LED goes off again. The program runs until the
> "Disable memory...." and there the NPR goes low.
> But I don't see any response happening on the NPG or SACK lines.

OK, thats the error.

Would be interesting to see NPR/NPG/SACK directly on the CPU.

> I've cut the NPG wire between CA1 and CB1.
> I thought lets check some connections with my multimeter. The weird
> thing is that there is still a zero ohm connection
> between CA1 and CB1 while the wire is cut. Now that is strange to say
> the least! I think they made a direct connection
> between both terminators... I think I have to investigate that first...

I've seen older backplanes (on 11/40), which are not wired for DMA, so
NPR/NPG/SACK always connected to the terminator there, with strange
conenction in between.
Maybe the SPC slots were oginally meant for really SMALL Peripheral
Controllers, which don't do DMA.

>
> Oh, another question. can you PLOT the Unibone schematic to a PDF
> instead of printing it to PDF in Kicad?
> It is in the same file menu but just under print. That will make the
> schematic searchable for
> net labels etc. Far more convenient to use...

Here it is.

Joerg

[Todd Goodman]

FWIW, I have Joerg's G7273 diagnostics bare board available (US$20 each) along with many of his other boards (https://retrobrewcomputers.org/doku.php?id=boardinventory#dec_digital_boards_designed_by_joerg_hoppe).

These boards have hard gold on the contact edges

I'm in the US but happy to ship internationally

Contact me privately if you're interested.

But if you can get boards cheaper or want to get them yourself in any case, that's great!

Joerg has made all his board design files freely available to everybody so we all have the option and I appreciate it very much!

Many thanks,

Todd

To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/847c0502-2f9a-2363-a494-a862ed19072c%40gmail.com.

[Roland]

Joerg, thanks for the schematic!

Today I have done some measurements again. And I think the problem is not directly caused by the NPR / NPG.

It seems the CPU has to be in RUN state to generate that NPG signal. But way before the NPR is sent by

the Unibone, the machine goes out of RUN state.

See my measurements at E45/8815. The RUN signal should be LOW to make the NPR valid to generate a NPG signal.

Can you confirm that the machine should be in RUN state while running the XXDP simulation until the NPR comes in?

Any idea's on why the machine goes out of the RUN state that early? I really think I need to run some maindecs...

@ Todd,

>> Joerg has made all his board design files freely available to everybody so we all have the option and I appreciate it very much!

Yes sharing is also my style. I have made some projects for Omnibus machines. Including clones of some controller

boards like the RX8E floppy controller, TA8E TU60 controller, VC8E graphics board set, a bootloader etc...
https://github.com/Roland-Huisman?tab=repositories Maybe I should make a website for this too...

Regards, Roland

[Joerg Hoppe]

Roland,

Today I have done some measurements again. And I think the problem is not directly caused by the NPR / NPG.

It seems the CPU has to be in RUN state to generate that NPG signal. But way before the NPR is sent by

the Unibone, the machine goes out of RUN state.

Sounds strange, not sure whats going on on your side.

Is the machine running when UniBone is plugged out? Are UniBone's Selftest-jumpers on BG* and NPG removed? Best sent a photo. Did you got the machine running by any other means? Some Boot ROM code?

What happens if your deposit 777 into 0 and run it?

       2                                        .asect
       3                               
       4 000000                                 .=0
       5                                1$:
       6 000000 000777                          br 1$
       6                               

See my measurements at E45/8815. The RUN signal should be LOW to make the NPR valid to generate a NPG signal.

Can you confirm that the machine should be in RUN state while running the XXDP simulation until the NPR comes in?

Any idea's on why the machine goes out of the RUN state that early? I really think I need to run some maindecs...

Confirm: CPU must RUN steadily for DMA and boot code to execute.

Joerg

[Roland]

Hello Joerg,

The jumpers are in the picture. I have set the NPG out one step back to disconnect it from the bus.

This is because my system shorts the CA1 and CB1. I presume the NPG out isn't necessary at the

moment since I have no other devices on the bus.

I have just run these Unibone self tests again and it passes it with flying colours...

http://retrocmp.com/projects/unibone/287-unibone-acceptance-test

The 777 runs forever. I have a M9301 and it is running the monitor program without problems.

Also connected to PDP11GUI and that runs fine as well... The only weird thing

is that the monitor program stops when I press 'examine all' for the CPU.

In the mean while I'm completely lost in the maindec woods...

Regards, Roland

[Roland]

In the meanwhile I have run the T15 combined instruction test (D0OA). I tested it for 30 minutes and no problems.

Any other maindecs to be advised to run on the machine to test functions that might be needed for the Unibone?

Is there a way to single step trough the XXDP program to check exactly when/where my PDP11 goes out or RUN?

And I've been playing with the demo application. The bus master test program

allowed me to do "sz" and it gives back the correct amount of core memory in the machine.

TM>>>[22:55:34.190671 Inf  UNAPT] UNIBUSADAPTER::worker(0) started
[22:55:34.191209 Inf  UNAPT] Trying to set thread realtime priority = 50
[22:55:34.191511 Inf  UNAPT] Scheduling is at RT priority.
[22:55:34.191657 Inf  UNAPT] Thread priority is 50
sz

Found valid addresses in range 000000..037776.
Current EXAM/DEPOSIT address is 000000

TM>>>

Regards, Roland

[Joerg Hoppe]

Roland,

In the meanwhile I have run the T15 combined instruction test (D0OA). I tested it for 30 minutes and no problems.

Any other maindecs to be advised to run on the machine to test functions that might be needed for the Unibone?

Is there a way to single step trough the XXDP program to check exactly when/where my PDP11 goes out or RUN?

No. The xxdp.sh is not exactly a "program", just a call to a "demo" with a command file which works like a keyboard macro to enable emulation of a specific set of devices.

And I've been playing with the demo application. The bus master test program

allowed me to do "sz" and it gives back the correct amount of core memory in the machine.

TM>>>[22:55:34.190671 Inf  UNAPT] UNIBUSADAPTER::worker(0) started
[22:55:34.191209 Inf  UNAPT] Trying to set thread realtime priority = 50
[22:55:34.191511 Inf  UNAPT] Scheduling is at RT priority.
[22:55:34.191657 Inf  UNAPT] Thread priority is 50
sz

Found valid addresses in range 000000..037776.
Current EXAM/DEPOSIT address is 000000

As expected! "Bus master mode" is used for HALTed CPU, then we do UNIBUS accesses without DMR/DMG/SACK protocol.

best regards,

Joerg

[Roland]

Okay, I did a lot of tests on my PDP11. I found maindecs for these tests and the machine runs them all without any problems.

TEST 01 BRANCH
TEST 02 CON BRANCH
TEST 03 UNARY
TEST 04 UNARY + BINARY
TEST 05 ROTATE SHIFT
TEST 06 COMPARE
TEST 07 COMPARE NOT
TEST 08 MOVE
TEST 09 BIS, BIC + BIT
TEST 10 ADD
TEST 11 SUBTRACT
TEST 12 JMP
TEST 13 JSR, RTS, RTI
Test 14 TRAP TEST
Test 15 COMBINED INSTRUCTION TEST
Test 17 SYSTEM EXERCISER

Do I need any other tests to run on a minimal 11/10 configuration with 8KW of memory?

Because the machine runs all these tests I'm pretty convinced that the PDP11 is working okay.

So I made a slow motion video to see what actually happens when I start ./xxdp2.5_dl1.sh.

The RUN LED goes ON at the line: " [22:48:21.927443 Inf    APP] Registering Non-PRU GPIO pins. "

When the line " *** UniBone technology demonstrator build Jul 13 2020 22:14:16 " appears, the RUN LED goes off.

root@unibone:~# ./xxdp2.5_dl1.sh
iarg1=8, iarg2=15
[22:48:21.926404 Inf    APP] Printing verbose output.
demo  - UniBone test application.
    Version DBG v1.5.0, compile Jul 13 2020 22:06:34.
[22:48:21.927443 Inf    APP] Registering Non-PRU GPIO pins.
[22:48:21.927670 Inf  GPIOS] GPIO0 registers at 44E07000 - 44E07FFF (size = 1000
[22:48:21.927925 Inf  GPIOS] GPIO1 registers at 4804C000 - 4804CFFF (size = 1000
[22:48:21.928151 Inf  GPIOS] GPIO2 registers at 481AC000 - 481ACFFF (size = 1000
[22:48:21.928370 Inf  GPIOS] GPIO3 registers at 481AE000 - 481AEFFF (size = 1000
[22:48:21.935546 Inf    APP] Disable DS8641 UNIBUS drivers.
[22:48:21.935746 Inf    APP] Leave SYSBOOT mode.


*** UniBone technology demonstrator build Jul 13 2020 22:14:16

After this line the PDP11 RUN LED does not turn on any more and the UniBone is loading

the software up to the " Disable memory emulation, size physical memory ... "

I would love to know how I can do some tests with the UniBone and PDP11 to test where this

goes wrong. Maybe the knowledge of when the LED turns off does ring a bell at somebody?

Thanks in advance!

Roland

[Joerg Hoppe]

Roland,

we already traced the problem down to missing NPG response. Any news on this?

Neither can UniBone probe memory then, nor can you boot XXDP from RL drive, as both do DMA.

I assume your CPU tests run disk-less (=DMA-less) , how did you loaded them into memory?

Joerg

[roelof...@yahoo.com]

Hi Joerg,

The response to the NPR signal seems to be missing because the machine is not in RUN state at the moment that the
UniBone triggers the NPR line. The PDP11 goes out of RUN mode way before the NPR signal is triggered.

You can see that in the picture with my measurements earlier in this topic.

But, because the PDP11 is not in RUN mode at the moment that NPR is triggered, it will never generate a NPG signal.

So I wondered why the machine is not in RUN when the NPG is triggered...

That is the reason why I made the slow motion film. Just to see when things happen.

I have no reference about when the PDP11 should be in RUN mode in the process of starting ./xxdp2.5_dl1.sh

Does the PDP11 go in RUN mode and stays in RUN mode? Or does it have to go in RUN a few times?

For now it seems the PDP11 goes out of RUN as soon as "*** UniBone technology demonstrator build Jul 13 2020 22:14:16"

appears on the screen. After that the PDP11 does not go into RUN anymore.

When the machine is waiting at the memory sizer and I press RUN on the PDP11, the software loads further.
So when the PDP11 is in RUN mode the NPG is actually generated. But then it is emulating the full memory range.

Maybe I should make a little youtube film so you can see what happens?

Regards, Roland

 

[Joerg Hoppe]

Hi Roland,

you can execute the xxdp.cmd script manually by starting the "demo" application.

The first 3 commands are# inputfile for demo to select a rl1 device in the "device test" menu.

d            # device test menu
pwr
.wait 3000        # wait for PDP-11 to reset
m i            # install max UNIBUS memory

The PDP-11 is started by "pwr".

"pwr" generates a faked power-cycle by stimulating the ACLO & DCLO signals.

Depending on your system config, the '05 may not start executing code on power-up, but read some trash at vector 24 and HALT.

Does your M9301 boot into the console emulator on power-up?

Joerg

[Roland]

Hi Joerg,

When I execute " pwr " in the demo application the RUN LED turns on for a second.

When I type " m i " I get the "Disable memory emulation, size phisical memory... " and waits there

up to the moment when I press the RUN switch on the PDP11. After that I get the message that

it emulates memory from 000000 to 757776. So it does not see the memory at that moment.

For your M9301 question, I tested the PDP11 with the M9301 only to check if it can do the auto start.

And no, it does not start the PDP11 automatically with the dip switch set to auto start.

But when I connect TP2 to TP3 it starts the monitor right away. (Normally I start the monitor

trough the front panel at 173000. Normally I have disabled the auto start.)

BUT when I set the auto start on the M9301 at ON and then run the XXDP it goes much further.

Disable memory emulation, size physical memory ...

Now emulating UNIBUS memory in range 040000..757776 with DDR memory.

XXDP Runs all the way up to RL drives ready and the PDP11 stays in RUN. That looks like the right

thing to see! I didn't knew the Unibone was actually relying on the presence of a M9301...

So baby steps, lets see how I can start stuff from there... Thanks for pointing me to the M9301 settings...

Regards, Roland

[Joerg Hoppe]

Hi Roland,

XXDP Runs all the way up to RL drives ready and the PDP11 stays in RUN. That looks like the right

thing to see!

I hope your M9301 shows its "$" prompt now.

According to documentation M9301s are too old for RL11/01/02 and don't contain a "DL" bootloader.

Thats why each "demo" script dumps a bootloader into memory, see information printout.

 

I didn't knew the Unibone was actually relying on the presence of a M9301...

To be precise, not Unibone itself but the emulation scripts do.

I included the "pwr" command in all "demo"-scripts for comfort to make sure a HALTed CPU starts running.

Didn't realize that it may stop an already running CPU, if something is wrong with auto-start.

You can just comment out "pwr" from the *.cmd scripts.

regards,

Joerg

[roelof...@yahoo.com]

Hi Joerg,

Yes it shows the $. I uploaded all the maindecs earlier using the monitor and your wonderful PDP11GUI tool to test the bare system.

But I did start the monitor by hand at 173000 and never used the power up auto start. That auto start

at power on doesn't even work on this PDP11. But with your info on the pwr command I started to think

if I could trigger the M9301 with the PWR command when the M9301 was set to auto start. And it did.

With the dip switch set to auto start, I started XXDP and then it actually did what was expected/hoped for :-)

I have the M9301-YF. That seems to be the most complete M9301 ROM version for available bootstraps,

but indeed too old for the RL drives... So I have to start the bootloader which is dumped into memory manually.

I will try that tonight, but this looks very promising now :-) Thanks for all your work, patience and help!

Regards, Roland

.

[Roland]

Yesss! RT11 up and running!

Regards, Roland

.

[roelof...@yahoo.com]

Hi,

I've repaired my RX11 controller (replaced a broken 74H74 and a SN74157) and now it runs the maindec completely without errors.
I have written a RT11 disk image onto a few 8" disks to use with the system. But very often RT11 on the emulated RL02 does not seem
to recognize the drive when booting. When I enter DIR DX0: the system hangs. And after hitting ctrl-C RT11 does not come back to the prompt.
But sometimes it just works ok. So I'm wondering do I need to set some settings on the Unibone for the startup?

Regards, Roland

 

[Joerg Hoppe]

Roland,

no quick idea on that. So far the UniBone emulation software runs good in parallel with physical devices ... despite this was quite hard to achive.

The current state of the UNIBUS signals lines could help, do you have a UniProbe or similar display?

My step would be to monitor the UNIBUS signal history with an analyzer for the last failing transaction, and have an eye on the IRQ/DMA lines.

I wonder if anybody ran an RX11 in parallel with UniBone.

Many ideas for further variation tests:

- repeat the above setup in a different PDP-11?

- can you run other physical disk/tapes in parallel with UniBone-RL02?

- what if you boot from RX11 and access UniBone-RL02 as add-on disk?

- can you boot XXDP from UniBone-RL02 and access the physical RX11?

- can you boot RT11 from UniBone-MSCP and access the physical RX11?

- what if you install RT11 on the UniBone-RK05 and access the physical RX11?

- Too bad you can notboot RSX11 on the '05 from UniBone-RL02 and access the physical RX11.

Joerg

[Roland]

Hi Joerg,

Thanks for the input. I went back to the minimal configuration and found that the RX11 was still causing the problems sometimes.

Now this was a bit hard to find honestly... Sometimes the RX11 worked perfectly, other times it refused to pass the maindec.

It seems there was something on the board which was working on the edge of it specs. So I was following the signal path to see if

I could find any abnormalities like low TTL levels caused by a partly failing TTL chip output circuitry. ( I had these kind of problems

in my PDP8/L as well where some chips just got their output level to max 1.5V... )

But all levels were quite normal and I could not find any errors with my HP 10529A logic comparator.

Dec uses 10K pull up resistors to pull up some inputs from multiple chips. While checking the levels on the

RUN flip-flop the level on pin 10 dropped to approx 1.8V when starting the maindec. Now that is weird! This input should

stay high trough the pull up, and should not drop... So I thought lets put an 1K resistor for R12 instead of the 10K.

That fixed the voltage to drop on that line. And also stopped unexpected interrupts and resulted in a

normal RUN signal to the RX01 drive. This makes sense because that B-H line is also feeding the int enable FF.

Now it was running the maindec again. And this time for an hour without any errors... So that gave a bit of confidence.

Now I can access the floppy drive from RT11. When I enter BOOT DX0: it boots from the floppy drive.

And while the Unibone is running its emulated drives and memory, I can also boot trough the 173544 bootstrap on the M9301.

Just baby steps... I still think this fix is a bit weird... I will see if there is a cause to be find... Maybe was some oxidation

between pins of a chip causing the B-H line to drop.... But an 1K pull up is fine for me...

Regards, Roland

[Roland]

Just a little question... I want to run the BeagleBone alone to do stuff on the Linux side.

Is it allowed to keep the UniBone in the PDP11 and power the BeagleBone trough its 5V input?

Or does that try to power the whole PDP11 trough the BeagleBone and fry the BeagleBone?

Regards, Roland

[Roland]

>> Paul Birkel answered: Doesn’t K1 that care of that scenario?  It appears that when the UB_5V is powered down the BeagleBone +5VA line is isolated.

Hi Paul,

Yes it seems to be a nice side effect from that power on delay relay. But when you power the BeagleBone

externally and turn on and off the PDP11, then that relay will switch on and will not turn off. Not turning off is

because both power lines are connected together trough the relay. The BeagleBone and adapter can't

give that much power so the external 5V will drop to a level where the relay switches off again and then the

5V will come back... And I guess the BeagleBone will reboot then.

So that will mean that when powering the BeagleBone that it is forbidden to power cycle the PDP11.

But powering only the BeagleBone externally means that the in and output lines will be active as well.

This is while other chips on the board don't have power. I'm not sure if these chips would like that...

So I think the safest way is to pull the card and power it trough the SPC 5V power lines... I should have put this

text together in the first place when asking... But maybe Joerg has experience with my question... Better safe then sorry... :-)

Regards, Roland

[Joerg Hoppe]

Hi Roland and all,

I agree with your analysis: After powering the PDP-11 OFF, the BeagleBone power supply is short-cut through closed K1 by the whole '11 behind.
Voltage drops, K1 opens, and everything is as before, but the 'Bone will reboot. Hope it's reset-circuit can handle such short power-outages.

Damage could occur to the 'Bone's power supply, if it is not shot-cut proof.

Damage may also occur to relay K1: If the BeagleBone's external power supply is very strong, short-cut current may exceed the 2x2A limit of K1, and the contacts may bake.

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/ff3aaeb8-d491-4633-8d5d-718e972ce2d0o%40googlegroups.com.