UC17 question

[tradde]

I have a pdp-11/84 with a UC17 in it. I have not used it in some time as it's heavy and my
back complains when I try to lift it. I did not use it at all when I lived in Colorado. Now
that I am in Texas I have it on a furniture dolly to move it around. It boots just fine.
I can even boot BSD 2.11 off of a 1GB SCSI drive connected to the UC17. I can't boot
my SCSI2SD and I am sure this is because it's not properly defined in the FRD. But I
can't seem to access the FRD. I follow the instructions I wrote down and seem to get
the proper status. But the "200G" command just hangs. So far I haven't found anything
to help with this. I have the Emulex manual but nothing in there seems to talk about
how to solve problems (maybe just a flow chart but does not help much). Any ideas?
I have RSTS on the SCSI2SD and the light goes on when I try to boot it.
Tim R.

 

[AK6DN]

I have a pdp-11/84 with a UC17 in it. I have not used it in some time as it's heavy and my
back complains when I try to lift it. I did not use it at all when I lived in Colorado. Now
that I am in Texas I have it on a furniture dolly to move it around. It boots just fine.
I can even boot BSD 2.11 off of a 1GB SCSI drive connected to the UC17. I can't boot
my SCSI2SD and I am sure this is because it's not properly defined in the FRD. But I
can't seem to access the FRD. I follow the instructions I wrote down and seem to get
the proper status. But the "200G" command just hangs. So far I haven't found anything
to help with this. I have the Emulex manual but nothing in there seems to talk about
how to solve problems (maybe just a flow chart but does not help much). Any ideas?
I have RSTS on the SCSI2SD and the light goes on when I try to boot it.
Tim R.

Well ... I have a UC17 MSCP in my 11/34, and a UC18 MSCP/TMSCP in my 11/44, and I follow the directions in the Emulex manual p.4-33 UC1751001-C_UC17_Dec90.pdf (bitsavers) to poke the appropriate values in the control registers, then run at 200, and FRD starts right up. I have four Seagate 2.1G and one DEC RRDnn CDROM SCSI drive on my 11/34 currently, and a single SCSI2SD with four emulated drives on my 11/44 (RT11, XXDP, 2.11BSD, RSTS) and it boots and runs fine. Using SCSI2SD v4.7.1 firmware currently (it is up to 4.8.3 I think). UC17/18 firmware is G143R.

So it does work. The one thing that disappoints me is that the SCSI2SD is about 50% the transfer performance of the SEAGATE 2.1G SCSI drives (which are 10MB SYNC). Of course the SCSI2SD has much faster random access time (basically zero) compared to the SEAGATE drives. But 2.11BSD 'feels' slower, and using dd to transfer blocks it is as I say 50% as fast. Still usable, however.

Don

 

[tradde]

Well ... I have a UC17 MSCP in my 11/34, and a UC18 MSCP/TMSCP in my 11/44, and I follow the directions in the Emulex manual p.4-33 UC1751001-C_UC17_Dec90.pdf (bitsavers) to poke the appropriate values in the control registers, then run at 200, and FRD starts right up. I have four Seagate 2.1G and one DEC RRDnn CDROM SCSI drive on my 11/34 currently, and a single SCSI2SD with four emulated drives on my 11/44 (RT11, XXDP, 2.11BSD, RSTS) and it boots and runs fine. Using SCSI2SD v4.7.1 firmware currently (it is up to 4.8.3 I think). UC17/18 firmware is G143R.

So it does work. The one thing that disappoints me is that the SCSI2SD is about 50% the transfer performance of the SEAGATE 2.1G SCSI drives (which are 10MB SYNC). Of course the SCSI2SD has much faster random access time (basically zero) compared to the SEAGATE drives. But 2.11BSD 'feels' slower, and using dd to transfer blocks it is as I say 50% as fast. Still usable, however.

Don

