Re: PDP-11 disk image question

[Glen Slick via cctalk]

After spending way to much time on this today, I verified that at
least on the CMD CQD Q-Bus SCSI controller versions that I have if I
wanted the CMD CQD controller to report an MSCP disk size of exactly
891072 blocks to match the SIMH emulated RA81 disk size, I had to soft
resize the capacity of the SCSI hard drive to be 2 blocks larger, i.e.
a capacity of 891074 blocks. This is with the CMD CQD controller reset
to the default configuration with the 'Z' configuration option. The
behavior of Q-Bus SCSI controllers from other vendors will be
different.

After doing that I verified that VMS on a VAX CPU, and also the
2.11BSD standalone disklabel on a PDP-11 CPU saw an MSCP disk size of
891072 blocks with the SCSI disk size of 891074 blocks attached to the
CMD CQD Q-Bus SCSI controller.

I then installed RSTS/E 10.1 on a SIMH RA81 and then did the
equivalent of a dd from the SIMH RA81 disk image file of size
456,228,352 bytes to the SCSI hard drive of capacity 891074 blocks.
Then the PDP-11 CPU booted RSTS/E 10.1 from SCSI hard drive attached
to the CMD CQD Q-Bus SCSI controller.

Sorry for the extra long message. Gory details below. If I don't add
the details now I'll forget all the details myself tomorrow.

Resizing the 9GB SCSI hard drive down to a capacity of 891074 blocks
on a Windows PC using sg3_utils-1.37 (I seem to recall that previously
I tried this with a newer version of sg3_utils and something didn't
work right):

C:\sg3_utils-1.37>sg_scan
PD0 [C] HDS728040PLAT20  PF1OA21B
PD1 IBM   DDRS-39130D   DC1B
CDROM0  [Z] TEAC CD-224E  1.7A

C:\sg3_utils-1.37>sg_inq pd1
standard INQUIRY:
  PQual=0  Device_type=0  RMB=0  version=0x02  [SCSI-2]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  [BQue=0]
  EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=1  Sync=1  Linked=1  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x0  QAS=0  IUS=0]
length=164 (0xa4)   Peripheral device type: disk
 Vendor identification: IBM
 Product identification: DDRS-39130D
 Product revision level: DC1B
 Unit serial number: RE1X3474

C:\sg3_utils-1.37>sg_readcap pd1
Read Capacity results:
   Last logical block address=1784 (0x1105e8f), Number of blocks=1785
   Logical block length=512 bytes
Hence:
   Device size: 913920 bytes, 8715.82 MiB, 9.1392 GB

C:\sg3_utils-1.37>sg_format --count=891074 --resize --verbose pd1
inquiry cdb: 12 00 00 00 24 00
IBM   DDRS-39130D   DC1B   peripheral_type: disk [0x0]
  PROTECT=0
mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00
mode sense (10): pass-through requested 252 bytes but got 28 bytes
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=1785 [0x1105e90]
  Block size=512 [0x200]
mode select (10) cdb: 55 11 00 00 00 00 00 00 1c 00
Resize operation seems to have been successful

C:\sg3_utils-1.37>sg_readcap pd1
Read Capacity results:
   Last logical block address=891073 (0xd98c1), Number of blocks=891074
   Logical block length=512 bytes
Hence:
   Device size: 456229888 bytes, 435.095 MiB, 0.45623 GB

Verifying that the SCSI hard drive with a capacity of 891074 blocks
attached to the CMD CQD Q-Bus SCSI controller is seen as a drive with
a capacity of 891072 blocks on VMS on a VAX CPU:

$ MOUNT /FOREIGN BA215$DUA0:
%MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0:
$ SHOW DEVICE /FULL BA215$DUA0:

Disk BA215$DUA0:, device type RA81, is online, allocated, deallocate on
dismount, mounted foreign, file-oriented device, shareable, available to
cluster, error logging is enabled.

Error count0Operations completed  4
Owner process   "SYSTEM"Owner UIC  [SYSTEM]
Owner process ID0214Dev ProtS:RWPL,O:RWPL,G:R,W
Reference count2Default buffer size 512
Total blocks  891072Sectors per track   217
Total cylinders  411Tracks per cylinder  10

Volume label"OVMSVAXSYS"Relative volume number0
Cluster size   0Transaction count 1
Free blocks0Maximum files allowed 0
Extend quantity0Mount count   1
Mount status ProcessACP process name ""

  Volume Status:  Unknown ACP type.

Verifying that the SCSI hard drive with a capacity of 891074 blocks
attached to the CMD CQD Q-Bus SCSI controller is seen as a drive with
a capacity of 891072 blocks on the 2.11BSD standalone disklabel on a
PDP-11 CPU (ignore the "45Boot" which is a 2.11BSD bug that is fixed
in a newer patch to correctly report "53Boot" on an 11/53 CPU).

9 8 7 6 5 4 3 2 1

Commands are Help, Boot, List, Map, Test and Wrap.
Type a command then press 

Re: PDP-11 disk image question

[Jerry Weiss via cctalk]

On 2/20/19 1:25 PM, Glen Slick via cctalk wrote:

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk
 wrote:

Theoretically, the SIMH emulated RA81 and the CMD emulated real
disk RA81 should be the same size because they are both supposed
to be RA81's.

I spent the time to get set up and verified that this assumption is
not correct. The CMD CQD MSCP SCSI controller firmware RA device type
feature appears to only change the reported MSCP media name string,
and has no effect on the reported MSCP size and geometry information.

