• Please review our updated Terms and Rules here

RSX-11M+ sysgen question

It depends...

The working tables show that certain devices have ‘fixed’ addresses and vectors whereas others have ‘floating’ addresses and vectors.

Sticking with the DEC ‘standards’ mean that the general SYSGEN questions have the default answers already setup - meaning that you don’t have to spend a long time entering the details.

From memory, there was a ‘standard’ address and vector for a second RQDX3 controller.

Even if you don’t stick with the DEC Standard, look at what options you have for physically configuring the card (at the hardware level). You can pretty much setup anything like this - providing the card register addresses don’t overlap and are unique.

Dave
 
Ok - I've tried a few variations, and, I'm not able to get sysgen to work properly.

I ended up swapping the CSR of my controllers with switches/jumpers. I put the SCSI controller at 172150, 154 and the RQDX3 at 1760334, 300.

I set almost everything in the sysgen to the default choice. The biggest difference is around the disk controllers:

Two MSCP controllers, 5 total physical drives.

On the CQD-440, two drives, which I've specified as physical unit 0 and 1
On the RQDX3, three drives, which I've specified as physical unit 0, 1, 2

The RQDX3 is set for first LUN at 4.

From the ROM startup dialog mode, I can boot successfully from any drive, referring to the drives as DU0, DU1, and DU4, DU5, and DU6 (e.g., BOOT DU5, no other parameters are needed).

However, after sysgen on DU0, when I try to boot DU0 I get a crash on boot.

So, I have to copy over the system from DU1 (SD card) to the physical SCSI disk and try again.

Code:
                     Testing in progress - Please wait

                             1 2 3 4 5 6 7 8 9

                              Starting system




RSX-11M-PLUS V4.6  BL87   2044.KW  System:"RSXMPL"
 >RED DU:=SY: >RED DU:=LB: >RED DU:=SP: >MOU DU0:"RSX11MPBL87"

.....
.....SYSTEM FAULT DETECTED AT PC=044720  FACILITY=000311  ERROR CODE=000207......
.....
.....
.....CRASH -- CONT WITH SCRATCH MEDIA ON MU000
.....
.....
.....
013044
@
 
Did you take a crash dump on MU0:?

Did you look at listings/maps to find out what happened at "PC=044720 FACILITY=000311 ERROR CODE=000207"?
 
Thank you - that definitely seems like the next step. But, beyond my capability.

I think the problem was that I didn't do a BOOT [1,54]RSX11M, and SAV /WB after sysgen. But, it goes out to lunch when I do a SAV (as recommended in the DEC SYSGEN manual):

Code:
>; End of SYSGEN
>;
>TIME
14:40:13 15-MAY-22
>;
>ASN =
>;
>@ <EOF> >BOO DU0:[1,54]


RSX-11M-PLUS V4.6   BL87  
>
TIM 14:41 15-may-2022 >TIM
14:41:10 15-MAY-22 >SAV

I am doing the sysgen on the same disk drive as what I booted from.... but, when I boot from a different device and try to sysgen du0, I quickly get a file not found.

Clearly something is wrong somewhere, but, I think this process is flaky...
 
It has been a long time for me, probably late '80s. It would not surprise me a bit if the SYSGEN procedure only runs correctly on the boot device (which is expected to be a clean distribution kit). There may be hack-arounds for this, but not for the faint of heart.

The virgin system (i.e. one that has been VMR'ed but not SAV'ed) can't be treated the same as a SAV'ed system (IIRC some of the installed task data structures get changed at boot. Maybe disk block numbers to/from file ID numbers?).
 
Last edited:
I'm using the 4.6 from bitsavers. I suspect it's not a virgin system.

When I boot DU1, then set my target to DU0, I quickly get an error:

Code:
>* SU120   Do you want to do a complete SYSGEN? [Y/N D:Y]: 
>;
>INS [3,54]MAC/TASK=MACT0 
INS -- Device not mounted

>INS [3,54]PIP/TASK=PIPT0 
INS -- Device not mounted

>INS [3,54]LBR/TASK=LBRT0 
INS -- Device not mounted

>INS [3,54]TKB/TASK=TKBT0 
INS -- Device not mounted

>INS [3,54]VMR/TASK=VMRT0 
INS -- Device not mounted
>;
>;
>;======================================================
>;  Choosing Executive Options      17-MAY-22 at 16:47
>;======================================================
>;
>;

AT.T0  -- File not open
..ENABLE DATA #0 >
 
Ok - I tried to get a different distribution of RSX-11M+ 4.6 from trailing edge, and, following the instructions here


I created an MSCP disk. When it came to the copy from tape to disk, I substituted:

BRU>/REW/INIT/BAC:DBSYS MS0: DB0:

with

BRU>/REW/INIT/BAC:DUSYS MS0: DU0:

Then, I dd'd the simh disk image to my SD card and plopped it into my SCSI2SD adapter. No joy.

Code:
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: BOOT DU1:


Trying DU1

