• Please review our updated Terms and Rules here

Replacement firmware or downloadable code for RQDX3 to support FM RX01

Oldcoder

Member
Joined
Feb 28, 2021
Messages
49
The RQDX3 has a 9224 disk controller chip. Looking at the 9224 datasheet, the chip itself supports both FM (single density) and MFM modes of operation. AFAIK the T11 firmware on the RQDX3 only supports MFM mode. Is anybody aware of either replacement firmware that also supports FM mode or of downloadable code that does the same.

I would like to connect a BASF 6104 8" drive (Shuggart interface) and use it to access some RX01 disks using one of Mal's BOB boards.

AFAIK the RXV11 Qbus card is not compatible with a Micro 11/73 and even if it was would still leave emulating the RX01 drive electronics with the BASF drive.

Any suggestions?

Thanks

Peter
 
I've never seen or heard of any other firmware for the RQDX3. I could be wrong, but I doubt it exists. And you'd probably need to do a lot of trickery all over the place, in addition to any fixes of the controller itself.
Any software/OS would expect the floppy port of the RQDX3 to talk to an RX50 which holds 800K. An RX01 only holds 128K (or was it 256K?). Hmm, not sure exactly how this worked with the RX33 that I think was also possible to hook up... Maybe someone else have more detailed knowledge?

I doubt you'll ever get this sorted that way. Your best bet is either finding an RXV11 (it will work on an 11/73) along with a real RX01, or find a third party controller which talks to more random 8" floppy drives, and looks like an RX01 controller.

Or if you just want the content of a few disks you have, find someone else with a setup that can dump the floppies for you.
 
77x1x26 sectors. RX11 - 128 bytes per sector (256 kb), RX211 - 256 bytes per sector (512 kb)

Thanks. Seems I can never remember the capacities.

But I should also point out that the RX11 and RX211 are the controllers and not the drives. And an RX211 can be hooked up to either an RX01 or RX02.
 
Thanks

As I understand it, DEC has a 3 component solution for 8" floppy disks:

1) RXV11 / RXV211 Qbus interface with some of the controller functionality.
2) A board inside the RX01 or RX02 enclosure with the rest of the controller functionality (This is different to the non-DEC world where the floppy controller eg 9224 / WD17xx / WD27xx / WD37C65 directly connects to the Shugart 800 type interface on the drive mechanism)
3) A DEC 8" Drive mechanism either RX01 or RX02 with analogue and motor driver boards.

Items 2 & 3 are inside the standard RX01 / RX02 chassis.

The MSCP RQDX3 works more like a standard controller talking directly to the 5.25" or 3.5" floppy drive via a pin swapping breakout board. I was hoping to modify the T11 code to support FM and use a tweaked version of the MSCP driver to tell the OS RT11 / RSX how big the disk was, similar to the tweaks for different MFM hard drives.


The Qbus I/O ports and bit definitions are well defined for MSCP RQDX3, RXV11, or RXV211.

What ends up on the disk media is also relatively well defined.

Mention was made of non-DEC RXV(2)11 Qbus cards that directly support standard non-DEC drives, please suggest some makes / models.


BQT,
What do I need to do to put a RXVn11 Qbus card into a Micro PDP 11/73 together with the existing RQDX3 controller. I read that there was an incompatability between the RXVn11 cards and Micro-PDP11/73? - Backplane changes / card order / special config considerations please.



Peter
 
CHD on his web site defines some limited compability of RXV211 and Micro-PDP-11/73. Requiring late revision boards.

"Hardware Compatibility - RXV21 and the PDP-11/73


The RXV21 (M8029) must be the latest revision level to be compatible with a microPDP-11. The board is PN 5013080 with a suffix C or D to indicate etch level. Etch level C has a large number of ECO jumpers and does not function in a microPDP-11. (Etch C, Rev Unknown, component side. Etch C, Rev Unknown, solder side.) Etch level D eliminates most of the ECO jumpers, but does not necessarily function with a KDJ-11 processor. I believe that the last revision to the M8029 is F and that this is equivalent to print revision J. (Etch D, Rev F, component side. Etch D, Rev F, solder side.) The schematics below show the jumpers that must be added to an etch level D board, but do not show the trace cuts. Three cuts are necessary to get an etch level D board functional at M8029 rev F: one on the component side (Etch D, Rev F, component side marked with red circle) and two on the solder side (Etch D, Rev F, solder side marked with red circle)."
http://www.chdickman.com/rx02/

There is no mention of RXV11 compatability.