I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00).
As far as I know the CQD-420 and the CQD-220A (but not the original
CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive
with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive.
I used sg3-utils / sg_format to soft resize the drive to exactly 2GB
in capacity, 2,147,483,648 bytes, 4,194,304 blocks.

..
Paul K's explanation and Glen's example matches my own experience in 
this area. I don't have a CMD controller, but I move images between SIMH 
and both Emulex UC07 and Dilog SQ706A MSCP/SCSI Controllers. I've used 
RT11, XXDP, RSX11M+ and VAX VMS on both physical hard drives and SCSI2SD 
emulated disks.


The physical SCSI drives I use have SCSI reassign capability. This 
allows the controller/drive to manage media defects.  This is 
transparent to any of the OS'es. The controller presents the disk simply 
as a continuous logical disk of disk blocks and the geometry has no 
effect.    Space reserved for bad block replacement is not visible to 
the OS.


I make sure the number of logical blocks is maintained exactly as I move 
the images back and forth between SIMH and physical Machines. The disk 
type RA90, RA81, etc never makes a difference.  The MSCP controllers 
read the media size directly and report the disk logical capacity to VMS 
Drivers.


If I move an VMS ODS-2 SIMH disk image to a larger SCSI disk drive then 
problems will occur.  For ODS type volumes, my understanding is that 
bitmap.sys file won't have room to manage the extra space.   I also try 
to avoid edge cases for disk sizing that involve powers of two - e.g. 
2**32.   In my general experience, I have found boundary check problems 
in different situations (especially non-Digital).



Disk NASTY$DKA100:, device type DEC RA92, is online, mounted, file-oriented
    device, shareable, error logging is enabled.

    Error count    0    Operations 
completed   2653
    Owner process ""    Owner UIC  
[SYSTEM]

    Owner process ID        Dev Prot S:RWPL,O:RWPL,G:R,W
    Reference count   48    Default buffer 
size 512
    Total blocks 7603200    Sectors per 
track    63
    Total cylinders  474    Tracks per 
cylinder 255


    Volume label  "VAXVMS73"    Relative volume 
number    0
    Cluster size   9    Transaction 
count   155
    Free blocks  3072564    Maximum files 
allowed    419336
    Extend quantity    5    Mount 
count   1

    Mount status  System    Cache name "_NASTY$DKA100:XQPCACHE"
    Extent cache size 64    Maximum blocks in extent 
cache   307256
    File ID cache size    64    Blocks currently in extent 
cache 307161
    Quota cache size   0    Maximum buffers in FCP 
cache    557
    Volume owner UIC    [SYSTEM]    Vol Prot 
S:RWCD,O:RWCD,G:RWCD,W:RWCD


  Volume Status:  ODS-2, subject to mount verification, protected 
subsystems

  enabled, file high-water marking, write-through caching enabled.


I don't see a discrepancy on SCSI2SD V5 cards between configuration size 
and VMS reported block,  The size used is recorded on the SCSI2SD V5 
card.  The SCSI2SD V6 adapters store the drive configuration on the last 
block of the microSD and I believe reported capacity is reduced by 1.   
Perhaps the CMD is doing similar to allow the media to be interchanged 
between controllers.


  Jerry

Re: PDP-11 disk image question

[Glen Slick via cctalk]

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk
 wrote:
>
> Theoretically, the SIMH emulated RA81 and the CMD emulated real
> disk RA81 should be the same size because they are both supposed
> to be RA81's.

I spent the time to get set up and verified that this assumption is
not correct. The CMD CQD MSCP SCSI controller firmware RA device type
feature appears to only change the reported MSCP media name string,
and has no effect on the reported MSCP size and geometry information.

I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00).
As far as I know the CQD-420 and the CQD-220A (but not the original
CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive
with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive.
I used sg3-utils / sg_format to soft resize the drive to exactly 2GB
in capacity, 2,147,483,648 bytes, 4,194,304 blocks.

After using the "Z = Reset Controller" configuration option to reset
the CQD-420/TM firmware to its default state this was the
configuration reported by the firmware:

SCANNING SCSI DEVICES ATTACHED ...

DEV0: DU0  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV1: DU1  SCSI ID 1  LUN 0  OFFLINE
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV2: DU2  SCSI ID 2  LUN 0  OFFLINE
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV3: DU3  SCSI ID 3  LUN 0  OFFLINE
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV4: MU0  SCSI ID 4  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV5: MU1  SCSI ID 5  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV6: MU2  SCSI ID 6  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV7  SCSI ID 7  HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF,
  Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA dev= DEF,
  Rsv/Rls Option ON,MSCP credit = 16,sync rate = 04 MB/sec,
  RSX FP OFF,Sel Timeout = 250 ms
  (PMR=Prevent Medium Removal   WWV=Write W/Verify)

Then a KA660 VAX console sees the device like this:

>>>SHOW DEV
UQSSP Disk Controller 0 (772150)
-DUA0 (RA90)

UQSSP Tape Controller 0 (774500)

Then VMS booted on the KA660 VAX sees the device like this:

$ MOUNT /FOREIGN BA215$DUA0:
%MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0:
$ SHOW DEVICE /FULL BA215$DUA0:

Disk BA215$DUA0:, device type RA90, is online, allocated, deallocate on
dismount, mounted foreign, file-oriented device, shareable, available to
cluster, error logging is enabled.

Error count0Operations completed  4
Owner process   "SYSTEM"Owner UIC  [SYSTEM]
Owner process ID0214Dev ProtS:RWPL,O:RWPL,G:R,W
Reference count2Default buffer size 512
Total blocks 4194302Sectors per track   217
Total cylinders 1933Tracks per cylinder  10

Volume label"OVMSVAXSYS"Relative volume number0
Cluster size   0Transaction count 1
Free blocks0Maximum files allowed 0
Extend quantity0Mount count   1
Mount status ProcessACP process name ""

  Volume Status:  Unknown ACP type.

One question here is why does VMS see 4194302 blocks when a SCSI Read
Capacity command of the drive reports 4194304 blocks? Is the CMD
CQD-420/TM firmware reserving a block or two?

Anyway, I then tried to recreate the configuration of the original
post as I understand it, partitioning the one physical SCSI drive into
four logical MSCP device units, and turning on the RA81 type feature
for those four MSCP device units.

Note that now DEV0: DU0 through DEV3: DU3 all map the the same SCSI ID
0, they all have the RA feature set to ON, and the RA dev type is set
to 81.

SCANNING SCSI DEVICES ATTACHED ...

DEV0: DU0  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV1: DU1  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV2: DU2  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV3: DU3  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV4: MU0  SCSI ID 4  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV5: MU1  SCSI ID 5  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV6: MU2  SCSI ID 6  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV7  SCSI ID 7  HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF,
  Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA 

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 20, 2019, at 2:09 PM, Paul Koning via cctalk  
> wrote:
> 
> ...
> No, that's not what the symptoms say.  If you were dealing with geometry 
> confusion, you'd fail much earlier.  For example, if you were to take a RSTS 
> system built on an RP06, and image-copied it to an RM05, it would fit fine 
> (the RM05 is much bigger).  And since the "device cluster size" is 9 for 
> both, 

Typo. 8, not 9.  DCS is a power of 2, the smallest value such that device size 
/ DCS is < 65536.

paul

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 20, 2019, at 1:43 PM, Charles Anthony via cctalk 
>  wrote:
> 
> On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk 
> wrote:
> 
>> On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
>>  wrote:
>>> 
>>> However, in the original posters case, the SIMH disk image is being
>> copied
>>> to the RA81 drive without the benefit of the MSCP controller (if I
>>> understand correctly). This would lead to track misalignment and could
>>> result in the observed behavior.
>> 
>> How could you possibly write to a real RA81 drive without going
>> through a real KDA50 or UDA50 MSCP controller? Nothing like that is
>> happening in the original post. Just the disk size was chosen to be
>> that of an RA81, and the issue is to exactly match the emulated disk
>> size to that configured by the hardware, which is an MSCP SCSI
>> controller and drive in this case.
>> 
> 
> 
> Re-reading the original post, it it not clear to me how the disk write was
> accomplished; I am not familiar with the mentioned hardware. If the data
> was written to the RA81 with a controller that correctly did the spare
> sector mapping, then my spare sector hypothesis is wrong.

Your confusion stems from the fact you think of "spare sector" as something 
that is visible.  It is not.  Programs can only deal with program-visible 
properties of devices.  For MSCP disks, which is what we have here, the only 
program visible addressing is LBA addressing.  There IS no geometry from the 
program point of view.  

"spare sectors" are an internal detail in the MSCP controller that allows it to 
deliver an error-free device.  It has no relevance to programmers and it 
probably shouldn't have been mentioned in the documentation in the first place.

> The reported symptoms sound like a disk geometry issue; the data passes
> through several systems on the way to RSTS, and it seems likely to me that
> one of the steps is damaging the data.

No, that's not what the symptoms say.  If you were dealing with geometry 
confusion, you'd fail much earlier.  For example, if you were to take a RSTS 
system built on an RP06, and image-copied it to an RM05, it would fit fine (the 
RM05 is much bigger).  And since the "device cluster size" is 9 for both, the 
file system would even be basically valid (apart probably from a too-small 
storage bitmap, but that wouldn't prevent reading data).

However, the RM05 wouldn't boot at all, because the boot loader has been told 
it's on an RP06 and it would use the RP06 numbers for converting LBA to 
cylinder, track, sector values.  Since the sectors/track differs (22 vs. 32) 
all the boot loader reads would go to the wrong place.  It would be loading 
utter nonsense into memory.

In the original problem, the boot loader worked fine.  It loaded all of INIT 
successfully (because INIT got far enough to discover the disks and attempt to 
find INIT.SYS, and it did so without crashing).  You wouldn't get anywhere 
close to that point if you had a geometry issue.

paul

Re: PDP-11 disk image question

[Charles Anthony via cctalk]

On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk 
wrote:

> On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
>  wrote:
> >
> > However, in the original posters case, the SIMH disk image is being
> copied
> > to the RA81 drive without the benefit of the MSCP controller (if I
> > understand correctly). This would lead to track misalignment and could
> > result in the observed behavior.
>
> How could you possibly write to a real RA81 drive without going
> through a real KDA50 or UDA50 MSCP controller? Nothing like that is
> happening in the original post. Just the disk size was chosen to be
> that of an RA81, and the issue is to exactly match the emulated disk
> size to that configured by the hardware, which is an MSCP SCSI
> controller and drive in this case.
>


Re-reading the original post, it it not clear to me how the disk write was
accomplished; I am not familiar with the mentioned hardware. If the data
was written to the RA81 with a controller that correctly did the spare
sector mapping, then my spare sector hypothesis is wrong.

The reported symptoms sound like a disk geometry issue; the data passes
through several systems on the way to RSTS, and it seems likely to me that
one of the steps is damaging the data.

As I lack experience with or access to the specific hardware, I am
speculating about the exact failure mode. I do however believe that it is
highly likely that disk geometry is the root of the problem. Having no no
further specific ideas about the failure mode, I will shut up now.

-- Charles

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 20, 2019, at 11:57 AM, Charles Anthony  
> wrote:
> 
> 
> 
> On Wed, Feb 20, 2019 at 5:38 AM Paul Koning  wrote:
> 
> 
> You're misinterpreting "spare".  MSCP exposes the user address space as 
> contiguous LBAs, for which it uses 51 sectors per track.  The spare sector is 
> used to do bad sector replacement.  That is invisible to users, it doesn't 
> affect the LBA addressing.  dd, like any other host-resident code, sees the 
> user address space.  It will copy MSCP devices correctly.
> 
>  
> 
> Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the 
> disk through MSCP in the case of the *hardware*. 
> 
> However, in the original posters case, the SIMH disk image is being copied to 
> the RA81 drive without the benefit of the MSCP controller (if I understand 
> correctly). This would lead to track misalignment and could result in the 
> observed behavior.

No.  The original case isn't an actual RA81 at all, it's a non-DEC device that 
emulates an RA81.  Emulation means acting like an RA81 from the program point 
of view, which means as seen via MSCP.  There is no such thing as an RA81 
"without... MSCP controller".

> The SIMH MSCP emulation is not doing the spare sector correctly; it is not 
> including the spare sectors on the RA81 disk image.

It operates correctly because SIMH emulates the program point of view, so it 
exposes the user LBA space, not the internal structure.  For the same reason, 
it doesn't emulate sector headers, ECC codes, or servo fields.  None of that is 
visible to the software.

paul

Re: PDP-11 disk image question

[Glen Slick via cctalk]

On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
 wrote:
>
> However, in the original posters case, the SIMH disk image is being copied
> to the RA81 drive without the benefit of the MSCP controller (if I
> understand correctly). This would lead to track misalignment and could
> result in the observed behavior.

How could you possibly write to a real RA81 drive without going
through a real KDA50 or UDA50 MSCP controller? Nothing like that is
happening in the original post. Just the disk size was chosen to be
that of an RA81, and the issue is to exactly match the emulated disk
size to that configured by the hardware, which is an MSCP SCSI
controller and drive in this case.

Re: PDP-11 disk image question

[Charles Anthony via cctalk]

On Wed, Feb 20, 2019 at 5:38 AM Paul Koning  wrote:

>
>
> You're misinterpreting "spare".  MSCP exposes the user address space as
> contiguous LBAs, for which it uses 51 sectors per track.  The spare sector
> is used to do bad sector replacement.  That is invisible to users, it
> doesn't affect the LBA addressing.  dd, like any other host-resident code,
> sees the user address space.  It will copy MSCP devices correctly.
>
>


Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the
disk through MSCP in the case of the *hardware*.

However, in the original posters case, the SIMH disk image is being copied
to the RA81 drive without the benefit of the MSCP controller (if I
understand correctly). This would lead to track misalignment and could
result in the observed behavior.

The SIMH MSCP emulation is not doing the spare sector correctly; it is not
including the spare sectors on the RA81 disk image.

-- Charles

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 19, 2019, at 11:55 PM, Glen Slick via cctalk  
> wrote:
> 
> On Sat, Feb 16, 2019 at 1:20 PM Bill Gunshannon via cctalk
>  wrote:
>> 
>> I have a CQD=220A/MT configured for 6 disks and one tape.
>> As for disk types, you can toggle RA ON or OFF on each drive.
>> You can specify one RA type that will be in effect for any
>> disk with RA ON.  Types are: RA70, RA80, RA81, RA82, RA90 and RA92.
> 
> Looking at this further, I don't believe the CMD CQD RA type option
> does what you think it does. I don't believe it has any effect on the
> reported geometry of the MSCP unit, I believe it only changes the
> reported type name of the MSCP unit.

So this might be relevant.  If the reported size is sufficiently different, 
things will break.  

For MSCP, RSTS cares about the device size (LBA count).  It pays no attention 
to reported "geometry".  It displays the reported device type string (in INIT 
"Hardware List" option) but it doesn't care about what those are.  If a 
gigabyte disk claims it's an RX50 (or an RX98), RSTS will happily display that 
string without any objections.

paul

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 19, 2019, at 10:26 PM, Charles Anthony  
> wrote:
> 
> 
> 
> On Tue, Feb 19, 2019 at 10:14 AM Paul Koning  wrote:
> 
> ...
>> So indeed the correct sector count is 51 (the other one is a spare, a 
>> technique used by DEC as far back as the RM80).
>> 
> 
> I am concerned that the spare is the issue. If the track has 52 sectors, and 
> one is reserved as a spare, is that spare included in the LBA calculation? If 
> it is, then SIMH is wrong; the first sector of the second track written in 
> the spare sector, throwing all of the remaining data out of alignment, with 
> the symptom of RSTS booting but not being able to find INIT.SYS.
> 
> If the spare sector exists and SIMH is not allocation space for it, then the 
> disk image will not copy correctly with 'dd'. (However, dd might be coereced 
> into doing the right thing with 'dd if=... of=... ibs=26112 obs=26624'; 
> reading 512*51 byte records (a SIMH track) and writing 512*52 byte records (a 
> RA81 h/w track)).
> 
> -- Charles

You're misinterpreting "spare".  MSCP exposes the user address space as 
contiguous LBAs, for which it uses 51 sectors per track.  The spare sector is 
used to do bad sector replacement.  That is invisible to users, it doesn't 
affect the LBA addressing.  dd, like any other host-resident code, sees the 
user address space.  It will copy MSCP devices correctly.

paul

Re: PDP-11 disk image question

[Glen Slick via cctalk]

On Sat, Feb 16, 2019 at 1:20 PM Bill Gunshannon via cctalk
 wrote:
>
> I have a CQD=220A/MT configured for 6 disks and one tape.
> As for disk types, you can toggle RA ON or OFF on each drive.
> You can specify one RA type that will be in effect for any
> disk with RA ON.  Types are: RA70, RA80, RA81, RA82, RA90 and RA92.

Looking at this further, I don't believe the CMD CQD RA type option
does what you think it does. I don't believe it has any effect on the
reported geometry of the MSCP unit, I believe it only changes the
reported type name of the MSCP unit.

I need to change the firmware on one of my CMD CQD controllers to a
version of the firmware which has both the RA type specification
option and RA type toggle per unit option to verify the actual
behavior myself.

I tried firmware version REV. B3A-00 on a CQD-220/TM which has an "A =
Report specific media type" option, but not a "1 = Toggle device RA"
option. With that firmware specifying an particular RA type had no
effect on the reported unit geometry.

I have firmware version REV. B2L-00 I can try on a CQD-420/TM which
has both "A = Set the RA number" and "1 = Toggle device RA" options. I
currently have firmware version REV. B2C-00 on my CQD-420/TM which has
neither of those two option.

Regardless of that, there are a couple of options you can try:
(1) Find out the exact unit size that is being reported in your
configuration with your CMD controller and hard drive, and configure
the emulated hard drive unit size to match that.
-or-
(2) Reconfigure the SCSI hard drive independent of the CMD controller
to match the exact unit size of the emulated hard drive. Then use the
SCSI hard drive as a single unit without partitions on the CMD
controller and it should yield the desired result. To reconfigure the
SCSI hard drive you can use sg_format from the sg3_utils to soft
resize the reported capacity of a SCSI hard drive down to a lower
limit. I have done that several times, for example to resize a 9GB
drive down to 1GB in capacity for systems while can't handle drives
larger than 1GB. The sg_format command with the -resize option doesn't
actually format the drive, it just uses some mode page commands to
change the reported drive capacity.

Re: PDP-11 disk image question

[Charles Anthony via cctalk]

On Tue, Feb 19, 2019 at 10:14 AM Paul Koning  wrote:

>
>
> > On Feb 19, 2019, at 11:51 AM, Charles Anthony <
> charles.unix@gmail.com> wrote:
> >
> > ...
> > Presumably SIMH is returning RA81_LBN (891072) as the device size; this
> is calculated based on the 51 sectors/track. If the h/w is returning a size
> based on 52, then there is a mismatch which could be the source of the
> problem. It has been hypothesised that the original problem is related to
> SIMH misreporting the disk size; I was trying to point out a possible
> source of error; does anyone know what size the h/w reports?
> >
> > -- Charles
>
> Some people here probably have an actual drive and can double check.
>
> Meanwhile, I found the "RA60, RA80, and RA81 disk drives" brochure (DEC,
> August 1982) on Archive.org.  It has the details in the back.  Page 36
> shows "User data capacity" and says 51 sectors, 14 tracks, 1248 cylinders
> -- that works out to 891072 sectors which is the number SIMH uses.
>
> So indeed the correct sector count is 51 (the other one is a spare, a
> technique used by DEC as far back as the RM80).
>
>
I am concerned that the spare is the issue. If the track has 52 sectors,
and one is reserved as a spare, is that spare included in the LBA
calculation? If it is, then SIMH is wrong; the first sector of the second
track written in the spare sector, throwing all of the remaining data out
of alignment, with the symptom of RSTS booting but not being able to find
INIT.SYS.

If the spare sector exists and SIMH is not allocation space for it, then
the disk image will not copy correctly with 'dd'. (However, dd might be
coereced into doing the right thing with 'dd if=... of=... ibs=26112
obs=26624'; reading 512*51 byte records (a SIMH track) and writing 512*52
byte records (a RA81 h/w track)).

-- Charles

Re: PDP-11 disk image question

[Glen Slick via cctalk]

On Tue, Feb 19, 2019 at 11:22 AM Bill Gunshannon via cctalk
 wrote:
>
> > I have mostly used CMD CQD-220/TM controllers. As far as I remember
> > they do not have an RA drive emulation option.
>
> I have a 220A/TM and it certainly does.  Pages 4-10 thru 4-15
> of the manual, particularly Configuration Options "A" and "1".

> Not familiar with the 220A/E it's not mentioned in my manual.
> Probably a much newer version.

What version of the CQD-220A manual do you have? Do you only have a
hard copy, or do you have a scan of the manual? If you have a scan of
the manual it would be great to get a copy of it. Currently there
isn't any version of a CQD-220A manual on Bitsavers. I have a scan of
the MAN-00220A-000, Rev. 1.1, December 17, 1993 version of the
CQD-220A/223A manual. The RA drive emulation option must be newer than
1993 as I don't see it in the version of the manual I have.

Also, there are two main versions of the CQD-220, the original
CQD-220, and the newer redesigned CQD-220A version. The 'A' suffix is
an important difference. Each main version has minor versions, which
are are PAL and firmware differences.

The original CQD-220 has 220/M (MSCP only), 220/T (TMSCP only), and
220/TM (both MSCP and TMSCP at the same time) versions. The 220/M and
220/T versions can be converted into a 220/TM version by replacing the
CSR decode PAL and the firmware EPROMs. I know this can be done
because I have done it several times myself. This original version is
all through hole, except for the 53C90A SCSI controller in a PLCC
package. The firmware is contained in two 27C256 EPROMs.

The newer CQD-220A has 220A/TM (both MSCP and TMSCP at the same time)
and 220A/M/T (either MSCP or TMSCP, but not both at the same time)
versions. The boards that I have with CQD-220A/E stickers on them must
be the same thing as a CQD-220A/M/T. This newer redesigned version is
roughly half through hole, and half surface mount, including a large
CMD ASIC. The firmware is contained in two 27C512 EPROMs.

I just looked at the CQD-220/TM firmware images that I have. I must
have the B2A 06/24/94 version installed on my boards. In that version
I don't see any RA strings in the firmware image. In the B3 09/23/94
version I do see RA strings.

CQD-220/TM B3 Firmware 09/23/94:

"List of all supported device media type
0. Default value
1. RA 70
2. RA 80
3. RA 81
4. RA 82
5. RA 90
6. RA 92
7. RC 25"

I'll have to try the B3 Firmware 09/23/94 version on my CQD-220/TM boards.

Anyway, I'll still try to find time to see exactly what MSCP drive
geometry a CQD-220A reports when configured for RA drive emulation.

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

On 2/19/19 12:37 PM, Glen Slick via cctalk wrote:
> On Tue, Feb 19, 2019 at 5:39 AM Bill Gunshannon via cctalk
>  wrote:
>>
>> All sounds like fun, but if the two emulations don't do RA81
>> correctly the information doesn't really do me much good.  I
>> certainly can't change the CQD's idea of what an RA81 is.
>>
> 
> I have mostly used CMD CQD-220/TM controllers. As far as I remember
> they do not have an RA drive emulation option.

I have a 220A/TM and it certainly does.  Pages 4-10 thru 4-15
of the manual, particularly Configuration Options "A" and "1".

> 
> I also have some of the newer CMD CQD-220A/E controllers (the 220A/E
> being Either MSCP or TMSCP but not both at the same time, while the
> 220A/TM can be both MSCP and TMSCP at the same time). I'll see if I
> can find some time today to take a look at the RA drive emulation
> option using a CMD CQD-220A/E controller, and see exactly what it
> reports for MSCP drive geometry.
> 

Not familiar with the 220A/E it's not mentioned in my manual.
Probably a much newer version.

bill

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 19, 2019, at 11:51 AM, Charles Anthony  
> wrote:
> 
> ...
> Presumably SIMH is returning RA81_LBN (891072) as the device size; this is 
> calculated based on the 51 sectors/track. If the h/w is returning a size 
> based on 52, then there is a mismatch which could be the source of the 
> problem. It has been hypothesised that the original problem is related to 
> SIMH misreporting the disk size; I was trying to point out a possible source 
> of error; does anyone know what size the h/w reports?
> 
> -- Charles

Some people here probably have an actual drive and can double check.

Meanwhile, I found the "RA60, RA80, and RA81 disk drives" brochure (DEC, August 
1982) on Archive.org.  It has the details in the back.  Page 36 shows "User 
data capacity" and says 51 sectors, 14 tracks, 1248 cylinders -- that works out 
to 891072 sectors which is the number SIMH uses.

So indeed the correct sector count is 51 (the other one is a spare, a technique 
used by DEC as far back as the RM80).

paul

Re: PDP-11 disk image question

[Glen Slick via cctalk]

On Tue, Feb 19, 2019 at 5:39 AM Bill Gunshannon via cctalk
 wrote:
>
> All sounds like fun, but if the two emulations don't do RA81
> correctly the information doesn't really do me much good.  I
> certainly can't change the CQD's idea of what an RA81 is.
>

I have mostly used CMD CQD-220/TM controllers. As far as I remember
they do not have an RA drive emulation option.

I also have some of the newer CMD CQD-220A/E controllers (the 220A/E
being Either MSCP or TMSCP but not both at the same time, while the
220A/TM can be both MSCP and TMSCP at the same time). I'll see if I
can find some time today to take a look at the RA drive emulation
option using a CMD CQD-220A/E controller, and see exactly what it
reports for MSCP drive geometry.

Re: PDP-11 disk image question

[Charles Anthony via cctalk]

On Tue, Feb 19, 2019 at 6:27 AM Paul Koning  wrote:

>
>
> > On Feb 18, 2019, at 11:22 PM, Charles Anthony via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> >> ...
> > Looking at the SIMH code:
> >
> > /*
> >type sec surfcyl tpg gpc RCT LBNs
> >RA81 51(+1)  14  125814  1   2856891072
> > */
> >
> > #define RA81_SECT   51  /* +1
> spare/track */
> > #define RA81_SURF   14
> > #define RA81_CYL1258/* 0-1247 user */
> > #define RA81_TPGRA81_SURF
> > #define RA81_GPC1
> > #define RA81_XBN2436/* cyl
> 1252-1254? */
> > #define RA81_DBN2436/* cyl
> 1255-1256? */
> > #define RA81_LBN891072  /* 51*14*1248 */
> > #define RA81_RCTS   2856/* cyl
> 1248-1251? */
> > #define RA81_RCTC   1
> > #define RA81_RBN17472   /* 1 *14*1248 */
> >
> > I am presuming that (without actually checking) that these are the
> numbers
> > returned to RSTS when it queries the disk; if these numbers are different
> > then the h/w, then that could be an issue. I am a bit curious about "+1
> > spare/track" - I wonder if the h/w reports 51 or 52?
> >
> > -- Charles
>
> RSTS doesn't care about geometry, though MSCP does return something it
> calls geometry, for optimization purposes.  All RSTS wants to know is the
> device size, in 512-byte blocks.  Whatever the controller returns is what
> it uses.
>
>
Presumably SIMH is returning RA81_LBN (891072) as the device size; this is
calculated based on the 51 sectors/track. If the h/w is returning a size
based on 52, then there is a mismatch which could be the source of the
problem. It has been hypothesised that the original problem is related to
SIMH misreporting the disk size; I was trying to point out a possible
source of error; does anyone know what size the h/w reports?

-- Charles

Re: PDP-11 disk image question

[Warner Losh via cctalk]

On Tue, Feb 19, 2019, 7:24 AM Paul Koning 
>
> > On Feb 18, 2019, at 10:29 PM, Warner Losh via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > On Mon, Feb 18, 2019 at 6:18 PM Bill Gunshannon via cctalk <
> > cctalk@classiccmp.org> wrote:
> >
> >> ...
> >> No, RX50 was a strange DEC format.  RX33 is a 1.2M floppy.
> >
> > The RX50 was a single sided 800 block floppy. The first two tracks had no
> > interleave. The rest has 2:1 interleave, though sometimes physical and
> > other times logical. Strange in some ways, kinda standard in others. But
> > it's still a floppy, and other than size, much like the RX33 with 1/3 the
> > number of blocks.
> >
> > Warner
>
> That's not correct.
>
> RX50 is 80 track, single sided, 10 sectors per track (not the PC-standard
> 9 per track).  All tracks are 2:1 interleaved.  There is a 3 sector skew
> from track to track.  And logical track 0 is physical track 1 (physical
> track 0 is logical track 79).
>

The interleave is logical on the Rainbow. The drive is formatted to 1, 2,
3, 4, 5, 6, 7, 8, 9, 10, however after track 2 they are logically
interlaved by the drivers in Venix, Dos and CP/M. There is no skew there,
except for Venix...  And on the Rainbow, tracks are purely sequential...
Guess that lead me astray for the pdp-11 users...

The MSCP controller does this; on a Pro it's done in the driver.  I've done
> it for RSTS, but it's easy to confirm by reading the source code of DEC
> drivers such as the one in RT-11.
>

I stand corrected. Yet another odd quirk of this quirky media. I recall
from back in the day there are other DECmate quirks...

Warner

>

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 18, 2019, at 11:22 PM, Charles Anthony via cctalk 
>  wrote:
> 
>> ...
> Looking at the SIMH code:
> 
> /*
>type sec surfcyl tpg gpc RCT LBNs
>RA81 51(+1)  14  125814  1   2856891072
> */
> 
> #define RA81_SECT   51  /* +1 spare/track */
> #define RA81_SURF   14
> #define RA81_CYL1258/* 0-1247 user */
> #define RA81_TPGRA81_SURF
> #define RA81_GPC1
> #define RA81_XBN2436/* cyl 1252-1254? */
> #define RA81_DBN2436/* cyl 1255-1256? */
> #define RA81_LBN891072  /* 51*14*1248 */
> #define RA81_RCTS   2856/* cyl 1248-1251? */
> #define RA81_RCTC   1
> #define RA81_RBN17472   /* 1 *14*1248 */
> 
> I am presuming that (without actually checking) that these are the numbers
> returned to RSTS when it queries the disk; if these numbers are different
> then the h/w, then that could be an issue. I am a bit curious about "+1
> spare/track" - I wonder if the h/w reports 51 or 52?
> 
> -- Charles

RSTS doesn't care about geometry, though MSCP does return something it calls 
geometry, for optimization purposes.  All RSTS wants to know is the device 
size, in 512-byte blocks.  Whatever the controller returns is what it uses.

This is why in SIMH you can use "RAUSER" devices with MSCP, any size you like 
up to 8 megablocks.  RSTS doesn't limit you to the sizes of the DEC MSCP 
products, and in fact you won't find any list of those model codes or any of 
their attributes in the RSTS sources.

paul

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 18, 2019, at 10:29 PM, Warner Losh via cctalk  
> wrote:
> 
> On Mon, Feb 18, 2019 at 6:18 PM Bill Gunshannon via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> ...
>> No, RX50 was a strange DEC format.  RX33 is a 1.2M floppy.
> 
> The RX50 was a single sided 800 block floppy. The first two tracks had no
> interleave. The rest has 2:1 interleave, though sometimes physical and
> other times logical. Strange in some ways, kinda standard in others. But
> it's still a floppy, and other than size, much like the RX33 with 1/3 the
> number of blocks.
> 
> Warner

That's not correct.

RX50 is 80 track, single sided, 10 sectors per track (not the PC-standard 9 per 
track).  All tracks are 2:1 interleaved.  There is a 3 sector skew from track 
to track.  And logical track 0 is physical track 1 (physical track 0 is logical 
track 79).

The MSCP controller does this; on a Pro it's done in the driver.  I've done it 
for RSTS, but it's easy to confirm by reading the source code of DEC drivers 
such as the one in RT-11.

paul

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

On 2/18/19 10:59 PM, Glen Slick via cctalk wrote:
> On Mon, Feb 18, 2019 at 5:18 PM Bill Gunshannon via cctalk
>  wrote:
>>
>> Well, all I really have are CQD module which does MSCP and TMSCP
>> over SCSI.
> 
> Do you have any SCSI tape drives? 

Sure.  I have a SCSI 9-track and a 1.4" QIC  (TKZ-10) and even a
SCSI TK50 if I ever get it fixed (but then we know how likely it
is that any of the physical TK50 drives will actually work at this
point in time!!)  But all of these require TMSCP media and the only
one I have ever seen (and actually have in my possession) is TK50.

>I have successfully installed RSTS/E
> 10.1 from install tapes on real PDP-11 hardware using an Exabyte
> EXB-8200 8mm tape drive attached to a CMD CQD-220/TM. The target hard
> drive for the installation was also attached to the CMD CQD-220/TM.
> That is always one route you could try.

Yes, if I could get a TMSCP Install Kit on a 9-track tape. :-)

> 
> My guess is that the other posts about disk sizes being different is
> likely the issue. When I want to use a physical drive attached to
> Q-Bus SCSI controller to be the target of a copying a simulated disk,
> I usually try to verify that the MSCP block count for the physical
> drive is actually what I expect it to be.

I guess I was naive.  I used to work with real RA drives in the
past and figured the emulations were at least accurate enough to
know how big the disk was.  It wasn't a secret.

> 
> If I can attach the Q-Bus SCSI controller and drive to a MicroVAX
> system I can boot VMS and mount /foreign the drive and show dev /full
> the drive to get the block count. Or if the the Q-Bus SCSI controller
> and drive are attached to an 11/53, /73, /83 (or /93 if I had one of
> those) I can boot the 2.11BSD install tape and run the standalone
> disklabel program to display the reported MSCP geometry of the drive.
> The must be several other ways to display the MSCP reported geometry
> of a drive, those are just two that I have used myself in the past.
> 

All sounds like fun, but if the two emulations don't do RA81
correctly the information doesn't really do me much good.  I
certainly can't change the CQD's idea of what an RA81 is.

I am sure  once I successfully leap this hurdle the system will
run RSTS nicely (I only wish I had the CIS option for one of my
machines).  Like I said earlier, good thing this is only a
hobby.

bill

Re: PDP-11 disk image question

[Charles Anthony via cctalk]

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> On 2/18/19 4:35 PM, Paul Koning wrote:
>
> > It would be interesting if you can post the exact sizes in blocks of the
> SIMH image, and the real disk you copied it to.  That would help confirm my
> guess that it's a size issue.
>
> If it's a size issue then one of them is doing it wrong because the
> size of an RA81 constant.
>
>
Looking at the SIMH code:

/*
type sec surfcyl tpg gpc RCT LBNs
RA81 51(+1)  14  125814  1   2856891072
*/

#define RA81_SECT   51  /* +1 spare/track */
#define RA81_SURF   14
#define RA81_CYL1258/* 0-1247 user */
#define RA81_TPGRA81_SURF
#define RA81_GPC1
#define RA81_XBN2436/* cyl 1252-1254? */
#define RA81_DBN2436/* cyl 1255-1256? */
#define RA81_LBN891072  /* 51*14*1248 */
#define RA81_RCTS   2856/* cyl 1248-1251? */
#define RA81_RCTC   1
#define RA81_RBN17472   /* 1 *14*1248 */

I am presuming that (without actually checking) that these are the numbers
returned to RSTS when it queries the disk; if these numbers are different
then the h/w, then that could be an issue. I am a bit curious about "+1
spare/track" - I wonder if the h/w reports 51 or 52?

-- Charles

Re: PDP-11 disk image question

[Glen Slick via cctalk]

On Mon, Feb 18, 2019 at 5:18 PM Bill Gunshannon via cctalk
 wrote:
>
> Well, all I really have are CQD module which does MSCP and TMSCP
> over SCSI.

Do you have any SCSI tape drives? I have successfully installed RSTS/E
10.1 from install tapes on real PDP-11 hardware using an Exabyte
EXB-8200 8mm tape drive attached to a CMD CQD-220/TM. The target hard
drive for the installation was also attached to the CMD CQD-220/TM.
That is always one route you could try.

My guess is that the other posts about disk sizes being different is
likely the issue. When I want to use a physical drive attached to
Q-Bus SCSI controller to be the target of a copying a simulated disk,
I usually try to verify that the MSCP block count for the physical
drive is actually what I expect it to be.

If I can attach the Q-Bus SCSI controller and drive to a MicroVAX
system I can boot VMS and mount /foreign the drive and show dev /full
the drive to get the block count. Or if the the Q-Bus SCSI controller
and drive are attached to an 11/53, /73, /83 (or /93 if I had one of
those) I can boot the 2.11BSD install tape and run the standalone
disklabel program to display the reported MSCP geometry of the drive.
The must be several other ways to display the MSCP reported geometry
of a drive, those are just two that I have used myself in the past.

Re: PDP-11 disk image question

[Warner Losh via cctalk]

On Mon, Feb 18, 2019 at 6:18 PM Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> On 2/18/19 7:39 PM, Paul Koning wrote:
> > TU58, no -- that's not a file structured device on RSTS.  RX33 is an
> RX50 in a different physical package if I remember -- 800 block MSCP
> device.  That works fine, subject to the necessary tricks to get the files
> on the floppies and do the switching.
>
> No, RX50 was a strange DEC format.  RX33 is a 1.2M floppy.
>

The RX50 was a single sided 800 block floppy. The first two tracks had no
interleave. The rest has 2:1 interleave, though sometimes physical and
other times logical. Strange in some ways, kinda standard in others. But
it's still a floppy, and other than size, much like the RX33 with 1/3 the
number of blocks.

Warner

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

On 2/18/19 9:02 PM, Paul Koning wrote:
> 
> 
>> On Feb 18, 2019, at 8:18 PM, Bill Gunshannon via cctalk 
>>  wrote:
>>
>> On 2/18/19 7:39 PM, Paul Koning wrote:
>>>
>>> ...
>>> TU58, no -- that's not a file structured device on RSTS.  RX33 is an RX50 
>>> in a different physical package if I remember -- 800 block MSCP device.  
>>> That works fine, subject to the necessary tricks to get the files on the 
>>> floppies and do the switching.
>>
>> No, RX50 was a strange DEC format.  RX33 is a 1.2M floppy.
> 
> Ok.  That's may be big enough without volume switching, but in any case, if 
> it speaks MSCP, RSTS will support it.  (Well -- more precisely, if it speaks 
> MSCP and have fewer than 2^23 blocks.)

Works off of an RQDX3 or one of my Andromeda cards.  Both MSCP.

> 
>>> ...
>>> You mean build an initial system on a small disk, and then load the rest 
>>> onto a big disk some other way?  Sure, that should work fine.
>>
>> I was thinking build a minimal system on a smaller disk and
>> and then use it and backup to move the RA81 system to real
>> hardware and then use that for playing with.
> 
> Yes, that will be fine.  If the disk is RL02-ish in size it will be ample for 
> this purpose.  Even something as small as an RK05 can probably be  made to do 
> a basic job.

I have a couple of RD31's.  They are 20M.
I have one RD33 which is 71M.  Only possible problem is the Micronotes
claim it was never released by DEC so I may find it is not supported.
But I will likely try the RD31 and see what happens.

bill

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 18, 2019, at 8:18 PM, Bill Gunshannon via cctalk 
>  wrote:
> 
> On 2/18/19 7:39 PM, Paul Koning wrote:
>> 
>> ...
>> TU58, no -- that's not a file structured device on RSTS.  RX33 is an RX50 in 
>> a different physical package if I remember -- 800 block MSCP device.  That 
>> works fine, subject to the necessary tricks to get the files on the floppies 
>> and do the switching.
> 
> No, RX50 was a strange DEC format.  RX33 is a 1.2M floppy.

Ok.  That's may be big enough without volume switching, but in any case, if it 
speaks MSCP, RSTS will support it.  (Well -- more precisely, if it speaks MSCP 
and have fewer than 2^23 blocks.)

>> ...
>> You mean build an initial system on a small disk, and then load the rest 
>> onto a big disk some other way?  Sure, that should work fine.
> 
> I was thinking build a minimal system on a smaller disk and
> and then use it and backup to move the RA81 system to real
> hardware and then use that for playing with.

Yes, that will be fine.  If the disk is RL02-ish in size it will be ample for 
this purpose.  Even something as small as an RK05 can probably be  made to do a 
basic job.

paul

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

On 2/18/19 7:39 PM, Paul Koning wrote:
> 
> 
>> On Feb 18, 2019, at 5:24 PM, Bill Gunshannon via cctalk 
>>  wrote:
>>
>> On 2/18/19 4:35 PM, Paul Koning wrote:
>>>
>>> ...
>>> For the case of RSTS, small or large is not a consideration.  What matters, 
>>> as I mentioned, is that RSTS has a file system layout that is dependent on 
>>> the device size.  So (unlike some other file systems like FAT32) is isn't 
>>> always valid to do an image copy from one device to a larger device.
>>
>> My reference to small vs. large had to do with moving images from
>> SIMH virtual disks to real physical disks.  I have done it with
>> small disks which means the physical format of the virtual disk
>> in SIMH does, in fact, match the format of a\real equivalents.
>> At least for smaller disks.  I am fairly certain I have heard of
>> people doing it with RQ disks as well.  This was my first foray
>> into trying to do it with something the size of an RA disk.
>>
>> Theoretically, the SIMH emulated RA81 and the CMD emulated real
>> disk RA81 should be the same size because they are both supposed
>> to be RA81's.
> 
> Yes, but you said 4 partitions on a 2 GB disk, which is rather different from 
> the actual RA81 size.

According to the manual the first three will be RA81 and the
last partition whatever is left over.  So the part I was using
is supposed to be the same as a real RA81.

> 
>>> If the input and output devices are the same size, and error free, image 
>>> copy is always valid.  MSCP devices are error free;
>>
>> All of this sounds good on paper, but so far I have had no luck
>> actually accomplishing it.  I have tried copying with different block
>> sizes, copying from different media used to move the image.  The results
>> are always the same.
> 
> You could read back the copy and compare it with the original.  But I can 
> tell you that a properly executed image copy WILL work.  I suppose one 
> question is whether dd is actually such a program.

When I said I have seen others claim to do it, they usually
claim to have done it with dd.  I do know that VTServer worked
for RL02 and RX/RY disks because I  have done it myself.  But
the idea of doing this with a 400MB disk at 9600 baud seems
rather futile.  :-)

