[Simh] SCSI-Interface for simh-vax?

[Johnny Billquist]

On 2018-09-01 22:18, Timothe Litt wrote:
>> we might have done at DEC was mess with the block size on a CD
> 
> DEC does not modify the physical sector format - it is implemented in
> the drive.
> 
> VMS packs four 512 B logical sectors into one 2048 B physical sector;
> the driver handles buffering and provides the illusion of a 512B sector
> size.  Most FILES-11 CDs use unmodified ODS-2.   But distribution CDs
> would do things like omit (or truncate) the bit table to save space.
> For that reason, ANA/DISK would fail.  There are some CDs that use a
> slightly modified HOM block (FILES-11 B Level 0), but it wasn't widely
> adopted.

When you say "driver", it sounds like you mean the VMS device drive. But 
in the previous paragraph you said "drive".
The correct answer is "drive". VMS requires that the CD drive can handle 
512 byte sectors. The drive needs to do the unblocking.
Not all CD drives can do this, so one have to be careful which drive to 
use on a VMS system. This might be different on Alpha and Itanium 
systems, but for VAX it has to have 512 byte sector size.

Also, VMS actually understands ISO 9660 file systems. I don't remember 
when that came in, but it's definitely the case for OpenVMS V7.3 on a VAX.

> There are other oddities - drives & drivers tell different lies about
> the geometry (cyl/track/sector) of a CDROM; multiplying these out
> frequently will not match the file system's idea of the volume size.
> (As recorded in the SCB for FILES-11, equivalent for other formats.)
> The lies vary by OS, version, drive & phase of the moon.  The same CD
> read under different conditions will report alternative facts.  These
> will not trip up a DEC OS on DEC HW - but can create obscure issues with
> simulation - especially if you try to pass geometry  from a physical
> drive thru SimH.

That sounds weird. As far as I know, VMS don't really care about 
cyl/trk/sector information here. That kind of information is rather old 
school and was used on devices predating MSCP. MSCP and later instead 
just deal with total device capacity as reported, and don't try to 
calculate it. I think there usually is some fake cyl/trk/sector data 
that can be reported, which just gets you close to capacity, but usually 
don't really end up with the right number, but which can be used if 
anyone really insist they want this kind of information.

That said, CD is still a bit special, since the actual size in the file 
system might be different than the capacity of the drive.

But I think that there should hardly be any issues in any simulation 
here. As long as the size is reported right, geometry numbers can be 
pretty much anything without a problem.

> Writing a CD is rarely supported by a standard driver - typically, CD
> writing software issues direct SCSI commands to the drive (encapsulated
> in whatever the real transport is).  This may be by direct IO, or via a
> class driver.  It can be somewhat tricky - note that most drives can not
> tolerate buffer underruns when writing.

I don't think VMS ever supported writing to a CD in a natural way. But 
of course device drivers might have gotten the capability along the way, 
so special programs can do it.

I think most drives deal well with underruns nowadays. But that used to 
be a big issue a number of years ago.

>> I wasn’t able to figure out how to make it work in RSTS/E.
> 
> To be bootable, a CD needs an appropriate boot block (LBN 0).  For VMS,
> it's written by 'writeboot' - not initialize.  I don't remember the
> details for RSTS - look at SAVRES->RESTORE and BACKUP for
> possibilities.    Or wait for Paul K to fill that in.

Paul needs to chime in here. But in the back of my head, there is a 
warning bell about RSTS/E expecting/require the boot device to always be 
writeable, which could be a serious problem for a CD.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol