Setting up a DECnet network with a Pro380 and Windows client?

[MattisLind]

I found this in the tech manual:



So XACKAL is also connected to the BRPLYL circuit, not just the latch. I don't think you need to trace it.

 

[stanp]

So XACKAL is also connected to the BRPLYL circuit, not just the latch. I don't think you need to trace it.

I found XACKAL connects to the input enable on two 373 latches and pin 13 on a 74LS00 (input to a NAND gate) on the other side of the board - likely part of the bus reply generator in the figure above.

 

[stanp]

I have an unexpected result and I am not sure what to make of it. I patched together a program to enumerate the CTI cards, read the card ID, find the DECNA card and then perform the exact memory test from the diagnostic ROM. The card enumeration and ID code is based on davibear's code. As a starting test, I just enumerated the cards and their IDs. I have three cards in the cage: Slot 1: HDD controller (401), Slot 2: Floppy controller (2004), and Slot 3: DECNA card (42). The program runs and reports the following:

Slot 1: ID 401
Slot 2: ID 2004
Slot 3: ID 424 (not 42)

I moved the DECNA card to slot 6 with the same result. I'm looking for a bug in the code, but not finding one. It reports properly for the HDD and Floppy controllers. The PRO diagnostic does report ID 42 in the start-up error. I asked how could that be if I am reading 424? The ROM disassembly shows an immediate value of 42 is stuffed into a register for the return instead of reading the ID from the top of the ROM. The maintenance disk does recognize the card as DECNA. Could my ROM possibly have 424 as the ID? Or is this a symptom of a card failure with the data lines? I'm happy to post the code if anyone wants to take a look. I haven't run the memory test. Maybe I can accept the 424 and continue?

One possibility is the that control register has the bit set to the Address ROM, even though the control register reset state of 0 should point to the Option ROM. I could try first clearing the control register for that slot. According to the tech manual, "The first six bytes [of the Address ROM] contain the unique address and are accessible via the ROM data window register. The next two bytes contain a checksum value for PROM contents and are also accessible through the ROM data window register." The 424 doesn't seem match the address info on the card.

Is the following correct for the DECNA card? I cannot find mention of the offsets in the tech manuals:

ROM Data Register Base + 0
ROM Address Counter Base + 2
ROM Control Register Base + 4
ROM Memory Base Address Register Base + 6

 

[MattisLind]

I have an unexpected result and I am not sure what to make of it. I patched together a program to enumerate the CTI cards, read the card ID, find the DECNA card and then perform the exact memory test from the diagnostic ROM. The card enumeration and ID code is based on davibear's code. As a starting test, I just enumerated the cards and their IDs. I have three cards in the cage: Slot 1: HDD controller (401), Slot 2: Floppy controller (2004), and Slot 3: DECNA card (42). The program runs and reports the following:

Slot 1: ID 401
Slot 2: ID 2004
Slot 3: ID 424 (not 42)

I moved the DECNA card to slot 6 with the same result. I'm looking for a bug in the code, but not finding one. It reports properly for the HDD and Floppy controllers. The PRO diagnostic does report ID 42 in the start-up error. I asked how could that be if I am reading 424? The ROM disassembly shows an immediate value of 42 is stuffed into a register for the return instead of reading the ID from the top of the ROM. The maintenance disk does recognize the card as DECNA. Could my ROM possibly have 424 as the ID? Or is this a symptom of a card failure with the data lines? I'm happy to post the code if anyone wants to take a look. I haven't run the memory test. Maybe I can accept the 424 and continue?

One possibility is the that control register has the bit set to the Address ROM, even though the control register reset state of 0 should point to the Option ROM. I could try first clearing the control register for that slot. According to the tech manual, "The first six bytes [of the Address ROM] contain the unique address and are accessible via the ROM data window register. The next two bytes contain a checksum value for PROM contents and are also accessible through the ROM data window register." The 424 doesn't seem match the address info on the card.

Is the following correct for the DECNA card? I cannot find mention of the offsets in the tech manuals:

ROM Data Register Base + 0
ROM Address Counter Base + 2
ROM Control Register Base + 4
ROM Memory Base Address Register Base + 6

Are you certain that the ROM address counter is reset when reading the ROM Data register? I.e have you written to the ROM address register in order to reset the counter?

I don't think the HDD nor the floppy controller had a Diag ROM as the DECNA has. They only have one single word that is the ID.

The register layout is correct as far as I see. Unfortunately the tech manual is rather bad. It lacks a lot of interesting details.

 

[czunit]

Hm. Post the source code and I'll try compiling it this weekend.

 

[stanp]

Yes, I clear the ROM address register just before reading the card ID. Attached is the code. The memory test is commented out and just the card enumeration runs.

 

[stanp]

I stuck a memory card in the cage to test MattisLind's suggestion. The memory card is octal 34. The result came back as 344. So, it is definitely a bug. I'll bet it has something to do with the QIOW string.

Bingo! I replaced the length calculation in the QIOW$S call with the returned length from the $EDMSG macro and that fixed the problem. The hint was the "4" and the preceding reporting of "2004" that extended the string by one byte.