> 
>>> some older devices are also normally error free (like RK05 or RP03).
>>>
>>> It would be interesting if you can post the exact sizes in blocks of the 
>>> SIMH image, and the real disk you copied it to.  That would help confirm my 
>>> guess that it's a size issue.
>>
>> If it's a size issue then one of them is doing it wrong because the
>> size of an RA81 constant.
> 
> If you change the transfer address in the boot block by +2, you'll be dropped 
> into ODT immediately after INIT is loaded by the boot loader.  You can then 
> proceed from the break and ODT will be called again if a fatal error occurs 
> (such as the "init not found" message).
> 
> You can then look at the disk size table.  Use PATCH on your SIMH copy of the 
> system to find the address of DU$SZL and DU$SZM, those are the tables of low 
> and high 16 bits of the device size for each DU unit (indexed by unit 
> number).  The number there will tell you what INIT heard from the controller.
> 

Interesting.  Not sure I am ready to go that far into it at this point.
Still just  looking for some way to move the data.  I am thinking more
and more that an RD31 or RD33 might be a good stepping stone.

>>> ...
>>> The steps for bare metal restore go roughly like this:
>>>
>>> 1. Boot a kit
>>
>> And there is the problem.  If I had a kitI would  just do a clean
>> install on the 11/93.  :-)
> 
> What kit device do you need?

Well, all I really have are CQD module which does MSCP and TMSCP
over SCSI.  I have other controllers that might be coaxed  into
doing RX50 or RX33 but I haven't used one of them in ages, either.
And, as I said earlier TU58 in emulation. On a PC right now but
I have all the parts to build a hardware emulator.

> 
>>> 2. Use the DSKINT option to initialize the output disk
>>> 3. Use the COPY option to copy the minimal files to the output disk, which 
>>> is then booted.
>>> 4. Start that minimal system on the output disk.
>>> 5. Use RESTORE to copy everything from your backup.
>>>
>>> I don't remember if there is a documented procedure for creating a minimal 
>>> kit.  For disk based ones, it's pretty simple:
>>>
>>> a. Initialize the kit device as read-only.
>>> b. Mount it, overriding the read-only setting.
>>> c. Copy the minimal files.
>>> d. Hook INIT.SYS.
>>> e. To test it, boot the kit; it should boot correctly and act as a kit (by 
>>> offering to copy to the output device rather than by going to the usual 
>>> INIT prompt).
>>>
>>> You can do this for any RSTS disk that's big enough, and for which INIT 
>>> still has a boot loader.  For example, even in V10.1 you can boot an RK05, 
>>> so you can make an RK05 kit.
>>>
>>> If the device isn't big enough for all the minimal files, it gets a bit 
>>> tricky but it 

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 18, 2019, at 5:24 PM, Bill Gunshannon via cctalk 
>  wrote:
> 
> On 2/18/19 4:35 PM, Paul Koning wrote:
>> 
>> ...
>> For the case of RSTS, small or large is not a consideration.  What matters, 
>> as I mentioned, is that RSTS has a file system layout that is dependent on 
>> the device size.  So (unlike some other file systems like FAT32) is isn't 
>> always valid to do an image copy from one device to a larger device.
> 
> My reference to small vs. large had to do with moving images from
> SIMH virtual disks to real physical disks.  I have done it with
> small disks which means the physical format of the virtual disk
> in SIMH does, in fact, match the format of a\real equivalents.
> At least for smaller disks.  I am fairly certain I have heard of
> people doing it with RQ disks as well.  This was my first foray
> into trying to do it with something the size of an RA disk.
> 
> Theoretically, the SIMH emulated RA81 and the CMD emulated real
> disk RA81 should be the same size because they are both supposed
> to be RA81's.

