24 May
2016
24 May
'16
3:27 p.m.
Hi all --
I'm working on restoring a VAX-11/730 at the museum and things have been going pretty
well thus far. I've been bootstrapping the console and diagnostics from simulated
TU58 (images from: https://github.com/NF6X/VAX-11-730-Console-v57). All of the TU58-based
diagnostics are passing.
I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage and I'm
having trouble with it. I thought I'd check with you guys to see if any of you have
seen this issue or have any idea where I might be obviously going wrong before I start
digging deeper into this.
The current issue is that I can't get the UC17's built in diagnostic/utility
(referred to as the 'FRD' in the manual) to run. I am following all of the steps
to the letter (see the manual here
http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC1751001-C…,
pages 71-79 (section 4.5.7)) and I'm getting the right values back when examining the
SA register during the process, but executing "S 80" halts after a second or so
with:
?08 PC=00000298
Which is an odd way for it to halt, 08 means "No user WCS" according to the
11/730 user's guide.
Here's the full conversation, just in case:
>> I
>> D/L/P F26800 80000000
>> D/L/P F26804 80000001
>> D/W/P FFF46A 3003
>> E/W/P FFF46A
P 00FFF46A 0100
>> D/W/P FFF46A 4401
>> E/W/P FFF46A
P 00FFF46A 0400
>> S 80
?08 PC=00000298
I've confirmed that the issue isn't with the card, I can run the FRD without issue
on it, in an 11/44 we have here.
I've done my best to ensure that everything is sane on the UNIBUS; my understanding
from the 11/730 manuals is that by default none of the SPC slots have the NPG wire-wrap
fitted and that any empty SPC slots need to have an NPG grant card installed. (This makes
sense given how difficult the backplane is to access, it requires pulling the power supply
out first.) Just to make sure, I have double-checked that the NPG wirewrap jumper is not
present on Slot 10, where the UC17 is installed. At the moment the grant chain should be
unbroken as far as I can tell, here is the current configuration:
TOP
Slot 1 - Empty (normally RB730 option)
Slot 2- Empty (normally FPA option)
Slot 3- M8390 (DAP)
Slot 4- M8391 (MCT)
Slot 5- M8394 (WCS)
Slot 6- M8750 (1mb memory)
Slot 7- M8750 (1mb memory)
Slot 8- M8750 (1mb memory)
Slot 9- M8750 (1mb memory)
Slot 10- Emulex UC17
Slot 11- DMF32-AA
Slot 12- M9302 terminator | G7273 grant
BOTTOM
Thanks as always for the help.
- Josh
24 May
24 May
3:48 p.m.
On Tue, May 24, 2016 at 12:27 PM, Josh Dersch
<JoshD at livingcomputermuseum.org> wrote:
Hi all --
I'm working on restoring a VAX-11/730 at the museum and things have been going pretty
well thus far. I've been bootstrapping the console and diagnostics from simulated
TU58 (images from: https://github.com/NF6X/VAX-11-730-Console-v57). All of the TU58-based
diagnostics are passing.
I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage and
I'm having trouble with it. I thought I'd check with you guys to see if any of
you have seen this issue or have any idea where I might be obviously going wrong before I
start digging deeper into this.
The current issue is that I can't get the UC17's built in diagnostic/utility
(referred to as the 'FRD' in the manual) to run. I am following all of the steps
to the letter (see the manual here
http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC1751001-C…,
pages 71-79 (section 4.5.7)) and I'm getting the right values back when examining the
SA register during the process, but executing "S 80" halts after a second or so
with:
?08 PC=00000298
Which is an odd way for it to halt, 08 means "No user WCS" according to the
11/730 user's guide.
Here's the full conversation, just in case:
Don't know if this will help at all. Not sure if the UC07 and UC17
share the same firmware and VAX host resident FRD code. On the QBus
UC07 version (firmware version G143R) there is a short stub located at
80h which jumps to the main code at 280h. (If you have a VCB02 instead
of a serial console you start at 82h which then jumps to 282h and does
something slightly different).
I dumped the memory for this code from the VAX and entered it into
SIMH to use SIMH as an VAX unassembler and this is what it looks like.
If the UC17 host resident VAX code is the same, any clues here as to
what might be causing a halt on the 11/730?
sim> e -m 80-87
80: BRB 85
82: BRW 282
85: BRW 280
sim> e -m 280-3d3
280: BRB 298
282: BISB2 #1,27F
286: MOVL #80000003,@#2008800C
291: MTPR #800,#4
298: MOVL #80000002,@#20088008
2A3: NOP
2A4: MTPR #1F,#12
2A7: MOVAL 400,R1
2AE: MOVL #200,R2
2B5: MOVL #0,(R1)+
2B8: SOBGTR R2,2B5
2BB: MOVL #20001468,R5
2C2: CLRW (R5)
2C4: BITW #800,2(R5)
2CA: BEQL 2C4
2CC: MOVW #3003,2(R5)
2D2: CMPW #100,2(R5)
2D8: BNEQ 2D2
2DA: MOVW #4600,2(R5)
2E0: CMPW #400,2(R5)
2E6: BNEQ 2E0
2E8: MOVW #400,2(R5)
2EE: TSTB 27F
2F1: BEQL 30E
2F3: MOVL #1,R0
2F6: JSB @#20040008
2FC: CMPB #18,R0
2FF: BNEQ 304
301: BRW 362
304: EXTZV #0,#7,R0,R0
309: MOVL R0,R2
30C: BRB 338
30E: MFPR #20,R1
311: BBC #7,R1,362
315: MFPR #21,R2
318: EXTZV #0,#7,R2,R2
31D: CMPB R2,#13
320: BNEQ 338
322: MFPR #20,R0
325: BBC #7,R0,322
329: MFPR #21,R0
32C: EXTZV #0,#7,R0,R0
331: CMPB R0,#11
334: BNEQ 322
336: BRB 362
338: BISW2 #200,R2
33D: MOVW R2,2(R5)
341: MOVW 2(R5),R2
345: BITW #200,R2
34A: BEQL 341
34C: BICL2 #200,R2
353: MOVW R2,2(R5)
357: MOVW 2(R5),R2
35B: BITW #200,R2
360: BNEQ 357
362: MOVW 2(R5),R2
366: BITW #100,R2
36B: BEQL 2EE
36D: MOVW R2,2(R5)
371: MOVW 2(R5),R2
375: BITW #100,R2
37A: BNEQ 371
37C: BICW2 #100,R2
381: MOVW R2,2(R5)
385: EXTZV #0,#7,R2,R2
38A: BEQL 3C4
38C: TSTB 27F
390: BEQL 3B3
392: MOVB R2,3CF
399: MOVAL 3C7,R0
3A0: JSB @#2004000C
3A6: MOVW 2(R5),R2
3AA: BITW #100,R2
3AF: BEQL 3A6
3B1: BRB 36D
3B3: MFPR #22,R1
3B6: BBC #7,R1,3B3
3BA: MTPR R2,#23
3BD: MFPR #22,R1
3C0: BBC #7,R1,3BD
3C4: BRW 2EE
>> I
>> D/L/P F26800 80000000
>> D/L/P F26804 80000001
>> D/W/P FFF46A 3003
>> E/W/P FFF46A
P 00FFF46A 0100
>> D/W/P FFF46A 4401
>> E/W/P FFF46A
P 00FFF46A 0400
>> S 80
?08 PC=00000298
I've confirmed that the issue isn't with the card, I can run the FRD without
issue on it, in an 11/44 we have here.
4:58 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Glen Slick
Sent: Tuesday, May 24, 2016 12:48 PM
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: VAX-11/730 and Emulex UC17 woes
On Tue, May 24, 2016 at 12:27 PM, Josh Dersch
<JoshD at livingcomputermuseum.org> wrote:
Don't know if this will help at all. Not sure if the UC07 and UC17 share the
same firmware and VAX host resident FRD code. On the QBus
UC07 version (firmware version G143R) there is a short stub located at 80h
which jumps to the main code at 280h. (If you have a VCB02 instead of a
serial console you start at 82h which then jumps to 282h and does something
slightly different).
Interesting, the UC17 has the same firmware version (G143R) on the label of the EPROM. I
wonder if the contents are identical. Could you send me a dump of your ROM so I can
compare?
Hi all --
I'm working on restoring a VAX-11/730 at the museum and things have
been going
pretty well thus far. I've been bootstrapping the console and
diagnostics from simulated TU58 (images from:
https://github.com/NF6X/VAX-11-730-Console-v57). All of the TU58-based
diagnostics are passing.
I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage
and
I'm having trouble with it. I thought I'd check with you guys to see if any
of you have seen this issue or have any idea where I might be obviously
going wrong before I start digging deeper into this.
The current issue is that I can't get the UC17's built in diagnostic/utility
(referred to as the 'FRD' in the manual) to run. I am following all of the
steps
to the letter (see the manual here
http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC175
1001-C_UC17_Dec90.pdf, pages 71-79 (section 4.5.7)) and I'm getting the
right values back when examining the SA register during the process, but
executing "S 80" halts after a second or so with:
?08 PC=00000298
Which is an odd way for it to halt, 08 means "No user WCS" according to the
11/730 user's guide.
Here's the full conversation, just in case:
issue on it, in an 11/44 we have here.
>> I
>> D/L/P F26800 80000000
>> D/L/P F26804 80000001
>> D/W/P FFF46A 3003
>> E/W/P FFF46A
P 00FFF46A 0100
>> D/W/P FFF46A 4401
>> E/W/P FFF46A
P 00FFF46A 0400
>> S 80
?08 PC=00000298
I've confirmed that the issue isn't with the card, I can run the FRD without
I dumped the memory for this code from the VAX and entered it into SIMH
to use SIMH as an VAX unassembler and this is what it looks like.
If the UC17 host resident VAX code is the same, any clues here as to what
might be causing a halt on the 11/730?
The values in/around 298 look to be identical, but I haven't dumped everything in
memory. I'll poke at the code, do some disassembly and see I can figure out
what's going on...
Thanks!
Josh
sim> e -m 80-87
80: BRB 85
82: BRW 282
85: BRW 280
sim> e -m 280-3d3
280: BRB 298
282: BISB2 #1,27F
286: MOVL #80000003,@#2008800C
291: MTPR #800,#4
298: MOVL #80000002,@#20088008
2A3: NOP
2A4: MTPR #1F,#12
2A7: MOVAL 400,R1
2AE: MOVL #200,R2
2B5: MOVL #0,(R1)+
2B8: SOBGTR R2,2B5
2BB: MOVL #20001468,R5
2C2: CLRW (R5)
2C4: BITW #800,2(R5)
2CA: BEQL 2C4
2CC: MOVW #3003,2(R5)
2D2: CMPW #100,2(R5)
2D8: BNEQ 2D2
2DA: MOVW #4600,2(R5)
2E0: CMPW #400,2(R5)
2E6: BNEQ 2E0
2E8: MOVW #400,2(R5)
2EE: TSTB 27F
2F1: BEQL 30E
2F3: MOVL #1,R0
2F6: JSB @#20040008
2FC: CMPB #18,R0
2FF: BNEQ 304
301: BRW 362
304: EXTZV #0,#7,R0,R0
309: MOVL R0,R2
30C: BRB 338
30E: MFPR #20,R1
311: BBC #7,R1,362
315: MFPR #21,R2
318: EXTZV #0,#7,R2,R2
31D: CMPB R2,#13
320: BNEQ 338
322: MFPR #20,R0
325: BBC #7,R0,322
329: MFPR #21,R0
32C: EXTZV #0,#7,R0,R0
331: CMPB R0,#11
334: BNEQ 322
336: BRB 362
338: BISW2 #200,R2
33D: MOVW R2,2(R5)
341: MOVW 2(R5),R2
345: BITW #200,R2
34A: BEQL 341
34C: BICL2 #200,R2
353: MOVW R2,2(R5)
357: MOVW 2(R5),R2
35B: BITW #200,R2
360: BNEQ 357
362: MOVW 2(R5),R2
366: BITW #100,R2
36B: BEQL 2EE
36D: MOVW R2,2(R5)
371: MOVW 2(R5),R2
375: BITW #100,R2
37A: BNEQ 371
37C: BICW2 #100,R2
381: MOVW R2,2(R5)
385: EXTZV #0,#7,R2,R2
38A: BEQL 3C4
38C: TSTB 27F
390: BEQL 3B3
392: MOVB R2,3CF
399: MOVAL 3C7,R0
3A0: JSB @#2004000C
3A6: MOVW 2(R5),R2
3AA: BITW #100,R2
3AF: BEQL 3A6
3B1: BRB 36D
3B3: MFPR #22,R1
3B6: BBC #7,R1,3B3
3BA: MTPR R2,#23
3BD: MFPR #22,R1
3C0: BBC #7,R1,3BD
3C4: BRW 2EE
5:14 p.m.
On Wed, May 25, 2016 at 8:58 AM, Josh Dersch
<JoshD at livingcomputermuseum.org> wrote:
Interesting, the UC17 has the same firmware version
(G143R) on the label of the EPROM. I wonder if the contents are identical. Could you
send me a dump of your ROM so I can compare?
>
> I dumped the memory for this code from the VAX and entered it into SIMH
> to use SIMH as an VAX unassembler and this is what it looks like.
> If the UC17 host resident VAX code is the same, any clues here as to what
> might be causing a halt on the 11/730?
Here's what I found comparing my code with someone else's dump:
I've been working this with Glen Slick. Here's a snippet of a recent
email with him. He provided a dump of the DMAed loader from his UC07:
The raw binary dumped on the VAX looked like this:
>>E/P/L 80
P 00000080 FD310311
>>E
P 00000084 01F83101
>>E
P 00000280 01881611
>>E
P 00000284 8FD0F9AF
>>E
P 00000288 80000003
>>E
P 0000028C 08800C9F
>>E
P 00000290 008FDA20
>>E
P 00000294 04000008
>>E
P 00000298 00028FD0
>>E
P 0000029C 089F8000
>>E
P 000002A0 01200880
First mismatch is here; P 000002A0 0100F308
>>E
P 000002A4 DE121FDA
>>E
P 000002A8 000153EF
>>E
P 000002AC 8FD05100
>>E
P 000002B0 00000200
>>E
P 000002B4 8100D052
>>E
P 000002B8 D0FA52F5
>>E
P 000002BC 0014688F
But mine has P 000002BC FFF4688F
>>E
P 000002C0 65B45520
Mine had P 000002C0 65B45500
>>E
Ran out of time at this point - but enough to establish at least
*some* values are different.
Tried S 80 - different error! ?05 PC=00000344
I did 'I' then started from scratch - D/L/P F26800... etc.
Same result.
Here's a quote from an email exchange from a couple of months ago on
same issue: dumb question: have you tried just booting it without
running FRD?
"I think that UC17 is identical to UC07 firmware-wise. At least my
UC17 EPROM is marked UC07. There is some posts on vcfed.org forum on
UC07 firmware quite recently.
Why do you need to enter the FRD? I never needed to do that. Just
inserted the SCSI2SD with the SD-card in it and booted. Worked
straight away."
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
7:03 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mike Ross
Sent: Tuesday, May 24, 2016 2:15 PM
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: VAX-11/730 and Emulex UC17 woes
On Wed, May 25, 2016 at 8:58 AM, Josh Dersch
<JoshD at livingcomputermuseum.org> wrote:
Thanks. Glen sent me his dump and I compared with mine. I have the same three
differences:
D 000002A0 01200880 // 0100F308
D 000002BC 0014688F // FFF4688F
D 000002C0 65B45520 // 65B45500
(commented values are the ones that differ on my machine).
This changes the code as below:
-> 298: MOVL #80000002,@#F30808 (was: 298: MOVL #80000002,@#20088008)
2A3: NOP
2A4: MTPR #1F,#12
2A7: MOVAL 400,R1
2AE: MOVL #200,R2
2B5: MOVL #0,(R1)+
2B8: SOBGTR R2,2B5
-> 2BB: MOVL #FFF468,R5 (was 2BB: MOVL #20001468,R5)
I suspect these values are changed "on the fly" based on the machine type
punched into the SA register as the last step before the "S 80" command; in
particular, the source address for the MOVL instruction at 2BB now makes more sense,
corresponding to a value in the UBA register set for the UC17.
However, F30808 doesn't make sense as the destination argument address for the MOVL at
298. This looks like a map register for an 11/750 (as documented in the UC17 manual as
being at F30800/F30804) and I wondered if it should be similar to the value for the 11/730
(F26800/F26804).
So I changed the instruction at 298 to:
MOVL #80000002,@#F26808
(which corresponds to a change in the value at 2A0 to 0100F268)
On the VAX-11/730 and did an "S 80" and lo and behold, it works!
I suspect either a typo in the manual for the machine type designator word, or a revision
difference between firmware and documentation.
- Josh
Interesting, the UC17 has the same firmware
version (G143R) on the label
of the EPROM. I wonder if the contents are identical.
Could you send me a
dump of your ROM so I can compare?
>
> I dumped the memory for this code from the VAX and entered it into
> SIMH to use SIMH as an VAX unassembler and this is what it looks like.
> If the UC17 host resident VAX code is the same, any clues here as to
> what might be causing a halt on the 11/730?
Here's what I found comparing my code with someone else's dump:
I've been working this with Glen Slick. Here's a snippet of a recent email with
him. He provided a dump of the DMAed loader from his UC07:
The raw binary dumped on the VAX looked like this:
<snipped for brevity>
7:07 p.m.
On Wed, May 25, 2016 at 11:03 AM, Josh Dersch
<JoshD at livingcomputermuseum.org> wrote:
*another snip*
Thanks. Glen sent me his dump and I compared with
mine. I have the same three differences:
D 000002A0 01200880 // 0100F308
D 000002BC 0014688F // FFF4688F
D 000002C0 65B45520 // 65B45500
(commented values are the ones that differ on my machine).
This changes the code as below:
-> 298: MOVL #80000002,@#F30808 (was: 298: MOVL #80000002,@#20088008)
2A3: NOP
2A4: MTPR #1F,#12
2A7: MOVAL 400,R1
2AE: MOVL #200,R2
2B5: MOVL #0,(R1)+
2B8: SOBGTR R2,2B5
-> 2BB: MOVL #FFF468,R5 (was 2BB: MOVL #20001468,R5)
I suspect these values are changed "on the fly" based on the machine type
punched into the SA register as the last step before the "S 80" command; in
particular, the source address for the MOVL instruction at 2BB now makes more sense,
corresponding to a value in the UBA register set for the UC17.
However, F30808 doesn't make sense as the destination argument address for the MOVL
at 298. This looks like a map register for an 11/750 (as documented in the UC17 manual as
being at F30800/F30804) and I wondered if it should be similar to the value for the 11/730
(F26800/F26804).
So I changed the instruction at 298 to:
MOVL #80000002,@#F26808
(which corresponds to a change in the value at 2A0 to 0100F268)
On the VAX-11/730 and did an "S 80" and lo and behold, it works!
Ooooh! I'll have to try that! Thanks. Great sleuthing!
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
4:20 p.m.
On Wed, May 25, 2016 at 7:27 AM, Josh Dersch
<JoshD at livingcomputermuseum.org> wrote:
Hi all --
I'm working on restoring a VAX-11/730 at the museum and things have been going pretty
well thus far. I've been bootstrapping the console and diagnostics from simulated
TU58 (images from: https://github.com/NF6X/VAX-11-730-Console-v57). All of the TU58-based
diagnostics are passing.
I'm attempting to bring up an Emulex UC17 SCSI controller for mass storage and
I'm having trouble with it. I thought I'd check with you guys to see if any of
you have seen this issue or have any idea where I might be obviously going wrong before I
start digging deeper into this.
The current issue is that I can't get the UC17's built in diagnostic/utility
(referred to as the 'FRD' in the manual) to run. I am following all of the steps
to the letter (see the manual here
http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/emulex/UC1751001-C…,
pages 71-79 (section 4.5.7)) and I'm getting the right values back when examining the
SA register during the process, but executing "S 80" halts after a second or so
with:
?08 PC=00000298
Which is an odd way for it to halt, 08 means "No user WCS" according to the
11/730 user's guide.
Here's the full conversation, just in case:
That sounds a HELL of a lot like the issues I was having - and which I
haven't resolved yet. Someone provided me with a hex dump of memory
starting at location 80 as you say and what I found was that the code
I was seeing that the UC17 had loaded into memory had several
locations with quite different values to those that had been dumped
>> I
>> D/L/P F26800 80000000
>> D/L/P F26804 80000001
>> D/W/P FFF46A 3003
>> E/W/P FFF46A
P 00FFF46A 0100
>> D/W/P FFF46A 4401
>> E/W/P FFF46A
P 00FFF46A 0400
>> S 80
?08 PC=00000298
I've confirmed that the issue isn't with the card, I can run the FRD without
issue on it, in an 11/44 we have here.
I've done my best to ensure that everything is sane on the UNIBUS; my understanding
from the 11/730 manuals is that by default none of the SPC slots have the NPG wire-wrap
fitted and that any empty SPC slots need to have an NPG grant card installed. (This makes
sense given how difficult the backplane is to access, it requires pulling the power supply
out first.) Just to make sure, I have double-checked that the NPG wirewrap jumper is not
present on Slot 10, where the UC17 is installed. At the moment the grant chain should be
unbroken as far as I can tell, here is the current configuration:
TOP
Slot 1 - Empty (normally RB730 option)
Slot 2- Empty (normally FPA option)
Slot 3- M8390 (DAP)
Slot 4- M8391 (MCT)
Slot 5- M8394 (WCS)
Slot 6- M8750 (1mb memory)
Slot 7- M8750 (1mb memory)
Slot 8- M8750 (1mb memory)
Slot 9- M8750 (1mb memory)
Slot 10- Emulex UC17
Slot 11- DMF32-AA
Slot 12- M9302 terminator | G7273 grant
BOTTOM
Thanks as always for the help.
- Josh from a working system. I did the obvious and manually
deposited at
least the first few 'wrong' locations to the 'correct'
values; the
behaviour changed. Instead of halting with an error the run light
stayed on but no utility menu was displayed; the machine was hung. I
recently obtained and very briefly tried a second UC17 with similar
results - except on this card (same firmware version) the values in
memory prior to 'S 80' were even more 'wrong'.
Haven't got further yet but will have a hack in a few days. Do you
know beyond peradventure that the NPG wire-wrap IS removed? I don't
and will have to check.
My 11/730 also passed all diags - well until it got to the RL02 bit
where it failed due to no RL02!
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
2981
days inactive
2981
days old
6 comments
3 participants
participants (3)
-
glen.slick＠gmail.com -
JoshD＠LivingComputerMuseum.org -
tmfdmike＠gmail.com