Got DSM-11 running, any manuals online?

[Chris Zach]

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