Yes, but you said 4 partitions on a 2 GB disk, which is rather different from 
the actual RA81 size.

>> If the input and output devices are the same size, and error free, image 
>> copy is always valid.  MSCP devices are error free; 
> 
> All of this sounds good on paper, but so far I have had no luck
> actually accomplishing it.  I have tried copying with different block 
> sizes, copying from different media used to move the image.  The results
> are always the same.

You could read back the copy and compare it with the original.  But I can tell 
you that a properly executed image copy WILL work.  I suppose one question is 
whether dd is actually such a program.

>> some older devices are also normally error free (like RK05 or RP03).
>> 
>> It would be interesting if you can post the exact sizes in blocks of the 
>> SIMH image, and the real disk you copied it to.  That would help confirm my 
>> guess that it's a size issue.  
> 
> If it's a size issue then one of them is doing it wrong because the
> size of an RA81 constant.

If you change the transfer address in the boot block by +2, you'll be dropped 
into ODT immediately after INIT is loaded by the boot loader.  You can then 
proceed from the break and ODT will be called again if a fatal error occurs 
(such as the "init not found" message).

You can then look at the disk size table.  Use PATCH on your SIMH copy of the 
system to find the address of DU$SZL and DU$SZM, those are the tables of low 
and high 16 bits of the device size for each DU unit (indexed by unit number).  
The number there will tell you what INIT heard from the controller.

>> ...
>> The steps for bare metal restore go roughly like this:
>> 
>> 1. Boot a kit
> 
> And there is the problem.  If I had a kitI would  just do a clean
> install on the 11/93.  :-)

What kit device do you need?

>> 2. Use the DSKINT option to initialize the output disk
>> 3. Use the COPY option to copy the minimal files to the output disk, which 
>> is then booted.
>> 4. Start that minimal system on the output disk.
>> 5. Use RESTORE to copy everything from your backup.
>> 
>> I don't remember if there is a documented procedure for creating a minimal 
>> kit.  For disk based ones, it's pretty simple:
>> 
>> a. Initialize the kit device as read-only.
>> b. Mount it, overriding the read-only setting.
>> c. Copy the minimal files.
>> d. Hook INIT.SYS.
>> e. To test it, boot the kit; it should boot correctly and act as a kit (by 
>> offering to copy to the output device rather than by going to the usual INIT 
>> prompt).
>> 
>> You can do this for any RSTS disk that's big enough, and for which INIT 
>> still has a boot loader.  For example, even in V10.1 you can boot an RK05, 
>> so you can make an RK05 kit.
>> 
>> If the device isn't big enough for all the minimal files, it gets a bit 
>> tricky but it still can be done; the Micro-RSTS RX50 based kit is an 
>> example.  I don't have the details at my fingertips but I can dig them out 
>> if needed.
> 
> Well, this sounds like the most interesting and possible way.
> If it cold be done on RX50's it should be doable on other
> media.  Maybe RX33 or maybe even TU58. (Emulated, of course!)

