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