• Please review our updated Terms and Rules here

Running RT11 on 11/03 with Emulex UC07 and SCSI2SD

All --

I tried a few things based on the above so I'm going to respond to several posts:

* I did rearrange the cards again to put the UC07 ahead of the SLUs. No change.
* The CPU is in HALT when doing the DMA load. I dumped memory and compared it to the listing above and it matches, so it's definitely loading to RAM.
* I tried "206G" rather than "200G" but it still printed the address and returned to the ODT. I also tried this with the CPU in RUN and it has no impact.

So, the code is definitely being loaded to RAM but not executing. Not sure where to go with this now.
 
Two followup questions.

What is the firmware version on the UC07?

After loading the FRD bootstrap and hitting 200G, what is the address that is printed?

After it halts, Press P a few times. Does the address change (advance?)

While you need to halt the processor to key in the FRD bootstrap, make sure its in RUN mode before typing G or P
 
wa2flq said:
Two followup questions.

What is the firmware version on the UC07?

After loading the FRD bootstrap and hitting 200G, what is the address that is printed?

After it halts, Press P a few times. Does the address change (advance?)

While you need to halt the processor to key in the FRD bootstrap, make sure its in RUN mode before typing G or P
Click to expand...

Thanks.

The firmware is G143R. Verified that the processor was HALT when loading and RUN when, well, running. When entering 200G or 206G, the ODT returns with "000200" or "000206", respectively, followed by the prompt. The address does increment upon hitting P.
 
Just taking a guess here. Turn off the LTC or disable it on the CPU Board. Try it again.


You have a M7270 correct?
 
The CPU board is an M7270.

Great guess on the LTC! I installed J3 on the CPU (to disable the LTC) and it worked! RUN has to be on and no LTC. What's interesting is the Heath H-11 I have has an added LTC switch which is supposed to disable it. I need to look into it more -- maybe the switch isn't connected properly.

Looks like my board was configured for an RA81.

A project for tonight! Thanks!
 
Last edited:
Glad thinks worked out.

I first encountered this about 20+ years ago...


The LSI (Qbus) Processors don't manage PSW the same way the PDP (Unibus) ones did. If the Line Event is enabled and LTC turned on, the interrupts halt the bootstrap on some third party bootstraps.

The bootstrap code for the UC07 won't block the interrupt on the LSI 11/2. Hence the need to disable it via the jumper or panel control. The other processors probably do a better job of power-up reset with LTC enable off.

M7270 - It wasn't a guess. I doxed your site for it.

Let us know how things work out with the SCSI2SD card. Have Fun.
 
Last edited:
Thanks. I meant the "Great Guess" for the LTC rather than the CPU. I just forgot the <CR> when I was typing :)

I've had other encounters with LTC issues, so it's helpful to know about why it impacts booting. Not sure why bootstraps and related programs (I've heard RT-11 sometimes has problems) just didn't mask the Line Event (if it even is maskable; maybe it isn't) if it wasn't needed. Maybe I'm being too simplistic with it...dunno. The M7270 comes with the LTC enabled from the factory.

I don't have anything that explicitly requires it so it's probably best to just leave it disabled. It works now, so I'm going to try to configure it tonight.

Thanks again for the push I needed. Right now, I'm in the FRD...updated the NVRAM per the original thread, selecting RA54. Looks like it formatted it and is now verifying (expected to be no errors since it's an SD card).

Next up...putting RT11 on it.
 
Last edited:
You shouldn't need to SCSI format a SD card for SCSI2SD. Just blast the bits from disk image directly into the SD card, pop into the SCSI2SD, let discover/update the NVRAM. Once FRD shows that the SCSI2SD card is recognized with a reasonable capacity, you should be good to go.

I read back the first raw block of the SD Card to ensure the first byte is o240. Later on you should see a string that says "?BOOT-U-I/O error" That's usually a sign that the image is correctly copied and placed.
 
I formatted it using FRD just to make sure it could communicate successfully (it did). I just made an RD54 image from an RA81 disk (RT11 v5.6) with SIMH and dd'ed it to the card. I also just printed the bootstrap instructions from page 7-4 of the manual. Looks like it DMA's the bootstrap from ROM just like FRD. Hope this works.


...later...

It works! I now have RT-11 v5.07 running! Whoo hoo!

One small anomaly I just noticed. The RUN light stays off even though the switch is set for RUN (yes, the bulb is fine). Not sure why, though.

Thanks again for the help!
 
Last edited:
Congrats and enjoy. Can't help you with the run light.

Last bit of info to pass along as you get started with RT11, SCSI2SD and UC07

1) The SCS2SD will let you put several SCSI targets on the same card. You will need to reload NVRAM to see them. They appear as different units for the DU handler