TU58, no -- that's not a file structured device on RSTS.  RX33 is an RX50 in a 
different physical package if I remember -- 800 block MSCP device.  That works 
fine, subject to the necessary tricks to get the files on the floppies and do 
the switching.

Checking...  The way it's done is that INIT.SYS has to be on the first floppy, 
of course, which is what you boot.  Then the other needed files can be spread 
over other floppies as needed to fit (whole files per floppy).  All but the 
last floppy contain a name.EOV file where "name" is the pack label of the next 
floppy to use.  The content of the file is printed on the console as a prompt; 
it's a null terminated string.

> I haven't given up yet but it is turniong out to be a lot more
> of a 

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

On 2/18/19 4:35 PM, Paul Koning wrote:
> 
> 
>> On Feb 18, 2019, at 3:46 PM, Bill Gunshannon via cctalk 
>>  wrote:
>>
>>
>>
>> SO, to start a wrap up on this topic.  I had heard of people
>> copying images made on SIMH to real disks and using them.  It
>> now seems there are some serious strings attached to that idea.
>> I know it works for small disks as I have done it with RL02
>> and RX/Ry disks.
> 
> I'm not sure which comments you're replying to.

Pretty much all of them.  :-)


> 
> For the case of RSTS, small or large is not a consideration.  What matters, 
> as I mentioned, is that RSTS has a file system layout that is dependent on 
> the device size.  So (unlike some other file systems like FAT32) is isn't 
> always valid to do an image copy from one device to a larger device.

My reference to small vs. large had to do with moving images from
SIMH virtual disks to real physical disks.  I have done it with
small disks which means the physical format of the virtual disk
in SIMH does, in fact, match the format of a\real equivalents.
At least for smaller disks.  I am fairly certain I have heard of
people doing it with RQ disks as well.  This was my first foray
into trying to do it with something the size of an RA disk.

Theoretically, the SIMH emulated RA81 and the CMD emulated real
disk RA81 should be the same size because they are both supposed
to be RA81's.

> 
> If the input and output devices are the same size, and error free, image copy 
> is always valid.  MSCP devices are error free; 

All of this sounds good on paper, but so far I have had no luck
actually accomplishing it.  I have tried copying with different block 
sizes, copying from different media used to move the image.  The results
are always the same.

> some older devices are also normally error free (like RK05 or RP03).
> 
> It would be interesting if you can post the exact sizes in blocks of the SIMH 
> image, and the real disk you copied it to.  That would help confirm my guess 
> that it's a size issue.  

If it's a size issue then one of them is doing it wrong because the
size of an RA81 constant.

>  If that's not the answer, it would be possible to use INIT ODT to catch the 
> error and analyze what specifically it's unhappy about, but that's not 
> straightforward.
> 
> If you do have a size mismatch, fixing thatbefore you retry would be a good 
> thing.
> 
>> Too bad there is not some form of Standalone Backup like
>> VMS has.  I am open to any suggestions about how one can
>> get RSTS installed on real hardware when no usable tape
>> drive is available.  I don't suppose that hidden deep
>> in the bowels of RSTS is a procedure for making Installation
>> Kits on various media like Ultrix-11 has.
> 
> RSTS doesn't have any released mechanisms for creating installation kits.  
> Those scripts existed on the RSTS development systems.  Possibly they can be 
> found in source kits (which are rare).
> 
> In the early days, RSTS came with a standalone image backup program: ROLLIN.  
> Around V6 that was replaced by a file system aware standalone backup program: 
> the SAVRES option in INIT.  That was retired in V9 when the new fast BACKUP 
> program was released.
> 
> The reasoning here is that standalone backup isn't a feature -- instead, the 
> feature is a way to do a full system restore starting from a dead system.  
> RSTS does this by copying a few minimal features from the installation 
> device: INIT.SYS, a monitor (such as SYSGEN.SIL), DCL, BACKUP, and perhaps 
> one or two other files.  Then you start that minimal system and issue a 
> RESTORE command to restore everything from your backup.  So there is no need 
> for the maintenance headache of a "standalone" backup tool.  SAVRES had a 
> pile of hairy bugs and major maintenance headaches, and making a standalone 
> PDP11 tool do streaming tape support was just way too painful.  That's why V9 
> went the route of doing everything with BACKUP, since that's where the 
> streaming support was added.
> 
> The steps for bare metal restore go roughly like this:
> 
> 1. Boot a kit

And there is the problem.  If I had a kitI would  just do a clean
install on the 11/93.  :-)

> 2. Use the DSKINT option to initialize the output disk
> 3. Use the COPY option to copy the minimal files to the output disk, which is 
> then booted.
> 4. Start that minimal system on the output disk.
> 5. Use RESTORE to copy everything from your backup.
> 
> I don't remember if there is a documented procedure for creating a minimal 
> kit.  For disk based ones, it's pretty simple:
> 
> a. Initialize the kit device as read-only.
> b. Mount it, overriding the read-only setting.
> c. Copy the minimal files.
> d. Hook INIT.SYS.
> e. To test it, boot the kit; it should boot correctly and act as a kit (by 
> offering to copy to the output device rather than by going to the usual INIT 
> prompt).
> 
> You can do this for any RSTS disk that's big enough, and for which INIT still 
> has a boot loader.  For 

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 18, 2019, at 3:46 PM, Bill Gunshannon via cctalk 
>  wrote:
> 
> 
> 
> SO, to start a wrap up on this topic.  I had heard of people
> copying images made on SIMH to real disks and using them.  It
> now seems there are some serious strings attached to that idea.
> I know it works for small disks as I have done it with RL02
> and RX/Ry disks.  

I'm not sure which comments you're replying to.

For the case of RSTS, small or large is not a consideration.  What matters, as 
I mentioned, is that RSTS has a file system layout that is dependent on the 
device size.  So (unlike some other file systems like FAT32) is isn't always 
valid to do an image copy from one device to a larger device.

If the input and output devices are the same size, and error free, image copy 
is always valid.  MSCP devices are error free; some older devices are also 
normally error free (like RK05 or RP03).

It would be interesting if you can post the exact sizes in blocks of the SIMH 
image, and the real disk you copied it to.  That would help confirm my guess 
that it's a size issue.  If that's not the answer, it would be possible to use 
INIT ODT to catch the error and analyze what specifically it's unhappy about, 
but that's not straightforward.

If you do have a size mismatch, fixing thatbefore you retry would be a good 
thing.

> Too bad there is not some form of Standalone Backup like
> VMS has.  I am open to any suggestions about how one can
> get RSTS installed on real hardware when no usable tape
> drive is available.  I don't suppose that hidden deep
> in the bowels of RSTS is a procedure for making Installation
> Kits on various media like Ultrix-11 has.

RSTS doesn't have any released mechanisms for creating installation kits.  
Those scripts existed on the RSTS development systems.  Possibly they can be 
found in source kits (which are rare).

In the early days, RSTS came with a standalone image backup program: ROLLIN.  
Around V6 that was replaced by a file system aware standalone backup program: 
the SAVRES option in INIT.  That was retired in V9 when the new fast BACKUP 
program was released.

The reasoning here is that standalone backup isn't a feature -- instead, the 
feature is a way to do a full system restore starting from a dead system.  RSTS 
does this by copying a few minimal features from the installation device: 
INIT.SYS, a monitor (such as SYSGEN.SIL), DCL, BACKUP, and perhaps one or two 
other files.  Then you start that minimal system and issue a RESTORE command to 
restore everything from your backup.  So there is no need for the maintenance 
headache of a "standalone" backup tool.  SAVRES had a pile of hairy bugs and 
major maintenance headaches, and making a standalone PDP11 tool do streaming 
tape support was just way too painful.  That's why V9 went the route of doing 
everything with BACKUP, since that's where the streaming support was added.

The steps for bare metal restore go roughly like this:

1. Boot a kit
2. Use the DSKINT option to initialize the output disk
3. Use the COPY option to copy the minimal files to the output disk, which is 
then booted. 
4. Start that minimal system on the output disk.
5. Use RESTORE to copy everything from your backup.

I don't remember if there is a documented procedure for creating a minimal kit. 
 For disk based ones, it's pretty simple:

a. Initialize the kit device as read-only.
b. Mount it, overriding the read-only setting.
c. Copy the minimal files.
d. Hook INIT.SYS.
e. To test it, boot the kit; it should boot correctly and act as a kit (by 
offering to copy to the output device rather than by going to the usual INIT 
prompt).

You can do this for any RSTS disk that's big enough, and for which INIT still 
has a boot loader.  For example, even in V10.1 you can boot an RK05, so you can 
make an RK05 kit.

If the device isn't big enough for all the minimal files, it gets a bit tricky 
but it still can be done; the Micro-RSTS RX50 based kit is an example.  I don't 
have the details at my fingertips but I can dig them out if needed.

paul

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

SO, to start a wrap up on this topic.  I had heard of people
copying images made on SIMH to real disks and using them.  It
now seems there are some serious strings attached to that idea.
I know it works for small disks as I have done it with RL02
and RX/Ry disks.  I have one more thing to try but in the long
run it isn't very practical.  I am going to try using VTServer
to move the image.  Not practical as it will take several days
to do this and every minute increases the likelihood of it
just failing.

Too bad there is not some form of Standalone Backup like
VMS has.  I am open to any suggestions about how one can
get RSTS installed on real hardware when no usable tape
drive is available.  I don't suppose that hidden deep
in the bowels of RSTS is a procedure for making Installation
Kits on various media like Ultrix-11 has.

bill

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 17, 2019, at 2:32 PM, Paul Koning via cctalk  
> wrote:
> 
> 
> 
>> On Feb 16, 2019, at 1:04 PM, Bill Gunshannon via cctalk 
>>  wrote:
>> 
>> ...
>> First, my hardware.  I  have a PDP-11/93 with a CMD SCSI Module and
>> a BA350 with 6 2GB hard drives.  The Module is set up to present RA81
>> disks and the first 3 disks have 4 partitions each which should work
>> out to 12 RA81 disks. (But that last part is unimportant right now!)
> 
> A real RA81 has 891072 blocks, i.e., it's 445 MB.  If your partitions are 
> indeed 1/4th of a 2 GB disk they may be just over 512 MB.  If so, your RA81 
> image is not valid for those partitions.
> 
> Try shrinking the partitions to be the actual RA81 size, or slightly larger.

Alternatively, in SIMH define your disk to match the size of the actual device, 
and transfer your system to that disk.  It should be just a matter of copying 
everything (which in V9.0 or later is easily done with the BACKUP command) and 
you then probably have to use the HOOK utility to write the boot block.