Starting system from DU1
.
  RSX-11M V4.6 BL56   124.K MAPPED (BASELINE)
.
.
>RED DU1:=SY:
.
.
>RED DU1:=LB:
.
.
>MOU DU1:RSXM56
.
MOU - I/O error on device
.
.
.01:00:11  *** DU1: -- Dismount complete
.
.
IE.RER - file processor read error
.


Does anyone see my mistake, or, is there a better distribution to start from?
 
Three possibilities that I can think about (offhand).

1. DUSYS is designed (from what I have read on the site you linked to) to a specific sub-set of RAxx devices. In your SIMH environment (when you 'created' the disk), did you create one of the compatible disk types or not?

2. Is there something that you have to do with your SCSI setup to ensure that your dd'd image of the disk really looks like one of those disks to the PDP11 that is trying to bootstrap it.

3. I suppose there is the option that your SCSI setup itself doesn't actually work correctly?

Dave
 
Thank you for looking into this, Dave!

On your advice, I've confirmed that DU is the device abbreviation for the RA, but also the RC, RX, and RD disk drives. DUSYS would make sense as the appropriate driver. However, a slight difference. simh is accessing the "disk" through an emulated RQDX3. On the physical machine, it's actually a CQD SCSI adapter talking to a SCSI2SD device. That said, they're both MSCP devices, so it should work?

My simh disk is a 4GB dsk file that I attach as a device under the RQ controller. RQ is the emulation of the RQDX3.

Specifically, my config is:

SET RA enable
SET -L RQ0 RAUSER=8385867
ATTACH RQ0 st15230.dsk

How I got here was because I couldn't successfully sysgen the distribution I had. I was able to get one other distribution of RSX-11 moved to the physical hard disk.

I did this on the mac: dd if=rsx11mpmf.dsk of=/dev/disk4 bs=512

Then I booted from this SCSI2SD disk (DU1), which started RSX, and then I copied it over to the hard disk.

MOUNT/FOR DU0:
INS $BRU
BRU/INI/MOU DU1: DU0:

So, I don't think it's a problem with my SCSI setup.

Maybe I'm using a corrupted RSX11M+4.6?

ftp://ftp.trailing-edge.com/pub/rsxdists/rsx11m46.zip
 
We'll, I have just ordered a SCSI2SD card for my PDP-11/73, so I will be following in your footsteps shortly!

Dave
 
I just reread your post again now I have just woken up a bit more...

I am now a little confused...

You state in post #29 that you were able to boot from DU1 and RSX started, but the code extract in post #27 shows that booting from DU1 did not work...

Dave
 
That's correct - let me explain. I was able to boot from the SCSI2SD device using a different distribution.

The one that was able to boot was also retrieved from ftp://ftp.trailing-edge.com/pub/rsxdists/rsx11mplus_4_6_bl87.dsk

It unzips to a 159MB file (RD54?). It was referenced on Joerg Hoppe's web site here:




But, I couldn't successfully perform a sysgen. Actually I performed the sysgen, but the machine didn't reboot properly. Now that I've done about 30 sysgens, I probably should read Jeorg's "Appendix F" example more clearly!


Specifically, I don't think I've ever used exactly the boot command he issued post-sysgen.

Code:
>; End of SYSGEN
>;
>TIME
12:41:36 5-JAN-14
>;
>ASN =
>;
>@ <EOF>
>DIR [1,54]RSX11M.*;*


Directory DU0:[1,54]
5-JAN-14 12:43

RSX11M.SYS;1        1026.   C  03-NOV-99 18:01
RSX11M.TSK;1        130.    C  03-NOV-99 17:54
RSX11M.STB;1        37.        03-NOV-99 17:55
RSX11M.SYS;2        1026.   C  05-JAN-14 12:41
RSX11M.TSK;2        130.    C  05-JAN-14 12:41
RSX11M.STB;2        38.        05-JAN-14 12:41

Total of 2387./2387. blocks in 6. files

>BOOT [1,54]RSX11M.SYS
XDT: 87

XDT>G
RSX-11M-PLUS V4.6   BL87

>SAV /WB

I think I'll switch back to Joerg's distribution. I had more success with it.
 
RSX-11M V4.6 BL56 124.K MAPPED (BASELINE)

RSX-11M v4.6 is not RSX-11M-PLUS v4.6

RSX-11M-Plus 4.6 Distribution kit from bitsaver

Code:
RSX-11M/RSX-11M-PLUS Standalone Configuration and Disk Sizing Program

Valid switches are:
        /CSR=nnnnnn to change the default device CSR
        /VEC=nnn to change the default device vector
        /FOR=n to change the default magtape formatter number
        /DEV to list all default device CSR and vectors


Enter first device: DU0:

Enter second device: MU0:

Hit RETURN and enter date and time as 'TIM HH:MM MM/DD/YY'

>run bad
>
BAD>du:/li
BAD -- DU0: Total bad blocks= 0.
BAD>^Z
run bru
>
BRU>/ini/ver mu: du:
BRU - Starting Tape 1 on MU0:

