Got DSM-11 running, any manuals online?

[Warner Losh]

On Sat, Jan 9, 2021 at 12:08 PM David Gesswein via cctech <
cctech at classiccmp.org> wrote:

> To possibly be clearer the image of the disk was a raw dump of the disk
> taken with the mfm emulator/reader board so it sees all the extra data the
> controller puts on the disk and the bad sectors etc. As far as I know no
> documentation exists of the low level format and revector table etc. For
> RQDX3 the controller has extra information at the beginning of the disk so
> mounting the raw image under SIMH doesn't work. The RQDX2 apperently puts
> its
> information at the end.  Might be possible to reverse engineer the format
> if we get sector dump from the host to compare to the raw disk dump.
> Nobody
> has decided to tackle that.
>
> For the dump of my RD53 on Vaxstation RQDX3 head 0 sectors 0-2 are normal,
> 3-16 are funny format. Head 1 and 2 are all funny format. Head 3 sectors
> 0-2 are funny format. Removing those didn't work for me if I got my
> dd commands correct.
>

DEC standard 144 of any help?
http://bitsavers.org/pdf/dec/standards/EL-00144_B_DEC_STD_144_Disk_Standard_for_Recording_and_Handling_Bad_Sectors_Nov76.pdf

Warner

On Fri, Jan 08, 2021 at 09:29:19PM -0500, Chris Zach wrote:
> > If so, then that's probably what the RQDX1/2 format *was*: Just a big
> bunch
> > of 512 byte blocks, starting at zero and going up to the top.
> >
> > The controller had to know the geometry of the drive in order to move the
> > heads, know how many cylinders there were, etc. One thing I did notice is
> > the last cylinder of the disk is not formatted like the others and
> throws a
> > bunch of errors on the MFM_READ command on all tracks. It's possible that
> > the controller checks there first, then consults the ROM based lookup
> tables
> > to get the proper disk geometry. Which explains why some controllers
> > supported RD51,52 and later ones supported the 53 but none supported the
> 54.
> >
> > On the RQDX3 formatted disks, the first few tracks are also in a weird
> > format, it's possible that is where the controller stores the
> > head/cyl/sector format information. Note that a RQDX3 disk image does not
> > seem to be able to connect up to the RQ driver like the RQDX2 one.
> >
> > Interesting stuff. I'm guessing if you remove the first couple of tracks
> > from the file one could then read the rest of the disk on SIMH (as the
> rest
> > is probably just a big pile of blocks and that's all that matters to
> SIMH)
> > unless there are remapped sectors in which case I have no idea how those
> > would work.
> >
> > Fun stuff.
> > C
> >
> > On 1/8/2021 8:54 PM, Eric Smith via cctalk wrote:
> > > On Fri, Jan 8, 2021 at 6:16 PM Chris Zach <cz at alembic.crystel.com>
> wrote:
> > >
> > > > True, however SIMH has to write things to a "real" file that emulates
> > > > something of a disk.
> > > >
> > >
> > > I thought the SIMH representation of an MSCP disk was just a linear
> array
> > > of 512-byte blocks, from block 0 to block n-1, in which case, it's
> still
> > > not at all surprising that any RQDXn, or any other MSCP disk with the
> > > standard Unibus/Qbus MSCP port interface would "just work".
> > >
> > > If I'm wrong about how the disk is represented by SIMH, then maybe it
> could
> > > be more surprising.
> > >
> >
> >
> > ------------------------------
>