[Simh] SCSI-Interface for simh-vax?

[Eberhard Heuser]

Hi,

Are there any plans to add a SCSI-Interface to the VAX-code?

I want to add the CD-R burning capability but there is no interface
(SCSI or IDE) that allows to communicate on the diagnose level
with an CD-drive.

I have seen that one can access a physical CD-drive but only through
the pudriver and not via the pkdriver.

regards
Eberhard

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

[Mark Pizzolato]

Post by Eberhard Heuser
Are there any plans to add a SCSI-Interface to the VAX-code?
I want to add the CD-R burning capability but there is no interface
(SCSI or IDE) that allows to communicate on the diagnose level
with an CD-drive.
I have seen that one can access a physical CD-drive but only through
the pudriver and not via the pkdriver.

Well, none of the current VAX simulators had a native SCSI interface
which was interfaced with the pkdriver. Without a simulated system
there is no place for SCSI support.

Meanwhile, 99%+ of the host systems are natively capable of burning
CD/DVD. I am not aware of any DEC supplied software running on
VAX/VMS which was capable of producing a CD image in the ISO 9660
file system format. All CDs that I ever encountered on DEC systems
(produced by DEC for use on VMS systems) had ODS2 file systems on
the CD media. All of the existing VAX simulators can easily produce an
ODS2 disk image of arbitrary size which can then be readily written on
the host system to CD or DVD media with host supplied tools.

Even if a simulator comes along which does have a built in SCSI support,
arbitrarily extending that support to interface with CD/DVD media for
burning activities would be a challenge to achieve in a portable way
to work on most host platforms and as such probably won't get done
unless you're interested in taking on the project.

After thinking a little more, I vaguely recall that there was indeed a
Qbus board which had a SCSI chip that used the PKDRIVER. This
was called the KZQSA. I tested one once and was fundamentally
unimpressed by its performance primarily due to it not being a
DMA device. In any case, I haven't seen any detailed documentation
on this board which would be necessary to write a simulator of it,
but if you can find documentation, feel free to take a crack at
simulating it, and delving into the host platform complexities (in
a portable way) to burn CD media.

- Mark

[Jordi Guillaumes i Pons]

Mark,

I’ve got two QBUS interface cards installed in my VAX 4000-200 and uVAX 3300 systems. I think I’ve got no docs though. Would that be of any help (ie, testing stuff on real hardware)?

Jordi Guillaumes Pons

Post by Mark Pizzolato

Post by Eberhard Heuser
Are there any plans to add a SCSI-Interface to the VAX-code?
I want to add the CD-R burning capability but there is no interface
(SCSI or IDE) that allows to communicate on the diagnose level
with an CD-drive.
I have seen that one can access a physical CD-drive but only through
the pudriver and not via the pkdriver.

Well, none of the current VAX simulators had a native SCSI interface
which was interfaced with the pkdriver. Without a simulated system
there is no place for SCSI support.
Meanwhile, 99%+ of the host systems are natively capable of burning
CD/DVD. I am not aware of any DEC supplied software running on
VAX/VMS which was capable of producing a CD image in the ISO 9660
file system format. All CDs that I ever encountered on DEC systems
(produced by DEC for use on VMS systems) had ODS2 file systems on
the CD media. All of the existing VAX simulators can easily produce an
ODS2 disk image of arbitrary size which can then be readily written on
the host system to CD or DVD media with host supplied tools.
Even if a simulator comes along which does have a built in SCSI support,
arbitrarily extending that support to interface with CD/DVD media for
burning activities would be a challenge to achieve in a portable way
to work on most host platforms and as such probably won't get done
unless you're interested in taking on the project.
After thinking a little more, I vaguely recall that there was indeed a
Qbus board which had a SCSI chip that used the PKDRIVER. This
was called the KZQSA. I tested one once and was fundamentally
unimpressed by its performance primarily due to it not being a
DMA device. In any case, I haven't seen any detailed documentation
on this board which would be necessary to write a simulator of it,
but if you can find documentation, feel free to take a crack at
simulating it, and delving into the host platform complexities (in
a portable way) to burn CD media.
- Mark
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Lars Brinkhoff]

Post by Jordi Guillaumes i Pons
I’ve got two QBUS interface cards installed in my VAX 4000-200 and
uVAX 3300 systems. I think I’ve got no docs though. Would that be of
any help (ie, testing stuff on real hardware)?

Hello,

I'm sorry to bother you and everyone else on this list, but have been
unsuccessfully trying to reach you about Barcelona retro computing.
Would you mind sending me an email to ***@nocrew.org?

Thanks,
Lars Brinkhoff

[Zane Healy]

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.

Zane

