The Pro also has 16 sectors, that's a limitation of the sector address register. I know the Pro format is different than the RQDXn format; the latter is larger presumably because of more sectors per track. So that would fit. paul

These links may help: http://decvax.50megs.com/doc/rqdx/rqdx.html <http://decvax.50megs.com/doc/rqdx/rqdx.html> http://www.vcfed.org/forum/archive/index.php/t-47834.html <http://www.vcfed.org/forum/archive/index.php/t-47834.html> http://web.frainresearch.org:8080/projects/pdp-11/diskcntl.php <http://web.frainresearch.org:8080/projects/pdp-11/diskcntl.php> There?s definitely incompatabilities between the RQDX2 and RQDX3. They shouldn?t be assumed to be designed or act similarly, despite their names. The only similarity is that the RQDX3 can read the same floppy disks as the RQDX2 formats.

It makes sense: The 1/2 used interleaving, which would have required extra code in the 3 to support. The 1/2 figured out the disk geometry based on ROM lookups, the 3 stored the disk geometry on the disk. That meant you didn't have to worry about ROMs and technically you could use pretty much any MFM disk with less than a certain number of heads and cylinders. What I realized mentally is that from the OS/driver/register level they are identical. So while the physical disk format is different, there should be no reason I can't hook up an RQDX2 to the DSM disk, fire up PDPGUI, select the drive as a DU: type, suck the data into a file over a serial connection, and boot it on SIMH without any issues. True, and I can download P/OS, dig out the PC with a 1.2mb floppy, and make the floppies on these Micro-RSX11M floppies I have in a box but man it's 30 floppies of *stuff*. Technically I see there is a disk writer utility for the Pro/POS somewhere so I *could* download that to the Pro, download the disk images, and copy them one at a time. Or maybe I could use this Dave G MFM emulator to emulate an RX50, then just present the disks over and over till install is done. Hm.... C

I don't know about FreeBSD, but you don't need special drivers on DOS or Linux. In DOS, it's just some int 13 magic. In Linux, it's an ioctl to set the floppy layout. I did this a long time ago for my "flx" utility (RSTS file access on a PC). The initial version was for DOS, and that code should still work. I added Linux support later. There are two versions of this code: one in C (flx 2.6) for DOS and Linux; that one on Linux needs to have the layout set via a Linux utility first. The other is flx 3.0 which is written in Python; it handles everything directly. That version also includes a separate utility that just does interleave or de-interleave of 800 block disks and container files, so you can create a SIMH compatible disk image from a floppy, or a Xhomer interleaved layout image from a regular (logical order) image. That simply uses the disk access code from FLX with the file system pieces left out, so it isn't specific to RSTS. In my experience (admittedly only on a few PCs I have had that include a 5.25 inch floppy drive) both reading and writing work with no trouble at all. For my Pro development I've always used floppies as the transfer medium, which means creating bootable RSTS disks on the PC. Works fine. paul

On Tue, Jan 5, 2021 at 9:20 AM Paul Koning via cctalk <cctalk at classiccmp.org> wrote: I think it's more of a case that DEC completely rolled their own controller for the RQDX1/2 and gave it and went with a standard (SMC) controller for the KA410 (uVAX 2000) and the RQDX3. I have no specific knowledge of their process, but it seems likely that they had two engineering goals around the same time: make a lunchbox VAX and create the follow-on hard disk controller for Qbus MicroVAXen that could support larger disks than the RQDX2, and that one effort likely borrowed from the other (why reinvent two wheels at once?). The fact that you had to toss out your old RQDX2 to put a larger disk in the machine was already a given so there was no need to support a backwards-compatible on-disk format. I'm just happy that the KA410 and RQDX3 have compatible formats. That's been handy over the years. I do have one uVAX I with an RQDX1 (that I should probably see about imaging, but as mentioned, it's easy enough to use vtserver - just pull the KA610 processor and install a KDF11 or KDJ11 board (and a grant card) at the top. -ethan

On 05/01/2021 11:47, Joshua Rice via cctalk wrote: The RQDX3 definitely uses a T-11 (the controller User Guide says so). I don't know what the RQDX2 uses, although Wikipedia says that uses a T-11 too. They can use (at least) some of the same RDxx disks but the format is incompatible between the two AFAICR. So you could move an RD53 (say) to use it: you could not read data written by an RQDX2 on an RQDX3 (again, AFAICR). I think that the (even older) RQDX1 was very similar to the RQDX2 but had a design fault that meant it had to be the last module on the bus (it failed to pass on the grant signal, I think). Antonio -- Antonio Carlini antonio at acarlini.com