2) RT11 DU handlers (>5.4 I think) will allow you to logically create up to 256 logical partitions on a MSCP drive. Invisible to anything but RT11. RT11 v5.7 was the best for this, as it allowed you to boot the different partitions.

RT11 can only manage 32 Megabytes for each directory volume. But the DU (MSCP) handler will allow you to select other units (targets) or partitions within a large disk.

.sh dev:du


Device Status CSR Vector(s)
------ ------ --- ---------
DU Resident 172150 154


DU0: is set PORT = 0, UNIT = 0, PART = 0
DU1: is set PORT = 0, UNIT = 0, PART = 1
DU2: is set PORT = 0, UNIT = 0, PART = 2
DU3: is set PORT = 0, UNIT = 0, PART = 3
DU4: is set PORT = 0, UNIT = 0, PART = 4
DU5: is set PORT = 0, UNIT = 0, PART = 5
DU6: is set PORT = 0, UNIT = 0, PART = 6
DU7: is set PORT = 0, UNIT = 1, PART = 0

 
RichCini said:
One small anomaly I just noticed. The RUN light stays off even though the switch is set for RUN (yes, the bulb is fine). Not sure why, though.
Click to expand...

There's usually a jumper to slot 1 for the run lamp. I forget the pin, it's covered in the QBus handbook IIRC. I had to add a wire-wrap jumper on one of my backplanes as it was used as an expansion chassis for another system.
 
Interesting. The light worked when I had the CPU in slot 2...indeed swapping it back to slot 2 makes it work. Why would slot 1 not have a connection to that bus pin?
 
Last edited:
RichCini said:
Interesting. The light worked when I had the CPU in slot 2...indeed swapping it back to slot 2 makes it work. Why would slot 1 not have a connection to that bus pin?
Click to expand...

Ah, probably intended, for whatever reason, to have the CPU in slot 2. Anything before the CPU would need to be something that doesn't use interrupts and bus grant. Since you now have your SCSI board figured out, perhaps try rearranging and see if it continues to work.

Does the Heath manual have anything to say on the board ordering matter?
 
This is a more generic question about using SCSI2SD in this configuration. SCSI2SD enables up to 4 "partitions" on a card and allows specifying the starting block number on the card. So, my plan was to take a 512MB card and write two RD54 images onto it. However, I can't immediately figure out how to get dd to offset to a cylinder when writing. An RD54 image is 311200 blocks (of 512 bytes) so the second drive would start at offset 311200.

Maybe I'm thinking wrongly about how to do this, but any help would be appreciated. Thanks!

Rich
 
RichCini said:
This is a more generic question about using SCSI2SD in this configuration. SCSI2SD enables up to 4 "partitions" on a card and allows specifying the starting block number on the card. So, my plan was to take a 512MB card and write two RD54 images onto it. However, I can't immediately figure out how to get dd to offset to a cylinder when writing. An RD54 image is 311200 blocks (of 512 bytes) so the second drive would start at offset 311200.
Rich
Click to expand...

Hi Rich,

