Got DSM-11 running, any manuals online?

[David Gesswein]

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.

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