Does anybody know what the changes required are?

Thanks

Peter

 
Thanks

As I understand it, DEC has a 3 component solution for 8" floppy disks:

1) RXV11 / RXV211 Qbus interface with some of the controller functionality.
2) A board inside the RX01 or RX02 enclosure with the rest of the controller functionality (This is different to the non-DEC world where the floppy controller eg 9224 / WD17xx / WD27xx / WD37C65 directly connects to the Shugart 800 type interface on the drive mechanism)
3) A DEC 8" Drive mechanism either RX01 or RX02 with analogue and motor driver boards.

Items 2 & 3 are inside the standard RX01 / RX02 chassis.

The MSCP RQDX3 works more like a standard controller talking directly to the 5.25" or 3.5" floppy drive via a pin swapping breakout board. I was hoping to modify the T11 code to support FM and use a tweaked version of the MSCP driver to tell the OS RT11 / RSX how big the disk was, similar to the tweaks for different MFM hard drives.


The Qbus I/O ports and bit definitions are well defined for MSCP RQDX3, RXV11, or RXV211.

What ends up on the disk media is also relatively well defined.

Mention was made of non-DEC RXV(2)11 Qbus cards that directly support standard non-DEC drives, please suggest some makes / models.


BQT,
What do I need to do to put a RXVn11 Qbus card into a Micro PDP 11/73 together with the existing RQDX3 controller. I read that there was an incompatability between the RXVn11 cards and Micro-PDP11/73? - Backplane changes / card order / special config considerations please.



Peter

If we limit ourself to Qbus here (there are obviously also controllers for Unibus as well as Omnibus), then yes, what you describe is accurate.

The RQDX3 have a more normal floppy interface connector, so indeed, from that point you should be able to hook up various things. I don't know exactly what the RQDX3 would do if you hooked up anything but an RX50 or RX33 though, as those are the only ones defined to work. In general, MSCP always have a function to tell the capacity of a drive, and the floppy port is also exposed as a MSCP disk. But at the same time, the OSes do know about this floppy specifically, and it is not just managed like any other MSCP disk in all aspects.
So I do worry about things like what capacity it would be assumed to have at the OS level, because I don't know if they get it over MSCP, or if it is just fixed/known.

The MSCP protocol is rather complex, so writing your own firmware to do this on the RQDX3 would be a very complicated task. The I/O registers are dead simple, but that is partly because almost all communication between the CPU and the controller is not happening over those registers, but through shared buffers in memory that the controller access through DMA.

The RXV11/21 on the other hands is a simple, straight forward controller with a few I/O registers, and all operations are done through those. Nothing much to say really.

As for third party, compatible controllers, there were various different ones. A quick look on bitsavers turned up this one: http://www.bitsavers.org/pdf/plessey...floppyCtlr.pdf for example. RX01/RX02 compatible, use any shugart interface drive.

Finally, the issue with the RXV21 in an 11/73. It's simple, actually. The problem stems from the fact that the RXV21 is a DMA device, but it is one of a few that only do 18-bit DMA addressing on the Qbus. The RXV11 do not have this problem as it don't do any DMA to start with. But the solution is just to use a bounce buffer, and RSX do this already. No hardware changes or anything is neccesary. It's just that DMA from the floppy need to go into the first 256Kbyte of memory. So the OS need to make sure this happens, and then it can copy the data over to the final destination, when reading. Or, when writing, first copy the data down somewhere in the first 256K, and then do the I/O operation.
I would expect that both RT-11 and RSTS/E also already handle this. But if you write your own software, you need to be aware of this, or bad things might happen.

Not sure where CHD got the rest of his information from. Apart from the 22-bit DMA issue, the 11/73 isn't different than an 11/23, which obviously should work with any revision RXV21. That there were different revisions is nothing new. That just meant that they cleaned the design up. The earlier revisions should also work, as long as any neccesary ECO have been applied, which I would expect to be the case.
 
Last edited:
I don't know if it's worth mentioning, but I'll mention it only because I just got a pile of RX02 floppies in. Although described as "MFM", they're not quite standard MFM. Rather, the ID headers are encoded as standard FM, but the data blocks themselves are "DEC-funny" MFM. That is, they're MFM, with certain substitutions to avoid triggering the FM AM detection. As far as I know, DEC was the only vendor to do this.
 