paul

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 16, 2019, at 1:04 PM, Bill Gunshannon via cctalk 
>  wrote:
> 
> ...
> First, my hardware.  I  have a PDP-11/93 with a CMD SCSI Module and
> a BA350 with 6 2GB hard drives.  The Module is set up to present RA81
> disks and the first 3 disks have 4 partitions each which should work
> out to 12 RA81 disks. (But that last part is unimportant right now!)

A real RA81 has 891072 blocks, i.e., it's 445 MB.  If your partitions are 
indeed 1/4th of a 2 GB disk they may be just over 512 MB.  If so, your RA81 
image is not valid for those partitions.

Try shrinking the partitions to be the actual RA81 size, or slightly larger.

By the way, another possible issue: the free space bitmap in file SATT.SYS is 
created at pack format time to be large enough for the number of clusters on 
the disk.  If you move the image to a bigger disk, even one with the same 
device cluster size, it may be that the number of pack clusters now exceeds 
what SATT.SYS describes.  That too is an invalid file system.  I would expect 
that to give a more explicit error message, but it may be that this doesn't 
happen in INIT, or not at this stage.

Either way, the short answer is: RSTS will object to file systems moved to a 
smaller destination, or to one that is too much larger.  What is "too much" 
depends on a number of details.

paul

Re: PDP-11 disk image question

[Paul Koning via cctalk]

> On Feb 16, 2019, at 1:04 PM, Bill Gunshannon via cctalk 
>  wrote:
> 
> ...
> let's try with a detailed explanation of what I did that didn't seem
> to work.
> 
> First, my hardware.  I  have a PDP-11/93 with a CMD SCSI Module and
> a BA350 with 6 2GB hard drives.  The Module is set up to present RA81
> disks and the first 3 disks have 4 partitions each which should work
> out to 12 RA81 disks. (But that last part is unimportant right now!)
> 
> I used SIMH to build RSTS V9.6 on a simulated RA81 disk.  I wrote the
> disk as a file to a CDR in CD9660 format.  I moved the BA350 and the
> CD to a VS3100 running OpenBSD.  I was able to mount the CD under
> OpenBSD and see the file containing the disk image.  I used dd with
> the command given in my original message (and repeated above) to try
> to write the image to a real SCSI disk.  When I try to boot it I get
> the RSTS Message "INIT.SYS not found".  The disk was completely blank
> to start so the RSTS info must have been copied but apparently not
> copied correctly.

That message is from the first stage in INIT.SYS.  It means the boot loader 
loaded INIT successfully, because you got into that code and it executed disk 
drivers and file system code in an attempt to look up the INIT.SYS file.  That 
operation failed.

The most likely cause is that your disk is the wrong size.  If the system was 
built on a simulated disk of size x, and is booted on a disk where the 
controller reports size y, that may work.  But if the two sizes rounded up to 
the next power of two are different, RSTS will not recognize the file system.  
For example, if x is 500 GB and y is 600 GB, that will be the case.  This is 
because RSTS has a file system parameters "device cluster size" which is device 
size in blocks / 65535 rounded up to a power of 2.  And that number affects the 
file system layout.

The boot loader uses simple LBA addressing so it is unaffected by this, which 
explains why INIT.SYS was properly loaded by the boot loader.

paul

Re: PDP-11 disk image question

[J. David Bryan via cctalk]

On 2/16/19 7:55 AM, Bill Gunshannon via cctalk wrote:

> So, I used SIMH to do an install of a complete OS on an RA81 disk.  I
> would like to  move this to a real disk and try it on a real PDP-11.

Note that SIMH always writes disc images in little-endian format, 
regardless of host platform.  If your real PDP-11 expects to see big-endian 
16-bit words coming from the drive, you'll need to byte-swap the disc image 
before writing it to a real disc.

(This is necessary, e.g., when copying an HP 1000 disc image generated by 
SIMH to a real HP disc drive.)

  -- Dave

Re: PDP-11 disk image question

[Charles Anthony via cctalk]

On Sat, Feb 16, 2019 at 10:53 AM Charles Anthony 
wrote:

>
>
> On Sat, Feb 16, 2019 at 10:04 AM Bill Gunshannon via cctalk <
> cctalk@classiccmp.org> wrote:
>
>>
>>
>> I used SIMH to build RSTS V9.6 on a simulated RA81 disk.  I wrote the
>> disk as a file to a CDR in CD9660 format.  I moved the BA350 and the
>> CD to a VS3100 running OpenBSD.  I was able to mount the CD under
>> OpenBSD and see the file containing the disk image.  I used dd with
>> the command given in my original message (and repeated above) to try
>> to write the image to a real SCSI disk.  When I try to boot it I get
>> the RSTS Message "INIT.SYS not found".  The disk was completely blank
>> to start so the RSTS info must have been copied but apparently not
>> copied correctly.
>>
>> Any more suggestions?
>>
>
> My wild speculation would be disk geometry. I don't know the specific
> geometry of the RA81 disk, but it is possible that SIMH is writing a sparse
> disk image.
>
>
Did some reading up on the RA81 and looked at the relevant SIMH code; it
looks like the MSCP protocol is using Logical Block Addressing, which would
tend to disprove my sparse disk speculation.

-- Charles

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

On 2/16/19 3:57 PM, Zane Healy wrote:
> 
>> On Feb 16, 2019, at 10:04 AM, Bill Gunshannon via cctalk 
>>  wrote:
>>
>> OK, as usual, I hac caused confusion and didn't get my point across.
>>
>> let's try with a detailed explanation of what I did that didn't seem
>> to work.
>>
>> First, my hardware.  I  have a PDP-11/93 with a CMD SCSI Module and
>> a BA350 with 6 2GB hard drives.  The Module is set up to present RA81
>> disks and the first 3 disks have 4 partitions each which should work
>> out to 12 RA81 disks. (But that last part is unimportant right now!)
>>
>> I used SIMH to build RSTS V9.6 on a simulated RA81 disk.  I wrote the
>> disk as a file to a CDR in CD9660 format.  I moved the BA350 and the
>> CD to a VS3100 running OpenBSD.  I was able to mount the CD under
>> OpenBSD and see the file containing the disk image.  I used dd with
>> the command given in my original message (and repeated above) to try
>> to write the image to a real SCSI disk.  When I try to boot it I get
>> the RSTS Message "INIT.SYS not found".  The disk was completely blank
>> to start so the RSTS info must have been copied but apparently not
>> copied correctly.
>>
>> Any more suggestions?
> 
> That’s a really nice setup.
> 
> I’ve had a theory for a while now, but never had cause to actually put it to 
> the test.  RSTS/E would probably be why I would put it to the test.
> 
> First some background.  I’m far being skilled from RSTS/E, but I have managed 
> to get RSTS/E 10.1 and DECnet/E installed and running on my PDP-11/73, on a 
> SCSI drive.  While I’ve been able to install RT-11 and RSX-11M+ from CD-R, I 
> wasn’t able to figure out how to do that with RSTS/E.  With RT-11 or RSX I 
> boot from the CD-R, and do the install.  The next option I have is a TLZ06 
> drive, and I write the tapes with my Compaq XP1000/667 running OpenVMS.  As I 
> recall, that worked fine for installing RSTS/E, but it wouldn’t work for 
> DECnet/E, for DECnet/E I had to actually install from a TK50 tape.
> 

I guess I don't understand where you are getting bootable CDROM install
media for any PDP-11 OS.  I am not aware of any PDP-11 that supported
CDROM as a boot device either.

> Now for the theory…  What if you do a ‘dd’ of the drive you want to install 
> it to.  Then copy that image over to where you’re running SIMH, and use a 
> copy as your disk image for SIMH.   Install RSTS/E, and write it back to the 
> simulated RA81 using dd.  I do not know if this will work, but it’s something 
> I’ve wanted to try for a long time.

Might be interesting to try.

> 
> Another possibility is that you could be running into some sort of problem 
> with the RA81 simulation with the controller.  Do you have the manual for the 
> Controller?  If so what OS’s and versions does it say it supports?  Out of 
> curiosity, which SCSI board are you using?  I didn’t realize this was a 
> feature that the CMD controllers have.  Will it simulate any other drives?

I  have the manual.  I only chose RA81 as it was the biggest size
disk supported by all the PDP-11 OSes.  I would love to use bigger
but you have to pick one in the configuration of the controller.
You can choose to not emulate anything but I expect most PDP-11
OSes would have a problem installing to a very large, unspecified
type, disk.

I have a CQD=220A/MT configured for 6 disks and one tape.
As for disk types, you can toggle RA ON or OFF on each drive.
You can specify one RA type that will be in effect for any
disk with RA ON.  Types are: RA70, RA80, RA81, RA82, RA90 and RA92.
OSes supported are VMS, Ultrix, Unix/Berkeley, RSX-11M, RSX-11M-Plus,
RSTS/E, RT-11, DSM-11, ISM-11, TSX+, VAXELN and AT UNIX.
Most recent versions of all of them.  Or so it claims.  The only
OS I have ever had running on one of these cards was RT-11.  I
am just now getting around to trying to play with other OSes
to see if they actually work.  But, getting the OS onto the
machine is a challenge all in itself,

bill

Re: PDP-11 disk image question

[Zane Healy via cctalk]

> On Feb 16, 2019, at 10:04 AM, Bill Gunshannon via cctalk 
>  wrote:
> 
> OK, as usual, I hac caused confusion and didn't get my point across.
> 
> let's try with a detailed explanation of what I did that didn't seem
> to work.
> 
> First, my hardware.  I  have a PDP-11/93 with a CMD SCSI Module and
> a BA350 with 6 2GB hard drives.  The Module is set up to present RA81
> disks and the first 3 disks have 4 partitions each which should work
> out to 12 RA81 disks. (But that last part is unimportant right now!)
> 
> I used SIMH to build RSTS V9.6 on a simulated RA81 disk.  I wrote the
> disk as a file to a CDR in CD9660 format.  I moved the BA350 and the
> CD to a VS3100 running OpenBSD.  I was able to mount the CD under
> OpenBSD and see the file containing the disk image.  I used dd with
> the command given in my original message (and repeated above) to try
> to write the image to a real SCSI disk.  When I try to boot it I get
> the RSTS Message "INIT.SYS not found".  The disk was completely blank
> to start so the RSTS info must have been copied but apparently not
> copied correctly.
> 
> Any more suggestions?

That’s a really nice setup.

I’ve had a theory for a while now, but never had cause to actually put it to 
the test.  RSTS/E would probably be why I would put it to the test.  

First some background.  I’m far being skilled from RSTS/E, but I have managed 
to get RSTS/E 10.1 and DECnet/E installed and running on my PDP-11/73, on a 
SCSI drive.  While I’ve been able to install RT-11 and RSX-11M+ from CD-R, I 
wasn’t able to figure out how to do that with RSTS/E.  With RT-11 or RSX I boot 
from the CD-R, and do the install.  The next option I have is a TLZ06 drive, 
and I write the tapes with my Compaq XP1000/667 running OpenVMS.  As I recall, 
that worked fine for installing RSTS/E, but it wouldn’t work for DECnet/E, for 
DECnet/E I had to actually install from a TK50 tape.