Post by Eberhard Heuser
Hi,
Are there any plans to add a SCSI-Interface to the VAX-code?
I want to add the CD-R burning capability but there is no interface
(SCSI or IDE) that allows to communicate on the diagnose level
with an CD-drive.
I have seen that one can access a physical CD-drive but only through
the pudriver and not via the pkdriver.
regards
Eberhard
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Clem Cole]

below...

Post by Zane Healy
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

Post by Zane Healy

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. ;-)
ᐧ

[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.

below...
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. ;-)
ᐧ

[Clem Cole]

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.

2048/2336 -- thanks - I knew I remember is something funky,
ᐧ

[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

Post by 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.

below...
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
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

[Johnny Billquist]

Post by Timothe Litt

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.

Post by Timothe Litt
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.

Post by Timothe Litt
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.

Post by Timothe Litt

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

[Paul Koning]

...

Post by Zane Healy
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.

No, that's fine, provided the file system flags mark the file system as read-only. In that case, RSTS will treat the disk as an installation disk, and when booted go automatically to the installation actions as opposed to prompting for a regular startup. You can't start such a disk, that is true. But you can boot it, invoke the disk initializer to initiaze your intended system disk, and copy the minimal files from the CD to that disk after which it is booted.

The block size could be a consideration; RSTS expects 512 byte blocks and I don't know how one would work around that on a CD. Also, what interface would you use? MSCP, I suppose; does that do the necessary magic to make it look like a 512-byte sector size device?

paul

[Johnny Billquist]

Post by Paul Koning

...

Post by Zane Healy
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.

No, that's fine, provided the file system flags mark the file system as read-only. In that case, RSTS will treat the disk as an installation disk, and when booted go automatically to the installation actions as opposed to prompting for a regular startup. You can't start such a disk, that is true. But you can boot it, invoke the disk initializer to initiaze your intended system disk, and copy the minimal files from the CD to that disk after which it is booted.

Ok. Definitely sounds like it should work then.

Post by Paul Koning
The block size could be a consideration; RSTS expects 512 byte blocks and I don't know how one would work around that on a CD. Also, what interface would you use? MSCP, I suppose; does that do the necessary magic to make it look like a 512-byte sector size device?

This is the same issues/conditions as you face with RSX, which the OP
did get to work.
Yes, you'd normally hook the CD to a SCSI controller which appears as an
MSCP disk to the PDP-11 side. I've done that often enough myself as well.
You do need a CD which can deal with 512 byte blocks. But from there on,
it looks just like any other disk to the PDP-11. A VAX have the same
issues/requirements, as do SUN. Not all CD drives can deal with 512 byte
sectors, so you have to look for that.

Johnny

[Paul Koning]

Post by Zane Healy
...
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.

More details for RSTS.

Right, when you initialize a RSTS disk it isn't bootable. You get a dummy boot (one that prints "please boot from the system disk") instead.

Bootable disks are created in one of several ways. SAVRES does, but that isn't helpful here. The other is the HOOK utility, which should be on the RSTS kit. The way that works: first make sure INIT.SYS has been copied into [0,1] on the destination device. Then run HOOK and tell it:

dev:[0,1]

and that should be all you need. (This is for disk; tape is different and I don't have the details handy.)

BACKUP doesn't create bootable devices.

Note that a bootable tape, and a bootable disk whose file system flags say it's read-only, are considered installation media. Read/write bootable disks are considered a system disk.

Finally, yes, I remember working with Fred Knight on dual format RSTS/E CDROM. The intent was to create a single disk with all RSTS/E DEC software on it. I don't know if that ever happened; I never saw the results. But to make this possible I added a mode to FLX to create a dual mode disk, ISO 9660 plus RSTS/E file system. Look in the FLX 2.6 documentation, the "-merge" switch. Note that I removed it from the FLX 3 code (Python based FLX), though it could be brought back easily enough.

paul

[Zane Healy]

Post by Clem Cole
below...
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. ;-)
ᐧ

I’ve not run into any issues, but come to think of it, the SCSI CD-ROM drive attached to my PDP-11/73 is capable of 512-byte blocks. IIRC, the older DEC HW, just like the older Sun HW requires 512-byte blocks.

Zane

[Paul Koning]

Post by Zane Healy
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.
Zane

Could you describe how you built the RSTS/E CD? It should be possible. If nothing else, with the -merge switch in FLX 2.6 -- which creates a hybrid structure that looks both like a CD file system and a RSTS file system, boot block and all.

paul

[Paul Koning]

Paul, I have never made a bootable RSTS/E CD, but I might suspect that it is picky about being booted from read-only disk media.
(I remember last version of RSTS/E bootable install tape wouldn't boot unless the write ring was on! That's one of the reasons I put this in the "picky" bucket!)

Other way around. If you're booting a magtape, it requires the ring to be absent.

paul