I don't know if it's worth mentioning, but I'll mention it only because I just got a pile of RX02 floppies in. Although described as "MFM", they're not quite standard MFM. Rather, the ID headers are encoded as standard FM, but the data blocks themselves are "DEC-funny" MFM. That is, they're MFM, with certain substitutions to avoid triggering the FM AM detection. As far as I know, DEC was the only vendor to do this.

Right. Which also means if the OP really have actual RX02 floppies to read, then any normal shugart controller is not going to be able to deal with them at all.
 
The giveaway is that tools such as IMD will show the FM sector IDs in the "alignment" function, but otherwise be blind to the data; i.e., the READ ID function works, but READ does not.
 
I don't know if it's worth mentioning, but I'll mention it only because I just got a pile of RX02 floppies in. Although described as "MFM", they're not quite standard MFM. Rather, the ID headers are encoded as standard FM, but the data blocks themselves are "DEC-funny" MFM. That is, they're MFM, with certain substitutions to avoid triggering the FM AM detection. As far as I know, DEC was the only vendor to do this.
Datapoint also did this on the 15x0. When we did the 1550 CP/M at Lifeboat, we included a formatter for this oddball format (possible because the 17xx controllers just write a raw bit pattern from memory to a disk track for formatting. 765-family controllers can't do this because you tell them "I want X sectors of size Y with interleave Z" when you format. This caused great consternation / panic at Datapoint because a large portion of the product's revenue came from selling pre-formatted media. The format utility was removed from the CP/M implementation before it shipped.

Trivia: The 1550 was a 1500 with minor modifications to move its boot ROM out of low memory so it could run standard CP/M. The development machine we had was a 1500 with cuts & jumpers and the 1500 nameplate removed. Lifeboat was the major (only?) proponent of a modified CPM which was based at (IIRC) 0x2000 instead of 0x0 so that it would run on machines with ROM in low memory/ The most famous of those was the Heathkit H8. It was an uphill battle getting software authors / publishers to support that.

Further trivia: My engineering contact at Datapoint for the 1550 CP/M project was Steve Wood, one of the "Microsoft 11" in the famous "Would you have invested" photo (top row, left).
 
The RQDX3 has a 9224 disk controller chip. Looking at the 9224 datasheet, the chip itself supports both FM (single density) and MFM modes of operation.
Does the 9224 have an onboard data separator? If not, the external data separator circuitry may not support / be configurable to handle FM.
 
Apart from the 22-bit DMA issue, the 11/73 isn't different than an 11/23, which obviously should work with any revision RXV21.
Possibly my non-ECC memory has dropped multiple bits (4 of 'em!) but aren't the KDF11-A (Rev C or higher) and all KDF11-B Q22 processors? They can still use a bounce buffer as you describe for the 11/73
 
Possibly my non-ECC memory has dropped multiple bits (4 of 'em!) but aren't the KDF11-A (Rev C or higher) and all KDF11-B Q22 processors? They can still use a bounce buffer as you describe for the 11/73

You got me on that one. Exactly which revisions of the KDF11 boards were 11/23 compared to 11/23+ is not something I've tried to keep track of. Which is why I just said 11/23. Obviously, a proper 11/23 would be 18-bit only. The 22-bit capability came with the 11/23+. :)

But yeah, for the 11/23+ you also need the bounce buffer, and then you're all good.
 
Datapoint also did this on the 15x0. When we did the 1550 CP/M at Lifeboat, we included a formatter for this oddball format (possible because the 17xx controllers just write a raw bit pattern from memory to a disk track for formatting. 765-family controllers can't do this because you tell them "I want X sectors of size Y with interleave Z" when you format. This caused great consternation / panic at Datapoint because a large portion of the product's revenue came from selling pre-formatted media. The format utility was removed from the CP/M implementation before it shipped.

Don't think I follow--there are a few codes in the 177x and 179x that can write specific AMs with missing clock bits, but they're fairly restricted. The 1781 is the exception, but it's a "roll your own decoder/encoder" chip and not very common. My WD databook from 1984 doesn't even cover the 1781. It was a bit buggy and not popular. Among it's other "interesting" capabilities was the alternate interpretation of the "N" byte in CHRN address headers. You could have a disk with 64 byte sectors, for example.
 
Obviously, a proper 11/23 would be 18-bit only. The 22-bit capability came with the 11/23+. :)
PDP-11/23 - KDF11-A
PDP-11/23+ - KDF11-B

KDF11-A rev A support 18 bits
KDF11-A rev C and later support 22 bits
I have two KDF11-A and they can work with 4088 kb of memory

KDF11-B support 22 bits
 
Back
Top