On Sat, Jan 9, 2021 at 12:08 PM David Gesswein via cctech < cct...@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 <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. > > > > > > > > > ------------------------------ >
