• Please review our updated Terms and Rules here

RD32 usable blocks puzzle

leegleason

Experienced Member
Joined
Jan 20, 2014
Messages
140
I've been working on writing VAX code that accesses RDX3s and drives directly, without a driver. It's been going pretty well. There's a great reference docco, http://www.bitsavers.org/pdf/dec/dsa/mscp/Mass_Storage_Control_Protocol_Ver_2.4.0_Jun92.txt if anyone else needs to work at this level.

I've gotten disks to come online, read and write fine. Next step, I wanted to copy an RD32 SIMH image to a real RD32 using these routines. First, I formatted the RD32 using ZRQC?? on an 11/73. Then I moved it over to a VAXstation where I have the RQDX3 programs. It seemed to write OK, but stopped 32 blocks short of the complete disk image. More investigation showed that the RQDX3 thinks the disk is 83204 blocks long. Writes start failing when I get to the 83205th block. Test reads fail at that point as well. Pretty much every source I could find agrees that RD32s have 83236 blocks available for use Here's a look at the end code block for the MSCP ONLINE command of this disk.

command reference 00000000
unit number 0000
sequence number 0000
end code 89 (80+9, means end packet + command 9, ONLINE)
flags 00
status 0000 (0 is success)
multiunit code 0000
unit flags 8000 (indicates that controller will handle bad block replacement)
spindles 00 (# of spindles this unit, -1)
reserved 000000
unit identifier 020F000000000000 (02 = disk class, 0F = model rd32)
media type 25644020 (translates to DU RD32
reserved 00000000
unit size 00014504
volume serial # 00BC614E (12345678 decimal, the serial # I formatted it with)

Most of this looks pretty legit,. The unit size field, though, indicates that the RQDX3 and/or RD32 think 14504 hex,83204 decimal is the users block count - that's 32 blocks short of everywhere else.

So, long story short (I know, too late for that), I'm wondering if anyone else has encountered a situation working with MSCP disks, where a smaller than expected number of usable blocks is reported - and if they figured out why...
 
The RQDX3 steals some blocks (from the beginning of the volume, iirc) to store drive geometry information. this is how it knows the drive is an RD32 and not, say, an RD54. might that account for the 32 block deficit?

This block-stealing is the reason that you can't freely move a disk drive between an RQDX1/2 and an RQDX3.

Also the RQDX3 does automatic bad block replacement, so presumably it reserves some blocks for that as well. I don't know how many or where it puts them though. Probably just past the logical end of the volume.
 
Last edited:
kgober might have given the answer to this question.

I should also point out that no (normal) DEC software have any idea or knowledge of disk capacity based on any identity for MSCP disks. All software only makes use of the actual size reported when the disk comes online.
(Controller firmware and diagnostics might maybe know/do something based on identities...)
 
I'm starting to suspect that simh's RQDX3 emulation is doing something...different than a real RQDX3. regarding the non-user-storage blocks, at least for an RD32. I'll have to hand load my program into simh and see what the endcode block says about the disk size there.
 
I'm starting to suspect that simh's RQDX3 emulation is doing something...different than a real RQDX3. regarding the non-user-storage blocks, at least for an RD32. I'll have to hand load my program into simh and see what the endcode block says about the disk size there.

Well, simh don't really emulate what a real rqdx3 is doing at all. It just uses a file with the exact size the disk is supposed to have, and then append some meta-information for simh beyond that. There is no bbr handling or storage, nor geometry information, which a real rqdx3 would store. There is no need.
The simh rqdx3 won't pass diagnostics. It's just doing what is needed for normal software usage.
A real rqdx3 can only be used with a certain limited set of actual hard disks. The one in simh can essentially be thrown any disk image, and it will happily use it, and report that size to software.
 
I don't expect simh to be a microcode perfect emulation of an RQDX3. But I think it is intended by the developers that it function like a real one at the user level. Here's a test I just did, that leaves out my disk copying application, that makes me think it, isn't doing that, at least for RD32s.

Using a simh MicroVAX, I just created an RD32 (set rq3 rd32, att rq3 rd32test.dsk). Then used VMS on that simh MicroVAX to INIT it as a normal ODS-2 disk. SHO DEV/FU showed it to have 83236 total blocks. I shut down VMS and ran my RQDX3 test program, that does an MSCP ONLINE and a few READs and prints the endcode blocks. It also reported 83236 blocks, and could read the 83236th block. Booting VMS again, I filled up the disk and used DUMP to confirm thatuser file data gets stored all the way up to the 82236th block.

To compare with a real RD32 (using what's easily at hand today), I connected a real RD32 I usually use for RSX, to a real MicroVAX with an RQDX3. It was formatted with ZRQCH0, and had RSX installed on it. I ran my test program on it. The ONLINE endcode block reported 83204 blocks, and the reads attempted after that block failed. I would have expected that the disk sizes in the real case and the virtual case would be the same (and if they were, it would let me use simh to easily create virtual disks for this project).

As a slightly better test, I'm assembling enough of this junk to boot VMS on a real MIcroVAX, and use it to INIT a real RD32, and see what the VMS reported and ONLINE max number of user blocks is in that case. I suspect, that it will be 82304 for both.
 
Well, the "problem" is that the RD32 created in simh is just whatever size the author of that piece of code in simh thought an RD32 have. And that is all there is to it.
The create command creates a disk image with an assumed size that an RD32 have. How do they know the actual size of an RD32? Could be from reading some data about the MFM drive, without any understanding of how much space the RQDX3 reserves for its own use (not sure that is even properly documented anywhere). And it don't really matter in real life, since any OS would just use the size provided by the controller anyway. You can really create a disk of any size in simh, and it will work just fine. The actual size will be reported back the disk is brought online. RQDX3 it itself is really just an ID field in the MSCP communication as well. Normal software don't even care what kind of a controller it is. All that matters is that it talks MSCP, and it just works based on that.

The RQDX3 is not a normal MFM controller. It's an MSCP controller. Which means that the whole disk size and geometry are abstracted away and hidden from software. You can really create a disk with any size in simh, and hook that up to the simulated RQDX3. Because an MSCP controller in general can have disks of arbitrary size. It's an internal limitation that the RQDX3 only understands a few MFM disks, and implements MSCP properties on a type of disk that at the MFM level really do not work the way MSCP presents. And obviously simh don't simulate the internal oddities of an RQDX3.

In the end, yes, it would appear that a real RD32 hooked to an RQDX3 really only have 82304 blocks.

So, either fix simh, or create your disk with that explicit number of blocks, and then you will be good if you want to move it over to a real RD32 later.
 
Yajh, I agree - looks like a simh bug. Looks lie it's in pdp11_rq.c, line 558. They used 83236 when they needed to use 83204. Crazily enough they used the right value in a comment at line 258. For completeness' sake, I'll report it to 'em. I doubt it will be a priority - I'm probably the only person on the planet still messing around with RD32s, real or virtual. And I'm hip how MSCP works, thanks- I've been working with nothing but for the last several months...
 
MSCP is really nice in many ways. Funny that simh would have the correct value in a comment, but the wrong value in the actual code.

And yes, you might be the only person caring about an RD32. Personally, I just create 8G disk images for simh to use with my emulated RSX systems (I actually use >8G drives on my real RSX systems as well).
RSX truncates the disks at 8G, though. So no point in emulating anything bigger right now.
 
"I have an RD32 in my Decmate II. :):"

Hail Friend! Well met! At least ST-251's are still relatively available and relatively cheap.
 
Hi. I am planning to image it to using Dave Gesswein's MFM tool. That way I can use it instead of this drive. I don't think it has longer to live if it has anything. Haven't gotten far enough to be able to try booting from it. Don't know much about Decmates actually. Never had one till now. Good to know they are still available I guess.
 
"I am planning to image it to using Dave Gesswein's MFM tool." I have one of those I use that replaces an RD54 on another system here. Works great.
 
Back
Top