The offset should be specified in blocks, not cylinders. So try something like this for the first partition. It should appear as the second SCSI Target on UC07. This should be same offset that the scsi2sd-util specifies as sectors (where a sector size is 512 bytes).

dd skip=311200 count=311200 bs=512 if=/home/disk.image of=/dev/disk5s1

Where /dev/disk5s1 should be replaced with the actual drive that is mounted for the microSD card. Getting this wrong can ruin your whole day!


Jerry
 
Last edited:
Thanks Jerry. I must have missed that option when I looked the first time. For the output file it's "seek" rather than "skip" (at least on OSX).

In order for the UC07 to recognize the additional drive, you need to check the option for "LUNs as SCSI IDs" in the SCSI2SD configuration. Then, you need to configure the second drive in the FRD on the UC07.

RT-11 started-up just fine (using an existing image; DU0) and then I did "initialize/badblocks du1:" and it seemed to partially work...it never returned to the dot-prompt after printing "?DUP-I-No Bad Blocks Detected DU1:".

So, I created a blank image using SIMH and put a single file on it, then I wrote it to the SD card. RT-11 recognized the second drive as DU1: with no problem. So, I tried to copy a single file (PIP.SAV) from DU0: to DU1: and after 5 minutes it still didn't complete the copy. The CPU didn't HALT, and there was occasional activity on the SCSI2SD. Not sure what's going on, but clearly operations between disk units isn't working properly, which is possibly what was happening with the init command. One drive is good for now I guess :)

I need to locate a copy of a file transfer program so I can more easily get files into and out of the RT-11 environment without having to read/write SD images...maybe kermit or xmodem. If anyone has tried this, I'd be interested in learning about it.

Thanks again!
 
Last edited:
First check the mapping of the DU Handler. This handler is "munged" to allow it access different MSCP drives, controllers and partitions The setting is stored in the handler so it is restored on reboot. It should resemble:

.sh dev:du


Device Status CSR Vector(s)
------ ------ --- ---------
DU Resident 172150 154


DU0: is set PORT = 0, UNIT = 0, PART = 0
DU1: is set PORT = 0, UNIT = 1, PART = 0

Where -
Unit 0 = SCSI ID 0
Unit 1 = SCSI ID 1

Port 0 is the first MSCP Controller



Kermit can be found here http://www.columbia.edu/kermit/pdp11.html


 
Hi Rich,

Something for your consideration. Rather than break up microSD card into separate SCSI Units for RT11 via the UC07, you could just create separate partitions in one large drive. The type of drive that UC07 presents (e.g. RA81, RA92, RD54) is just a label to RT11. It really doesn't define or dictate the space allocated for the drive. The typical RT11 DU handler will just take whatever raw disk space the UC07 presents.

So I generally use a 2GB microSD card and give all the space to one SCSI ID with an RA92 or RA81 type. Then the DU handler maps a 65536 block (~33 Mbytes) to a DU Unit (see previous note). I typically leave partition 0 as the boot drive and map it to DU0: The rest are mapped and unmapped as I need. You can get up to 7 additional RT11 volume partitions at any one time. You can still DD the contents of a partition into or around in an image file or directly to an SD card. Most DU handlers can access up to 256 partitions, giving you up to 8GB per SD card.

Somewhere I have a crude bit of C code to do a simple inspect of a RT11 partition in a image file I can send you (OS X or Linux). For RT11 grab the DUSTAT program off the web.

Regards,
Jerry
 
Jerry --

I think I saw instructions somewhere how to do that. I was just trying to separate "boot" from "user" so to speak. Thanks again!

Rich
 
Going back to the Kermit question...I read somewhere that the RT11 version requires that the LTC be enabled. But, I have it disabled so that the UC07 works. I will definitely try re-enabling it. If that doesn't work, is there an XMODEM version for RT-11 or some way that doesn't require the LTC?
 
You must log in or register to reply here.
Back
Top