[Info-vax] Valid disk types for SIMH?

[Paul Sture]

In article <00c1309c$0$32363$c3e8da3 at news.astraweb.com>,
 JF Mezei <jfmezei.spamnot at vaxination.ca> wrote:

> Paul Sture wrote:
> > I would like to use a larger disk with SIMH than an RA90 (1GB), but
> > can't dig up any SIMH related info mentioning larger disks.
> > 
> > Can some kind soul please point me in the right direction?
> 
> Since you want the "right" direction, you need to turn right and look at:
> 
> http://labs.hoffmanlabs.com/node/922

Touché :-)

> and
> 
> http://simh.trailing-edge.com/
> 
> Somewhere in there is documentation on the variable to set during
> compile so that it allows the use of large files as disk containers.
> (Can't seem to find it right now)

I used the "hack" at 

http://labs.hoffmanlabs.com/node/922

to get SIMH to compile with XCode 3.1. Looking at the makefile, it 
appears that the large file support option is already there.
 
> 
> And then, in you .ini file, something like
> 
> SET RQ0 rauser=3125408
> ATTACH RQ0 /Users/jfmezei/dia0.iso
> 
> which defines the size of the disk.

In the latest version of vax_doc.pdf (01-Dec-2008), the "SET -L" line in 
the table of disks at 2.4.2 has unfortunately slipped to the next page:

---- start quote ----
SET RQn RAUSER{=n}  set type to RA82 with n MB's
SET -L RQn RAUSER{=n}  set type to RA82 with n LBN's

The type options can be used only when a unit is not attached to a file.  
RAUSER is a "user specified" disk;  the user can specify the size of the 
disk in either MB (1000000 bytes) or logical block numbers (LBN's, 512 
bytes each).  The minimum size is 5MB; the maximum size is 2GB without 
extended file support, 1TB with  extended file support 
---- end quote ----

There's an area of confusion here in that when you first initialize a 
disk declared using either flavour of RAUSER syntax (under OS X 10.5.8), 
only half of the expected amount is allocated in the host OS. The 
MAXBLOCK size within VMS does look right, and a simple INIT/ERASE will 
expand the container file to the full size.

It strikes me that there's a potential problem here if the host has 
insufficient free space to expand the container to its full size when 
VMS requires it.

Here's an example:

sim> set -L rq3 rauser=10000000
att rq3 /Volumes/simh-data/dua3.dsk
RQ: creating new file

In OS X:

$ ls -l dua3.dsk
-rw-r--r--  1 simh  staff  0 Nov 23 12:58 dua3.dsk

Now do INIT in VMS, and this changes to half the expected size:

$ ls -l dua3.dsk
-rw-r--r--  1 simh  staff  2560665600 Nov 23 12:59 dua3.dsk
$ ls -lh dua3.dsk
-rw-r--r--  1 simh  staff   2.4G Nov 23 12:59 dua3.dsk

Now do INIT/ERASE in VMS and full allocation is achieved:

$ ls -l dua3.dsk
-rw-r--r--  1 simh  staff  5120000000 Nov 23 13:08 dua3.dsk
$ ls -lh dua3.dsk
-rw-r--r--  1 simh  staff   4.8G Nov 23 13:08 dua3.dsk

-- 
Paul Sture