DLV11-J

[Cliff Miller]

The system is an H9270-Q backplane, the four-slot 18-bit which has jumpers designed to provide 22-bit capability - installed.  The CPU is KDJ11-A 11/73 which has no RAM, ROM, LTC or Serial Port.  For this the QBone is perfect.  I've had it running successfully with QBone providing memory and console but of course was not satisfied.

I obtained a DLV11-J 4-port serial card and am trying to get it running as the console.  There are several messages here and more at VCF about the issues regarding this board - it is Rev D so does not have the ECO to fix an addressing or timing problem with faster systems.

The default factory configuration provides a base address of 176500 but jumpers the fourth channel to the console address of 177560 (all this in 18-bit context).  Set to boot into ODT, the KDJ11 LEDs show it fails to find a console. 

The QBone seems perfect to investigate this problem.  

What emulation setup and steps would you suggest to troubleshoot?  

Is this an 18-bit card in a 22-bit system problem?  The KDJ11 manual mentions the ECO as required but it seems the CPU should at least see the console as addressed.

The H-9270Q backplane is Q-Q all four slots and serpentine in arrangement so I've had the processor in slot 1 and the DLV11 in slot 2 next door so I can probe it easily.  Slots 3 and 4 are Bus-Grant cards to provide clearance for the QBone in slots 5 and 6.

Thanks!

[Cliff Miller]

One addition:  With the DLV11 installed if I try to emulate a DL11 on the QBone the @ character of ODT become garbled as if the two cards are conflicting.

[Juergen Staehler]

Hello Cliff

Have you double-checked that the DL11 device is actually disabled in QBONE?

[Cliff Miller]

Juergen - Yes.  When I run 'demo.sh -aw 22' I go to the Device menu and check the DL11 is disabled.  

With the DLV11 removed (and replaced with a Bus Grant Card) when I enable the DL11 emulation and run the 'pwr' command, the SLU light on the CPU goes out indicating it has found a console.

[Juergen Staehler]

Cliff,

Maybe the following hints can help to narrow down the issue:

You can test the proper DLV11J CSR settings by entering some test characters from within QBONE:

This command write the code (101 octal) for ASCII 'A' to the XBUF register of the DLV11-J console line. You should see the 'A' on your console terminal.

In turn if you enter e.g. the character 'Z' on your console terminal you should read the value 132 (octal) in RBUF register 17777562.

Regards,

Jürgen

[Joerg Hoppe]

Cliff,

some thoughts:

- 18/22 bit QBUS should be no problem: a QBUS peripheral card in the IOPage is always addressed via the BBS7 address signal.

- Juergens suggestions (EXAM/DEPOSIT to 17777562/566) is the way to go.

Deposit to *66 should output an RS232 character. Reading *62 gives the last received RS232 character.

- For debugging, you should remove all other cards from the QBUS for this test, even the CPU.
The QBUS CPU is always polling the console UART, even when HALTed,
With the CPU gone, you'd need a terminator card, (or a QProbe).
Then you can stimulate the DLV11 from QBone in a controlled way.

- Test the other three channels of the DLV11 with QBone EXAM/DEPOSIT.

- if the DLV11 console does not respond, you have to debug the DLV11.
Double Check all its jumpers.

- if this doesn't help, you have to check signals inside the DLV11.
A possible error is one blown BDAL receiver chip, the BDIN, BDOUT receiver, or the driver for BRPLY.

You can execute QBUS DATI/DATO cycle step by step by setting QBUS lines manually in QBone.

Set the address with BBS7 and BDAL, assert SYNC, and check wether the local signals on DLV11 indicate an selected address.

Joerg

[Cliff Miller]

Juergens - Joerg-

Thank you so much for the information, advice and encouraging words.  

The board is now responding one-way from the DLV11 back to the PC I'm using for a terminal.    