This used to work in this system. I had booted both BSD Unix and RSTS many times. Don't know what's preventing it now.
Checked the NPG jumper for slot 9 and it is removed. I see no indication of any errors until the 200G hangs. I guess I'll pull the board
and clean the fingers to see if that helps.

 

[AK6DN]

This used to work in this system. I had booted both BSD Unix and RSTS many times. Don't know what's preventing it now.
Checked the NPG jumper for slot 9 and it is removed. I see no indication of any errors until the 200G hangs. I guess I'll pull the board
and clean the fingers to see if that helps.

My 11/44 is rock solid. Never behaves, never have to reseat/wiggle boards or any of that stuff. Same for connectors.

My 11/34 on the other hand is very finnicky. Sometimes it starts up, other times it hangs. I have cleaned fingers and backplane connections using Deoxit Gold numerous times. Changed CPU backplane and CPU boards. Always the same behavior. I'm beginning to think the BA11K box itself is haunted. With enough fiddling it will come alive again and run for the rest of the day.

NPR/BR connectivity is sometimes an issue, where the system will run fine until the first DMA device kicks in.

I replaced the terminators (M9302) with M9313 modules instead, which feature control registers for testing BR/BG NPR/NPG functionality. M9313 was designed for VAX750 application, but it just another UNIBUS module, so works just fine in a PDP-11. I have one in each of my 11/34 and 11/44 as the bus terminator, and have written a diagnostic to fully exercise BRx/BGx and NPR/NPG functionality, so I can run a quick test on the backplane and validate all the NPR jumpers are valid and working, etc.

Can you read the code loaded at 200+ and is is reasonable PDP-11 code? I believe the register deposits before the 200G cause the UC17 to DMA the FRD loader into memory and the 200G causes you to execute it. If it did not load correctly that would explain 200G going out to lunch.

Don

 

[wa2flq]

I have a pdp-11/84 with a UC17 in it. I have not used it in some time as it's heavy and my
back complains when I try to lift it. I did not use it at all when I lived in Colorado. Now
that I am in Texas I have it on a furniture dolly to move it around. It boots just fine.
I can even boot BSD 2.11 off of a 1GB SCSI drive connected to the UC17. I can't boot
my SCSI2SD and I am sure this is because it's not properly defined in the FRD. But I
can't seem to access the FRD. I follow the instructions I wrote down and seem to get
the proper status. But the "200G" command just hangs. So far I haven't found anything
to help with this. I have the Emulex manual but nothing in there seems to talk about
how to solve problems (maybe just a flow chart but does not help much). Any ideas?
I have RSTS on the SCSI2SD and the light goes on when I try to boot it.
Tim R.

If you are following UC1751001-C_UC17_Dec90_text.pdf make sure you are using xxxxx and yyyyy values from table 4-13 - MSCP. A quick read section 4.5.9 might make someone believe that the yyyyy values are taken from table 4-14, but those are TMSCP (Tape) typical CSR addresses.

The description in Q-BUS version UC0751001-F_UC07_Feb90.pdf section 5.4.2 is only slightly clearer. Assuming a controller CSR base address of 17772150 should get a response of 2000 from step 4 (read of 17772152), which verifies that the FRD bootstrap is downloaded into memory.

Jerry

 

[tradde]

If you are following UC1751001-C_UC17_Dec90_text.pdf make sure you are using xxxxx and yyyyy values from table 4-13 - MSCP. A quick read section 4.5.9 might make someone believe that the yyyyy values are taken from table 4-14, but those are TMSCP (Tape) typical CSR addresses.

The description in Q-BUS version UC0751001-F_UC07_Feb90.pdf section 5.4.2 is only slightly clearer. Assuming a controller CSR base address of 17772150 should get a response of 2000 from step 4 (read of 17772152), which verifies that the FRD bootstrap is downloaded into memory.

Jerry

