[Simh] Imaging SCSI HD's

[Zane Healy]

This was supposed to go out well before my last email, I thought it went out hours ago, and just realized I’d not sent it.  The hazards of doing too many things today.

> On Apr 21, 2019, at 2:36 PM, Mark Pizzolato <Mark at infocomm.com> wrote:
> 
> On Sunday, April 21, 2019 at 11:28 AM, Zane Healy wrote:
>> I have a DL380 on the way to add to my ESXI cluster here at home.  As a result
>> I’m looking to finish virtualizing my DEC HW.  What is the best way to convert
>> a physical SCSI HD to a disk image for SIMH?  I need to do this for both VAX
>> and PDP-11.
> 
> If these are SCSI disks, AND you have a host system with a SCSI host adapter 
> that can connect to these disks (i.e. it is the correct SCSI width, and type), 
> then you can do this directly using simh from the host system.

Okay, I thought that might be possible, but I wasn’t sure.  This is venturing into areas that I’ve never messed with, with any of the DEC emulation software.

> Warning: If  you try to do this under some complicated set of layered 
> virtual systems, then you are on your own (recall your VNC experience).

Reading up more on SDL2, I don’t think virtualization was the issue, rather my lack of understanding as to what LibSDL2 provides.

> Depending on your host system the OS will have some name for the 
> above mentioned SCSI disk(s) which you've connected.  
> When you connect these disks to the host system, BE SURE not to 
> perform any action on these drives BEFORE you let simh see them.
> Be sure you identify the raw device name that the OS sees the newly
> connected SCSI disks as.  Knowing that name the following should work
> with a VAX or PDP11 simulator.  Note that this will probably have to 
> be done as root in order to access the physical devices.
> 
>       # vax
>       sim> ATTACH RQ0 -c <rawdevicename> disk1.vhd
>       sim> DETACH RQ0
> 
> This will produce a "disk1.vhd" container file with all of the bits that can be read from the original SCSI disk.
> Repeat as necessary for each original disk. 

Interesting, I may be better off doing this with a SparcStation then, as I seem to remember the OBP would make ID’ing things easier.  In any case, this isn’t a quick fix.  I should have all the bits and pieces, but find them will likely be a challenge. 

>> One of the main systems that I want to Virtualize is a VAXstation 4000/60
>> with a BA350 shelf.  The only HD connected to the system is a RZ28-VA SBB
>> (2GB) as DKA200:, so yesterday I added a RZ29-VA SBB (4GB) as DKA100:.  I
>> setup Standalone Backup on the RZ29 and booted into Standalone backup.
>> 
>> I tried to run the following:
>> backup/image/verify dka200: dka100:[000000]20190420-system.sav/sav
>> 
>> I ended up with a very strange “No valid storage bitmap found” error, and it
>> failed to copy anything.
>> 
>> Facility: BACKUP, Backup Utility
>> Explanation: Software bad block data is not present on the volume. The
>> volume has been initialized with no bad blocks.
>> User Action: Execute the Bad Block Locator utility before using the volume.
>> NOBITMAP, no valid storage bitmap found on 'device-name’
>> 
>> I tried ANALYZE/MEDIA, but may not have been doing things right.  This is a
>> Genuine RZ29-VA, but it was originally used as part of a disk array for a Sun
>> Sparc system.
> 
> This exercise will merely put a backup saveset on another disk which I don't 
> see getting you very far towards making it accessible from simh.

I should be able to then transfer the resulting file over to a SIMH/VAX disk, boot up SIMH in StandAlone Backup, and restore it.

(I’ve now verified this works for an Alpha).

> Meanwhile, I suspect you are seeing a failure under standalone backup due 
> to the fact that after you added the DKA100 disk drive to the system you 
> didn't initialize the disk.  You can't initialize a target disk under standalone
> backup, so you'll have to do that with full VMS running before you attempt
> the backup again.

I wish it were this simple.  The disk was already initialized before I installed it, though oddly enough, unused (so I’m not sure what I’d previously intended it for).  In addition I did an INIT on it from VAX/VMS 5.5-2, and I did it an INIT a second time on an installation of StandAlone Backup.

I’m not sure if I’m running into a VAX/VMS 5.5-2 bug, or a problem with the destination Hard Drive.  I need to try a different RZ29-VA drive.

Zane