With an RS232 LED troubleshooter dongle I found part of the problem. With the 10-pin to DB9 adapter in the QBone UART 2 slot a null-modem adapter was necessary to connect the PC USB to RS232 interface.  With the same 10 pin adapter in channel 3 of the DLV11 I've found that the null-modem is not needed.

Juergens - I've used the 'e' and the 'd' commands based on your suggestions.  Deposit of various characters in the TXBUF for channel 3 console as well as for channel 0 show up on the PC terminal screen.  However sending data from the PC does not show in the RXBUF for either channel and is now the focus of my efforts.

Joerg, your mention of a possible blown receiver chip is my next area of exploration as I get nothing when I try to send characters from the PC terminal to both channel 3 and channel 0.  I've begun checking the cabling and it works halfway to the DLV11 ...

[Juergen Staehler]

Cliff,

If I have not made a mistake (unfortunately, I don't have a DLV11J here to verify it), then the connection between the DLV11 port and a PC should be wired like this:

If the cabling is correct you should measure a negative voltage of > -5 V on both signal lines (RxD and TxD) against the Gnd.

[Dennis Boone]

> Joerg, your mention of a possible blown receiver chip is my next area
> of exploration as I get nothing when I try to send characters from
> the PC terminal to both channel 3 and channel 0. I've begun checking
> the cabling and it works halfway to the DLV11 ...

If there are multiple interfaces with the same problem, you might look
at serial hardware handshake. I've met cases on PCs where e.g. if you
didn't assert one or another handshaking signal on the PC port, it
wouldn't communicate. Pretty sure when I saw this, it was either crappy
serial port hardware, or a software (OS, kermit) bug.

If this is the issue, possible fixes include configuring the terminal
application to not require hardware handshake, or building a serial
cable that just forces the assorted handshake signals (DSR, CD, CTS) to
be asserted on the PC end.

If you have a breakout box, you can test the theory there -- jumper
something like DTR that's asserted to DSR and/or CTS on the PC side. If
your breakout box is minimal (just lights) then you may have to tack
solder fly wires in or something.

I keep a few adapters around that just basically interconnect RTS, CTS,
DSR, CD, DTR. (THERE, I FIXED IT.) Not elegant, but ...

De

[Cliff Miller]

The 10 pin to DB9 connector is an eBay clone of this design by DBIT who have released the details under the name "DLVDB25".  The sales literature specifically mentions the DLV11-J if I recall correctly. Schematic:

I've also discovered the 12V fuse shown on the DLV11-J in Juergen's picture  is open so there is no DTR going to the PC.

Juergen - my sketch looks as if pin 7 on the 10-pin header is grounded from the computer.  For RS-422? compatibility I guess, pins 7 and 8 go to a 9639 op-amp type receiver.

Fuse time.

[Juergen Staehler]

Cliff,

As a PC COM port works with RS232 level, the RxD- port of the RS422/423 receiver IC on the DLV must be connected to a defined signal level, namely Gnd. This is the connection between 7 and 9.

Regarding DTR signal at the PC side: If the terminal emulation program on the PC side is set to 'Xon/Xoff' handshake mode, the DTR and the other handshake signals (RTS/CTS) are ignored and do not need to be wired.

Another hint:

The resistor Rx (bus termination for RS422) has to be removed for RS232!

[Cliff Miller]

I've learned a great deal in exploring this problem but still haven't found the issue.  My efforts this weekend were stymied when the KDJ11-A processor board seemed to stop working.  Old (both of us), purchased used from that auction house, the first symptom was the inability to establish memory emulation on the QBone - the 'hanging' problem when issuing the "m i" or "m" command.

Upon reflection I realized I've connected nothing to the 10-pin connector on the backplane, most importantly the BDCOK signal - what symptoms would that cause if it is floating?

Again, all comments are appreciated.

[Cliff Miller]

It appears as I have the KDJ11 strapped that it provides a BDCOK signal to the bus.

  

My sequence of commands to the QBone was to power up the system, ssh to the QBone, run 'demo.sh' and then establish memory emulation with 'm i' then enable the DL11 console on the QBone. It was necessary to issue the 'pwr' command, perhaps twice, to get the LEDs on the KDJ11 to go out.  I would then have a ODT prompt on the terminal connected to the Linux PC via a USB-to-RS232 adapter.  I could enter ODT commands, check memory addresses and run simple programs I entered.

All the time if I ran the RT11 program rather than 'demo' I could boot the operating system and interact with it on the emulated serial console.

Then the KDJ11 stopped playing.  The system would hang with any attempt to do memory emulation.

I worry that all the power cycles and/or the 'pwr' commands somehow damaged the processor board?

[Steven Hirsch]

On Tue, 23 Jan 2024, Cliff Miller wrote:

> It appears as I have the KDJ11 strapped that it provides a BDCOK signal
> to the bus.  My sequence of commands to the QBone was to power up the
> system, ssh to the QBone, run 'demo.sh' and then establish memory
> emulation with 'm i' then enable the DL11 console on the QBone. It was
> necessary to issue the 'pwr' command, perhaps twice, to get the LEDs on
> the KDJ11 to go out. 

I've noticed the same issue with the status LEDs. An additional reset is
always required to clear them. For whatever reason, I was never able to
automate this in the configuration script.

[Joerg Hoppe]

Steven, CLiff, all,

>
>
>> It appears as I have the KDJ11 strapped that it provides a BDCOK
>> signal to the bus.  My sequence of commands to the QBone was to power
>> up the system, ssh to the QBone, run 'demo.sh' and then establish
>> memory emulation with 'm i' then enable the DL11 console on the
>> QBone. It was necessary to issue the 'pwr' command, perhaps twice, to
>> get the LEDs on the KDJ11 to go out.

At any case, the CPU should be jumpered to boot into ODT, nit trying to
boot from some devcie.

>
> I've noticed the same issue with the status LEDs.  An additional reset
> is always required to clear them.  For whatever reason, I was never
> able to automate this in the configuration script.
>

Agree, there's something difficult in the LSI11/F-11/J-11 startup sequence.

Never understood it fully.  Current theory is like:
Some CPU need existing RAM to process the Power-Off/On sequence, as it
triggers a CPU trap?
So without mem it goes into "double-bus-fault" mode and does not ACK DMA
anymore,
which is needed for the "m i" sequence?
So "hen&egg" between "pwr" and "m i" ?

Then the problem should arise only on QBUS CPUs without physical mem, be
it on-board or on 2nd card.
Maybe existence of CPU cache is also relevant?

You  can try to fix a hanging "m i" by doing "m i" in the "tm" menu,
without CPU DMA protocol support then.
But shouldn't QBUS memory probing then interfer with QBUS traffic
generated by ODT microcode polling the UART?

OK, that was mostly techno-babble. Should read manuals and do a QBUS&LA
analysis instead!

kind regards,

Joerg

[Cliff Miller]

I plan to try my setup using just the emulated console - not time for the DLV11-J yet - with a physical memory board installed to see if that makes a difference. 

[Cliff Miller]

Joerg - The KDJ11-A definitely likes starting up with physical memory present.  I found a static 512KB memory board in an old system and configured it to begin @ address 0.  The CPU is in the first 2 slots, the memory in the 2nd two, then two bus-grant cards for insulation, then the Qbone.  The system came right up.  I was able to do 'm i' to maximize memory and to enable the DL11 emulation.

A 'pwr' command got the status lights correct. A USB-RS232 terminal connected to the Qbone UART2 showed the ODT prompt.  But I still couldn't type to it -

Juergen - Your suggestion to ensure there was no hardware or software handshaking was key to resolving this interface.  I'm using Minicom on Linux and found it is necessary not just to change the interface parameter but to save it as default and to exit the program and start it back up.  I was then able to interact with the ODT prompt two-way.

Back to the DLV11-J...