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