I am using that document. I have the CSR set to 17772150 and get a 2000 from 17772152 at step 4. All the status
come back normal but the command to start just hangs. I will dump some of 200 onward just to see what is there. Is the FRD
stored in some ROM/PROM. Could this have gotten corrupted somehow? Everything else about the board seems to work fine.

 

[wa2flq]

The FRD procedure does trigger a download of code from the PROM to the memory of your machine. Since you can boot normally from the card with another disk, that rules out quite a few issues.

Have you tried to run FRD with NO drives attached? How about when you have the 1GB SCSI disk attached?

What is the configuration of the SCSI2SD card?

Can you boot the RSTS image on the MicroSD under SIMH or another machine?

If the PROM is marked, what version does it appear to be? G143R is what many of us have (same on the UC07) and if you have the same a comparison with someone who has a programmer might be possible. Before trying the 200g, if you can take and share a dump from 0 to say 1000 it might help figure out what the is amiss.

Can you halt the machine after starting at 200G? If so what reported address and what is the content of the registers?

 

[tradde]

I pulled the SD card and tried to read it on my MacBook Air. It is not readable there. I'd have expected it to at least be
able to read it. So maybe the SD got corrupted somehow. I will try to boot FRD with no devices attached. I did
not try to boot FRD with the 1GB SCSI disk attached (I think). The SCSI2SD is set up with 4 2GB partitions. I will
try the SD on my Windows machine just to be sure. I no longer have the Linux PC that I created this on. I'll
check the PROM but I kind of remember it has no marking. Dumping 0 to 1000 would not be fun as I have no
way to capture the output that I know of.

 

[wa2flq]

I pulled the SD card and tried to read it on my MacBook Air. It is not readable there. I'd have expected it to at least be
able to read it. So maybe the SD got corrupted somehow. I will try to boot FRD with no devices attached. I did
not try to boot FRD with the 1GB SCSI disk attached (I think). The SCSI2SD is set up with 4 2GB partitions. I will
try the SD on my Windows machine just to be sure. I no longer have the Linux PC that I created this on. I'll
check the PROM but I kind of remember it has no marking. Dumping 0 to 1000 would not be fun as I have no
way to capture the output that I know of.

Under OSX you should be able to dump the SD card.

# use this to find the device the SD card is attached to. Make sure you don't Initialize when OS X complains it cannot "read" the disk. Choose ignore.

$ diskutil list

/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: <empty > *4.0 GB disk3



# example RT11 image. a0 is a NOP instruction typically used at the first word of a disk bootstrap.

$ sudo dd if=/dev/disk3 | xxd |more
00000000: a000 0d01 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 1058 1087 0001 ...........X....
00000020: 5f00 7e01 0000 0000 0000 0000 0000 0000 _.~.............
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
. . .
000001b0: 5f00 0002 7708 0200 eb01 c015 e001 c215 _...w...........
000001c0: d201 ca09 4012 ca09 c015 f401 ca09 0000 ....@...........
000001d0: fe01 df8b 74ff fd80 1f94 76ff fa02 8700 ....t.....v.....
000001e0: 0d0a 3f42 4f4f 542d 552d 0049 2f4f 2065 ..?BOOT-U-.I/O e
000001f0: 7272 6f72 0d0a 0a00 ffff ffff ffff ffff rror............



Check out http://www.retrocmp.com/tools/pdp11gui for a Windows Tool to facilitate many aspects of testing, include dumps.

Jerry

 

[tradde]

Thanks for those tips. I had figured that if OSX could not read the disk then I had no chance.
But I followed your instructions (never ever ever do an Initialize unless you know you have to).
I was able to dump the first part and it does indeed start with A0.