Now for the theory…  What if you do a ‘dd’ of the drive you want to install it 
to.  Then copy that image over to where you’re running SIMH, and use a copy as 
your disk image for SIMH.   Install RSTS/E, and write it back to the simulated 
RA81 using dd.  I do not know if this will work, but it’s something I’ve wanted 
to try for a long time.  

Another possibility is that you could be running into some sort of problem with 
the RA81 simulation with the controller.  Do you have the manual for the 
Controller?  If so what OS’s and versions does it say it supports?  Out of 
curiosity, which SCSI board are you using?  I didn’t realize this was a feature 
that the CMD controllers have.  Will it simulate any other drives?

Zane

Re: PDP-11 disk image question

[Charles Anthony via cctalk]

On Sat, Feb 16, 2019 at 10:04 AM Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> I used SIMH to build RSTS V9.6 on a simulated RA81 disk.  I wrote the
> disk as a file to a CDR in CD9660 format.  I moved the BA350 and the
> CD to a VS3100 running OpenBSD.  I was able to mount the CD under
> OpenBSD and see the file containing the disk image.  I used dd with
> the command given in my original message (and repeated above) to try
> to write the image to a real SCSI disk.  When I try to boot it I get
> the RSTS Message "INIT.SYS not found".  The disk was completely blank
> to start so the RSTS info must have been copied but apparently not
> copied correctly.
>
> Any more suggestions?
>

My wild speculation would be disk geometry. I don't know the specific
geometry of the RA81 disk, but it is possible that SIMH is writing a sparse
disk image.

As an arbitrary example, suppose that there were seven sectors per track,
and the RA81 accepts a 3 bit sector number. If SIMH is treating the sector
number as a 0-7, then the blocks would be written to the image file as:
(track/sector)
   0/0  0/1  0/2  0/3  0/4  0/5  0/6  unused  1/0  1/1 .
When the image file is copied to the drive, the "unused" block is written
to 1/0 on the drive, and 1/0 is written to 1/1. etc.

This could match the observed behavior; the data in the first track is call
correct, allowing RSTS to start, but the directory blocks containing
INIT.SYS are on the wrong locations, causing the 'can't find' failure.

I don't know if SIMH is doing this; one test would be to run something on
the SIMH RSTS that filled the disk with data (ensuring that the last
sectors are written to, and compare the size of the image file with the
size of the actual disk; if the image file is bigger, then it is probably
sparsely written.

-- Charles

Re: PDP-11 disk image question

[Bill Gunshannon via cctalk]

On 2/16/19 12:35 PM, Zane Healy via cctalk wrote:
> 
>> On Feb 16, 2019, at 9:10 AM, Lyle Bickley via cctalk  
>> wrote:
>>
>> Bill,
>>
>> On Sat, 16 Feb 2019 13:55:10 +
>> Bill Gunshannon via cctalk  wrote:
>>
>>> So, I used SIMH to do an install of a complete OS on
>>> an RA81 disk.  I would like to  move this to a real disk
>>> and try it on a real PDP-11.  Is there a way to do this
>>> using dd on a BSD machine?  I tried but it created a
>>> non bootable system.  Well, actually, it starts to boot
>>> but then fails very early in the startup process.  I used
>>> "dd if=filename of=raw-device bs=1024".  Could it be that
>>> the block size needs to be something else?
>>>
>>> I know that VTServer and PDPGUI can move disk images but
>>> it would take a week at 9600 baud and I think very little
>>> likelihood of it ever completing successfully.
>>>
>>> bill
>>
>> In order to do this easily, I have SCSI controllers (and disks) on my
>> two primary PDP-11 systems (11/34 and 11/83).
>>
>> 1. I copy the image file I want on a "native" drive using a PC w/SCSI
>> and Linux to a SCSI disk (or removable media) using "dd".
>>
>> 2. I move that drive/media to the SCSI "chain" on a PDP-11.
>>
>> 3. I use RT-11 to move the image from the SCSI drive/media to the
>> "native" HDD.
>>
>> Its a bit cumbersome, but I used this method for years and it hasn't
>> failed me yet ;)
> 
> Like Lyle I have SCSI controllers on my PDP-11/73, and my PDP-11/44.  I’ve 
> actually installed RT-11 and RSX-11M+ from CD-R.  There is another option, 
> and I’ve used this with RL01’s and RL02’s.  With those, I’ve used a MicroVAX 
> II or MicroVAX 3 and VAX/VMS.  I used to have a  dedicated MicroVAX 3 setup 
> with RA73 drives for this.  I still have the hardware, but it hasn’t been 
> used since 2000.  If you have a way to hook the RA81 up to a VAX, I think 
> that would be an option as well.
> 

OK, as usual, I hac caused confusion and didn't get my point across.

let's try with a detailed explanation of what I did that didn't seem
to work.

First, my hardware.  I  have a PDP-11/93 with a CMD SCSI Module and
a BA350 with 6 2GB hard drives.  The Module is set up to present RA81
disks and the first 3 disks have 4 partitions each which should work
out to 12 RA81 disks. (But that last part is unimportant right now!)

I used SIMH to build RSTS V9.6 on a simulated RA81 disk.  I wrote the
disk as a file to a CDR in CD9660 format.  I moved the BA350 and the
CD to a VS3100 running OpenBSD.  I was able to mount the CD under
OpenBSD and see the file containing the disk image.  I used dd with
the command given in my original message (and repeated above) to try
to write the image to a real SCSI disk.  When I try to boot it I get
the RSTS Message "INIT.SYS not found".  The disk was completely blank
to start so the RSTS info must have been copied but apparently not
copied correctly.

Any more suggestions?

bill

Re: PDP-11 disk image question

[Jerry Weiss via cctalk]

On 2/16/19 7:55 AM, Bill Gunshannon via cctalk wrote:

So, I used SIMH to do an install of a complete OS on
an RA81 disk.  I would like to  move this to a real disk
and try it on a real PDP-11.  Is there a way to do this
using dd on a BSD machine?  I tried but it created a
non bootable system.  Well, actually, it starts to boot
but then fails very early in the startup process.  I used
"dd if=filename of=raw-device bs=1024".  Could it be that
the block size needs to be something else?

I know that VTServer and PDPGUI can move disk images but
it would take a week at 9600 baud and I think very little
likelihood of it ever completing successfully.

bill
As long as the media is presented as "Error Free", you should be able to 
to change the block size.   Since a RA81 (MSCP) remaps error blocks 
automatically and invisibly, it should work.  Is the media type the same 
on SIMH and Real PDP11?   If all else fails try bs=512.


For drives that have OS visible media defects, you should make sure the 
block size matches the same on the media and also use the option 
"conv=noerror,sync".  Otherwise dd will actually reorders the blocks(!), 
good first then zero fill the ones it cannot read.


    Jerry

Re: PDP-11 disk image question

[Zane Healy via cctalk]

> On Feb 16, 2019, at 9:10 AM, Lyle Bickley via cctalk  
> wrote:
> 
> Bill,
> 
> On Sat, 16 Feb 2019 13:55:10 +
> Bill Gunshannon via cctalk  wrote:
> 
>> So, I used SIMH to do an install of a complete OS on
>> an RA81 disk.  I would like to  move this to a real disk
>> and try it on a real PDP-11.  Is there a way to do this
>> using dd on a BSD machine?  I tried but it created a
>> non bootable system.  Well, actually, it starts to boot
>> but then fails very early in the startup process.  I used
>> "dd if=filename of=raw-device bs=1024".  Could it be that
>> the block size needs to be something else?
>> 
>> I know that VTServer and PDPGUI can move disk images but
>> it would take a week at 9600 baud and I think very little
>> likelihood of it ever completing successfully.
>> 
>> bill
> 
> In order to do this easily, I have SCSI controllers (and disks) on my
> two primary PDP-11 systems (11/34 and 11/83).
> 
> 1. I copy the image file I want on a "native" drive using a PC w/SCSI
> and Linux to a SCSI disk (or removable media) using "dd".
> 
> 2. I move that drive/media to the SCSI "chain" on a PDP-11.
> 
> 3. I use RT-11 to move the image from the SCSI drive/media to the
> "native" HDD.
> 
> Its a bit cumbersome, but I used this method for years and it hasn't
> failed me yet ;)

Like Lyle I have SCSI controllers on my PDP-11/73, and my PDP-11/44.  I’ve 
actually installed RT-11 and RSX-11M+ from CD-R.  There is another option, and 
I’ve used this with RL01’s and RL02’s.  With those, I’ve used a MicroVAX II or 
MicroVAX 3 and VAX/VMS.  I used to have a  dedicated MicroVAX 3 setup with RA73 
drives for this.  I still have the hardware, but it hasn’t been used since 
2000.  If you have a way to hook the RA81 up to a VAX, I think that would be an 
option as well.

Zane

Re: PDP-11 disk image question

[Lyle Bickley via cctalk]

Bill,

On Sat, 16 Feb 2019 13:55:10 +
Bill Gunshannon via cctalk  wrote:

> So, I used SIMH to do an install of a complete OS on
> an RA81 disk.  I would like to  move this to a real disk
> and try it on a real PDP-11.  Is there a way to do this
> using dd on a BSD machine?  I tried but it created a
> non bootable system.  Well, actually, it starts to boot
> but then fails very early in the startup process.  I used
> "dd if=filename of=raw-device bs=1024".  Could it be that
> the block size needs to be something else?
> 
> I know that VTServer and PDPGUI can move disk images but
> it would take a week at 9600 baud and I think very little
> likelihood of it ever completing successfully.
> 
> bill

In order to do this easily, I have SCSI controllers (and disks) on my
two primary PDP-11 systems (11/34 and 11/83).

1. I copy the image file I want on a "native" drive using a PC w/SCSI
and Linux to a SCSI disk (or removable media) using "dd".

2. I move that drive/media to the SCSI "chain" on a PDP-11.

3. I use RT-11 to move the image from the SCSI drive/media to the
"native" HDD.

Its a bit cumbersome, but I used this method for years and it hasn't
failed me yet ;)

Cheers,
Lyle
-- 
73   NM6Y
Bickley Consulting West Inc.
http://bickleywest.com

"Black holes are where God is dividing by zero"

PDP-11 disk image question

[Bill Gunshannon via cctalk]

So, I used SIMH to do an install of a complete OS on
an RA81 disk.  I would like to  move this to a real disk
and try it on a real PDP-11.  Is there a way to do this
using dd on a BSD machine?  I tried but it created a
non bootable system.  Well, actually, it starts to boot
but then fails very early in the startup process.  I used
"dd if=filename of=raw-device bs=1024".  Could it be that
the block size needs to be something else?

I know that VTServer and PDPGUI can move disk images but
it would take a week at 9600 baud and I think very little
likelihood of it ever completing successfully.

bill