BRU - End of Tape 1 on MU0:

BRU - Starting verify pass Tape 1 on MU0:

BRU - End of Tape 1 on MU0:

BRU - Completed

BRU>^Z



RSX-11M-PLUS V4.6  BL87   2044.KW  System:"Baseline"
>RED DU:=SY:
>RED DU:=LB:
>RED DU:=SP:
>MOU DU0:"RSX11MPBL87"
>@[2,54]BASTART.CMD
>SET /CRASHDEV=MM0:
SET -- Crash device MM000: has been successfully loaded
>;
>;
>;      RSX-11M-PLUS V4.6 Distribution Kit
>;
>;      This is the baseline system of the RSX-11M-PLUS V4.6
>;      distribution kit. This system contains an assortment of
>;      devices and may in fact be of some use on your target
>;      system. The main purpose of the baseline system, however,
>;      is to provide a working system environment which may be
>;      used to generate a custom-tailored operating system for
>;      your target hardware. We will now provide instructions
>;      to guide you through the startup procedure.
>;
>* Please enter time and date (Default:19-MAY-2022 18:27) [S]: ^Z
>@ <EOF>
>
 
Immediately after the full generation has been completed (with the assembly and build of the system, drivers and system tasks), as well as the preparation of the system image, you have a virgin system. When you boot virgin system, you will get the standard system prompt and that is all.

The SAV program prepares such a system for use. At a minimum, it saves the current contents of memory back to the image file of the booted system and changes the starting point in such a way that control returns to SAV immediately after booting. It is the SAV program that, when such a system is loaded, executes the commands RED, MOU and launches the starting command file. If the CAB program was started without the /WB key, then it DOES NOT OVERWRITE the boot block and this system CANNOT be booted by hardware. It can only be loaded from another loaded RSX system with the BOO command. After the system has been saved by the SAV program, it ceases to be virgin.

If the SAV program was launched with the /WB switch, then, in addition to the listed actions, it also writes a new bootloader, configuring it to boot this particular system in hardware.

For hardware boot, the system MUST BE saved by the SAV program and primary bootloader MUST BE configured to boot THIS system.

Since no commands are automatically executed when booting a virgin system, everything seems to work, but if you try to issue a MOU command to mount a boot drive, you will almost certainly get the same error and crash the system.

It seems to me that there is some kind of problem when hardware bootloader set the address of the controller's CSR and the device number to the primary bootloader in your case, but to be sure, you need to create a boot image on the SD card with a hacked bootloader, so that there would be an exit to the hardware ODT and the ability to see content of registers R0 and R1.
 
You guys are GREAT! Finally, SUCCESS!

I think the problem was exactly that - I didn't boot the unsaved system and SAV /WB after the sysgen.

So, to recap, I have two MSCP controllers, a SCSI controller (CQD-440/TM) and an MFM controller (RQDX3), and thought this was causing a problem during sysgen. It wasn't - I just wasn't following the sysgen instructions properly!

Code:
1. I moved my SCSI controller to the primary MSCP CSR/vector: 172150 / 154
2. I set the RQDX3 to secondary (1760334 / 300)

This controller swap likely had no impact on my problem.

3. I copied a fresh baseline RSX-11MPlus 4.6 to my SCSI disk drive
    a. Copied RSX11MPBL87.dsk from bitsavers to an SD partition with my Mac  (sudo dd if=RSX11MPBL87.dsk of=/dev/disk2 bs=512)
    b. booted SD card with the SCSI2SD adapter  (boot DU1 from dialog)
    c.
          MOUNT/FOR DU0:
          INS $BRU
          BRU/INI/MOU DU1: DU0:
4. Rebooted PDP-11 and now booted DU0  (boot du0: )
5. After startup, @sysgen with target disk = du0:
     - I would get an error if I tried to boot du1 and sysgen to du0
6. During sysgen, selected most defaults.
     - Specified 2 MSCP controllers
     - Did not rebuild system files.
     - Did not save old system
7. After sysgen
     a. BOO DU0:[1,54]
     b. TIM  14:52 30-MAY-2022
     c. SAV /WB
     d. then, after the system completed startup, I shut it down (RUN $SHUTUP), and rebooted
 
Last edited:
So the RTFM part worked - it was just the putting into practice that was deficient :)...

You have probably learnt a lot in the process though!

Well done!

Dave
 
oh my - you ain't kidding!!

Also, to get the drives working properly, I needed to set the physical unit number in sysgen like this:

0 - Seagate disk drive (controller A)
1 - SCSI2SD adapter (A)
4 - ST251-1 (B)
5 - RX50-A (B)
6 - RX50-B (B)

The trick there was that the RQDX3 controller was set to have the LUN start at 4. So, sysgen needed to have the disks specified the same way. (previously I tried A0, A1, then B0, B1, B2, but that didn't work. I also tried A0,A1,B2,B3,B4..)

Incidentally, the bootstrap ROM dialog mode also refers to them as:
DU0
DU1

DU4
DU5
DU6
 
Back
Top