00000000: a000 7a01 0600 0000 0a00 0000 4000 68f4 ..z.........@.h.
00000010: 4455 c715 2857 0000 7803 2122 2100 0000 DU..(W..x.!"!...
00000020: 0000 0000 0000 8601 3901 c511 c565 e400 ........9....e..
00000030: c015 3400 150a 027e f71d e0ff 1e01 f71d ..4....~........
00000040: dcff 2c01 f71d d8ff 2801 f71d d8ff 1001 ..,.....(.......
00000050: f76d d2ff 0a01 f71d c8ff 0801 f71d c4ff .m..............

I have to believe the micro SD card is good. Upon using the SCSI2SD utility I
was told the firmware needed upgrading so I did that. Still no go. Tried to
load FRD with nothing attached. Nope.

PROM has label of G143R on it.

After trying to load FRD locations 200 to 206 are:
200: 012737
202: 000340
204: 177776
206: 012705

My pdp-11 assembly memory is quite rusty but I will see what this maps to.
It seems to hang at address 346 if I press the halt switch after the 200G.

340 to 346 are:
340: 000002
342: 016500
344: 000002
346: 032700

 

[tradde]

The FRD procedure does trigger a download of code from the PROM to the memory of your machine. Since you can boot normally from the card with another disk, that rules out quite a few issues.

Have you tried to run FRD with NO drives attached? How about when you have the 1GB SCSI disk attached?

What is the configuration of the SCSI2SD card?

Can you boot the RSTS image on the MicroSD under SIMH or another machine?

If the PROM is marked, what version does it appear to be? G143R is what many of us have (same on the UC07) and if you have the same a comparison with someone who has a programmer might be possible. Before trying the 200g, if you can take and share a dump from 0 to say 1000 it might help figure out what the is amiss.

Can you halt the machine after starting at 200G? If so what reported address and what is the content of the registers?

I do not have Simh installed on any machine at this time. I will attempt to install it on this laptop and see if I can load RSTS from
the image on the SD.

 

[wa2flq]

Thanks for those tips. I had figured that if OSX could not read the disk then I had no chance.
But I followed your instructions (never ever ever do an Initialize unless you know you have to).
I was able to dump the first part and it does indeed start with A0.

00000000: a000 7a01 0600 0000 0a00 0000 4000 68f4 ..z.........@.h.
00000010: 4455 c715 2857 0000 7803 2122 2100 0000 DU..(W..x.!"!...
00000020: 0000 0000 0000 8601 3901 c511 c565 e400 ........9....e..
00000030: c015 3400 150a 027e f71d e0ff 1e01 f71d ..4....~........
00000040: dcff 2c01 f71d d8ff 2801 f71d d8ff 1001 ..,.....(.......
00000050: f76d d2ff 0a01 f71d c8ff 0801 f71d c4ff .m..............

I have to believe the micro SD card is good. Upon using the SCSI2SD utility I
was told the firmware needed upgrading so I did that. Still no go. Tried to
load FRD with nothing attached. Nope.

PROM has label of G143R on it.

After trying to load FRD locations 200 to 206 are:
200: 012737
202: 000340
204: 177776
206: 012705

My pdp-11 assembly memory is quite rusty but I will see what this maps to.
It seems to hang at address 346 if I press the halt switch after the 200G.

340 to 346 are:
340: 000002
342: 016500
344: 000002
346: 032700

I agree that your SD card looks intact. You are on the latest version of firmware I am aware of. No FRD success with no drives rules out SCSI2SD issues.

The first instruction is a MOV #340, @#PSW which would block all interrupts. A reasonable thing to do for most processors druing early bootstrap phases.

Some more instructions before and after the halt point might help us decode what the code was trying to do when it halted. Also include R0-R7 right after the halt.


Jerry

 

[gslick]

Disassembly of the G143R 8051 firmware is available here. I never spent any time trying to understand how the firmware works after dumping it.

www.bitsavers.org/pdf/emulex/firmware/UC07-G143R_disassembly.ZIP

The PDP-11 version of the FRD code is located at 0xE5F2 - 0xE6A5 in the firmware image. That is DMA copied to the PDP-11 host at 200 - 462.

Depositing that code in SIMH and then unassembling it in SIMH looks like this:

sim> E  200-462
200:    012737
202:    000340
204:    177776
206:    012705
210:    000000
212:    005065
214:    000000
216:    032765
220:    004000
222:    000002
224:    001774
226:    012765
230:    030003
232:    000002
234:    022765
236:    000400
240:    000002
242:    001374
244:    012765
246:    043000
250:    000002
252:    022765
254:    002000
256:    000002
260:    001374
262:    012765
264:    002000
266:    000002
270:    105737
272:    177560
274:    100040
276:    113700
300:    177562
302:    120027
304:    000023
306:    001011
310:    105737
312:    177560
314:    100375
316:    113700
320:    177562
322:    120027
324:    000021
326:    001370
330:    000422
332:    052700
334:    001000
336:    010065
340:    000002
342:    016500
344:    000002
346:    032700
350:    001000
352:    001773
354:    042700
356:    001000
360:    010065
362:    000002
364:    016500
366:    000002
370:    032700
372:    001000
374:    001373
376:    016500
400:    000002
402:    032700
404:    000400
406:    001730
410:    010065
412:    000002
414:    016501
416:    000002
420:    032701
422:    000400
424:    001373
426:    042701
430:    000400
432:    010165
434:    000002
436:    105700
440:    001713
442:    105737
444:    177564
446:    100375
450:    110037
452:    177566
454:    105737
456:    177564
460:    100375
462:    000702

sim> E -M 200-462
200:    MOV #340,@#177776
206:    MOV #0,R5
212:    CLR 0(R5)
216:    BIT #4000,2(R5)
224:    BEQ 216
226:    MOV #30003,2(R5)
234:    CMP #400,2(R5)
242:    BNE 234
244:    MOV #43000,2(R5)
252:    CMP #2000,2(R5)
260:    BNE 252
262:    MOV #2000,2(R5)
270:    TSTB @#177560
274:    BPL 376
276:    MOVB @#177562,R0
302:    CMPB R0,#23
306:    BNE 332
310:    TSTB @#177560
314:    BPL 310
316:    MOVB @#177562,R0
322:    CMPB R0,#21
326:    BNE 310
330:    BR 376
332:    BIS #1000,R0
336:    MOV R0,2(R5)
342:    MOV 2(R5),R0
346:    BIT #1000,R0
352:    BEQ 342
354:    BIC #1000,R0
360:    MOV R0,2(R5)
364:    MOV 2(R5),R0
370:    BIT #1000,R0
374:    BNE 364
376:    MOV 2(R5),R0
402:    BIT #400,R0
406:    BEQ 270
410:    MOV R0,2(R5)
414:    MOV 2(R5),R1
420:    BIT #400,R1
424:    BNE 414
426:    BIC #400,R1
432:    MOV R1,2(R5)
436:    TSTB R0
440:    BEQ 270
442:    TSTB @#177564
446:    BPL 442
450:    MOVB R0,@#177566
454:    TSTB @#177564
460:    BPL 454
462:    BR 270

 

[tradde]

Never knew Simh had that feature to disassemble code. Interesting. I also did not know
the source to the firmware was located on bitsavers. Thank you for these two useful pieces
of info. My Mac seems to be missing some developer components needed to build Simh.
I'll have to figure out what and how to get them or load Simh to my Windows box.

 

[wa2flq]

I will venture that this code passes terminal data back and forth between the console serial port and UC17 controller. On some DEC cpu boards, the console is not accessible from the Unibus/Qbus side.

I'd still suggest sharing the registers before the 200G and after the halt. Also the contents of address 210. It shows as a 0 in the PROM dump, but I suspect it gets loaded with the starting CSR of the UC17 after the DMA downloads this code.

 

[tradde]

Ok, the code for FRD loaded matches your dump. So that is good. 210 is indeed the CSR of 172150.
Registers before the 200G and after:

Before: R0=100, R1=32772, R2=22003, R3=0, R4=322, R5=251, R6=172272, R7=165232
After: R0=12, R1=32772, R2=22003, R3=0, R4=322, R5=172150, R6=172272, R7=352

 

[wa2flq]

Looks like the code to assist the controller in FRD mode looks okay then.


Make sure the terminal (or emulation) is set up for correct speed, parity and stop bits. I don't know if there is any in-band handshaking, but a few control-Q and Control-C after 200g is simple enough to try. If you are running the terminal at high speeds, you might want to drop it down and recheck.

If you haven't already, let it run in diagnostic mode (SW1-4 on) and see if reports any problems.

Since there are two FRD's in the unit, one for MSCP and the other for TMSCP (Tape) you might want to flip the device to the latter. I don't think you need to change the CSR for this short test. Just flip SW4-5 and use the same addresses. The controller either needs a power cycle or reset/halt if you are doing this with the system powered up. Note: this may change or reset the NOVRAM, the documentation is not clear on this point. Since your other disks work, think twice before giving this a try.

 

[tradde]

I believe the terminal is set to 38400. It reports the 11/84 start up info properly. I have never
changed anything on this terminal nor the 11/84 port. Not sure why it would not work for the
FRD. I'll try the tape version just as an additional check. I am not too worried about the NOVRAM
being reset. I know how to set it back up once I get into FRD. I'll try the Ctrl-Q just to see what
happens. It's just weird this used to work as this system is now configured. Nothing was changed
since I used it several years ago. The only thing I would do is from time to time I'd power it on
to make sure it would pass the bootup tests and end up at "4" on the front display.

 

[AK6DN]

If you are interested I have a very basic MSCP test program I wrote for checking out my UC17 when I first got it.

Located here: https://www.ak6dn.com/PDP-11/ in TU58/ is 11XX_9.DSK (TU58 image) and 11XX_9.TXT (dir listing) that is a bootable TU58 image with XXDP and some diagnostics. Relevant here is: MSCP.BIC which is a very basic MSCP controller tester. It checks initialization sequencing, driver detection, basic read access.

Under DIAGNOSTICS/ is the listing for it as mscp.lst and the standalone binary mscp.bic. It runs under SIMH as well using the UDA50 device.

Console log:

MSCP Controller Exerciser v1.15

Test1: basic MSCP controller access

Test2: basic controller initialization

Test3: controller illegal opcode response

Test4: check online units
Test4: online check, unit=0, blkcount=21600., mediatype=DU:RD51
Test4: online check, unit=1, blkcount=311200., mediatype=DU:RD54
Test4: online check, unit=2, blkcount=21600., mediatype=DU:RD51
Test4: online check, unit=3, blkcount=891072., mediatype=DU:RA81
Test4: online check, unit=4, not present, status=03
Test4: online check, unit=5, not present, status=03
Test4: online check, unit=6, not present, status=03
Test4: online check, unit=7, not present, status=03

Test5: M9312 basic boot sequence
Test5: bootblock read success, unit=0, bytecount=512.
Test5: bootblock read success, unit=1, bytecount=512.
Test5: bootblock read success, unit=2, bytecount=512.
Test5: bootblock read success, unit=3, bytecount=512.

Test6: sequential read
Test6: sequential read, unit=0, success, blkcnt=1599992., ticks=600., devsiz=21600.
Test6: sequential read, unit=1, success, blkcnt=1574960., ticks=600., devsiz=311200.
Test6: sequential read, unit=2, success, blkcnt=1485648., ticks=600., devsiz=21600.
Test6: sequential read, unit=3, success, blkcnt=1524592., ticks=600., devsiz=891072.

End pass 1. errors 0.

 

[tradde]

Thanks for the info. I have an M7856 that I used long ago to boot an image to an 11/34 that I no longer have using
TU58. I may have to try that if I don't figure something out soon.