UniBone on the VAX-11/780

65 views
Skip to first unread message

Matt Burke

unread,
Jan 24, 2021, 7:28:17 AM1/24/21
to UniBone
I finally got my VAX-11/780 running so I thought I would give it a try with the UniBone. I couldn't seem to get it working properly so I spent some time investigating with the logic analyser and I think I've located the problem. Unfortunately I'm not sure that it can be fixed easily (if at all).

The problem is due to the elongated SSYN phase as described in the UniBone Theory of Operation. The statement that "the slave has endless time to complete the cycle" is only partly true on the VAX-11/780. It's true as long as the CPU does not make another access to the UNIBUS. It should be noted that the UNIBUS on the VAX-11/780 is just a secondary bus hanging off the SBI (Synchronous Backplane Interconnect) via the DW780. The DW780 has to arbitrate for use of the UNIBUS like any other device and seemingly unique to the DW780 there is an arbitration timeout of 51.2uS.

My test scenario is running the command SHOW /UNIBUS from within SYSGEN with the UniBone simulating a UDA50. What I am seeing on the logic analyser is MSYN going active followed by SSYN about 1uS later. MSYN is then cleared after a further 600nS at which point the DW780 will return the read data to the CPU. The UniBone keeps SSYN active whilst it is calling the on_after_register_access() function in the higher level code. About 17uS after the first read SACK goes active as the CPU makes another access to the UNIBUS and the DW780 is trying to arbitrate for use of the bus. After about 65uS the DW780 gives up and returns a value of zero to the CPU as well as setting the "select timeout" bit in the status register. VMS has interrupts enabled for this bit and the handler routine forces a UNIBUS reset and adds an entry to the system error log. During normal operation this means any access to a UniBone simulated device will result in a bus reset and you get OPCOM messages about other UNIBUS devices such as the DEUNA going offline temporarily.

I have been able to boot the VAX diagnostic supervisor from the UniBone but investigation with the logic analyser shows that this is because the software is ignoring the select timeout bit. This means that certain UNIBUS reads are returning zeros which occasionally causes the diagnostic supervisor not to boot.

As this is a problem with the DW780 I suspect this issue will also occur on the VAX 8600. I have been looking at the schematics/technical manuals for the VAX-11/750, VAX-11/730 and VAX 8200 (DWBUA) and as far as I can tell they all have an infinite arbitration timeout so they shouldn't encounter this problem.

I have some ideas on how to fix this which I will experiment with but I thought I would post this here in case I've missed something obvious or if anyone wants me to make any further measurements whilst I still have the logic analyser connected up.

Joerg Hoppe

unread,
Jan 24, 2021, 8:25:17 AM1/24/21
to uni...@googlegroups.com, Josh Dersch
Hi Matt,

thanks for these new tests on the '780 !

I think your measurements and analysis are correct.
UniBone needs to hold SSYN for "infinite" long time.
I've seen times from about 150us to 30ms in rare cases, depending on Debians process scheduling.
This works well on all PDP-11s so far.

I know Josh tested UniBone successfully on a VAX11/750. I do not have access to an UNIBUS VAX, and no other VAX reports arrived here, neither good nor bad ones.

Can you point me to docs about  DW780's "arbitration timeout" ? Why 51.2usecs?

Please keep your LA shots, and if possible document them, maybe we'd need them later.

kind regards,
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/58eb628a-673f-4657-8f0b-32b9c7cdd66cn%40googlegroups.com.


Matt Burke

unread,
Jan 24, 2021, 10:36:22 AM1/24/21
to UniBone
I should mention that I've also tested the UniBone on my PDP-11/05 and PDP-11/84 and it works great. Thanks for developing this excellent hardware!

The SBI works on a major cycle time of 200nS. For a UNIBUS read a command/address is transferred from the CPU to the DW780 during one of these cycles. The DW780 must respond to this command with an acknowledgement within 512 bus cycles (102.4uS) to avoid a timeout. For the DW780 this happens almost immediately. Once the acknowledgement has been sent the CPU will wait a further 512 bus cycles for the requested data otherwise a read data timeout will occur. These timeouts are described on page 2-88 of TB/Cache/SBI Control Technical Description (PDF page 129).

Once the DW780 has sent the acknowledgement of the command it tries to become UNIBUS master through the arbitration process. I've still not worked out exactly how this takes place but you can see the NPR master flip flop on sheet UAIC of the DW780 Field Maintenance Print Set (PDF page 142). The timeouts are handled by the two counters on sheet UAID (PDF page 143). SSYN timeout is 64 x 200nS = 12.8uS and UBSTO (UNIBUS select timeout) is 256 x 200nS = 51.2uS. I'm not sure why these particular values were chosen but it means that worst case you use 51.2 + 12.8 = 64uS of the maximum allowable 102.4uS to return valid data. These timeouts are briefly mentioned in the DW780 Technical Description on page 2-50 (PDF page 80). It also mentions here that unless the software checks the DW780 status register (as VMS does) then it will be unaware that a UNIBUS timeout has occurred!

Regards,

Matt

Joerg Hoppe

unread,
Jan 24, 2021, 12:16:12 PM1/24/21
to uni...@googlegroups.com
Hi Matt,
I should mention that I've also tested the UniBone on my PDP-11/05 and PDP-11/84 and it works great. Thanks for developing this excellent hardware!

The SBI works on a major cycle time of 200nS. For a UNIBUS read a command/address is transferred from the CPU to the DW780 during one of these cycles. The DW780 must respond to this command with an acknowledgement within 512 bus cycles (102.4uS) to avoid a timeout. For the DW780 this happens almost immediately. Once the acknowledgement has been sent the CPU will wait a further 512 bus cycles for the requested data otherwise a read data timeout will occur. These timeouts are described on page 2-88 of TB/Cache/SBI Control Technical Description (PDF page 129).

Once the DW780 has sent the acknowledgement of the command it tries to become UNIBUS master through the arbitration process. I've still not worked out exactly how this takes place but you can see the NPR master flip flop on sheet UAIC of the DW780 Field Maintenance Print Set (PDF page 142). The timeouts are handled by the two counters on sheet UAID (PDF page 143). SSYN timeout is 64 x 200nS = 12.8uS and UBSTO (UNIBUS select timeout) is 256 x 200nS = 51.2uS. I'm not sure why these particular values were chosen but it means that worst case you use 51.2 + 12.8 = 64uS of the maximum allowable 102.4uS to return valid data. These timeouts are briefly mentioned in the DW780 Technical Description on page 2-50 (PDF page 80). It also mentions here that unless the software checks the DW780 status register (as VMS does) then it will be unaware that a UNIBUS timeout has occurred!

Brains starts spinning:

Are the UNIBUS cycles terminated in any case, or is this behaviour software-definable?

What would one of the UNIXes (4.3 BSD, Ultrix) do?

Can the timeout-timer on DW780 be manipulated/disabled? How is the DW780 emulated in SimH, can we use it has test bed?

Is there an alternative implemention for DW780, maybe a later release?

Joerg

Reply all
Reply to author
Forward
0 new messages