[Simh] SCSI-Interface for simh-vax?

[Eberhard Heuser]

Newer systems (alpha,itanium) have drivers for SCSI,IDE and USB, that 
accept "RAW"-I/O.
That means that it is possible to read and write via SCSI-commands. You 
must use IO$_DIAGNOSE
in your sys$qiow-command:
         status = sys$qiow ( 1, gk_channel, IO$_DIAGNOSE,
             &disk_iosb, 0, 0,
             &gk_desc, sizeof(gk_desc), 0, 0, 0, 0);
The pudriver hasn't this capability. The first class driver that accepts 
raw commands is the SCSI-driver
(dkdriver/pkdriver).

I have written a writer program for VMS that produces CD/DVD/BLU-RAY and 
the VAX-version works
definitely for CD-R(W) and DVD+-R(W).

Eberhard

Am 01.09.2018 um 22:18 schrieb Timothe Litt:
>> CD's are normally 1024 byte blocks
> 2048 Bytes/sector is the ISO std for CD-ROMs (Mode 1).  Mode 2 omits ECC
> for2336 B/sector - but I don't know of a case where someone was crazy
> enough to use it for data.
>
>> 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.
>
> 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.
>
> 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 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.
>
> Also note that dual format CDROMs are possible - 9660 reserves the first
> 16 sectors for this; thus it's possible to write a disk that is readable
> as both FILES-11 and & 9660 (with file data being in the same sectors;
> only the metadata differs.)  Such disks were actually created.
>
> On 01-Sep-18 15:28, Clem Cole wrote:
>> below...
>>
>> On Sat, Sep 1, 2018 at 2:39 PM Zane Healy <healyzh at avanthar.com
>> <mailto:healyzh at avanthar.com>> wrote:
>>
>>      Create a virtual disk in SIMH the size of the CD-R blank.  Prep
>>      the disk, then burn it to CD-R.  This is how I created my bootable
>>      CD’s for RT-11 and RSX-11M+.  I’ve then used those CD’s to do
>>      installs on my PDP-11/73.  I wasn’t able to figure out how to make
>>      it work in RSTS/E.  I could create the CD-R, but not boot and
>>      install RSTS/E from it.
>>
>>
>> Just curious ... aren't there funnies because CD's are normally 1024
>> byte blocks and disks are usually 512?    IIRC, there are places that
>> store numbers of blocks (not bytes), and you have to be careful.    I
>> have >>not<< played in any of that in years.
>>
>> IIRC one of things  we might have done at DEC was mess with the block
>> size on a CD -- that's a Tim Litt type question.   Those bits are so
>> long ago depreciated/garbage collected in my acitve brain cells. ;-)
>> ᐧ
>>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus