Imaging SMD drives

[antiquekid3]

I have an Emulex QD34 SMD controller in my MicroVAX 3800. Given this arrangement, what is the easiest procedure for producing a bit-for-bit image of an arbitrary SMD drive? The VAX is running VMS 5.4 and also has a CQD-223/TM for SCSI, perhaps opening up the possibility of imaging the SMD drives to a ZuluSCSI?

Also, does anyone have the docs for the QD34? I see the QD33 and QD35 on Bitsavers, but not the QD34.

I also have an 11/73 with an SMD interface, but it's not accessible right now, but could be a possibility in the near future for additional experimentation.

 

[Terri Kennedy]

I have an Emulex QD34 SMD controller in my MicroVAX 3800. Given this arrangement, what is the easiest procedure for producing a bit-for-bit image of an arbitrary SMD drive?

You may not be able to, for a number of reasons. [E]SMD drives can be configured with an arbitrary number of sectors, often ranging from as low as 64 bytes to a single sector spanning the entire track. "Runts" (less than full-size sectors at the end of the track) can either be suppressed or passed to the controller when requested. Your QD34 is likely a MSCP-emulating controller with its own idea of bad block management and likely requires a specific sector size to be configured on the drive, and likely a controller-based disk format operation as well.

Sector sizes include preamble, header data, gap, user data, gap, checksum, postamble. So for 512-byte host sectors you may need to set (as an example) the drive sector size to 570 bytes.

Data rates on [E]SMD drives are very slow by modern standards, and in theory it should be possible to build something that will select each cylinder and head and get the raw track data from the B-cable. Someone may have even built something already to perform that task. Of course, you then need to interpret the raw data to make sense of it.

When attempting anything like this, it is important to physically write-protect the drive if possible. If it isn't possible, the cables could be probably be modified to never assert the write enable line.

 

[Bitly]

Also, does anyone have the docs for the QD34? I see the QD33 and QD35 on Bitsavers, but not the QD34.

User's guide is on archive.org.

CW

 

[MattisLind]

SMD (and ESDI) is tricky since the controller need to understand the format and issue proper commands to the drive on the right time. It is not readings bits since the PLL and data separator is on the drive. Whenever there is a write-splice read need to be disabled som bits in advance and then it need to resync afterwards. Just taking an arbitrary SMD disk and attach it to a DEC controller wouldn't work as far as I understand. But I haven't tested so I can be wrong.

Another thing with SMD is that they can be hard sector (the old CDC SMD / CMD or the like are hard sector). Later were selectable hard sector or soft sector.

My opinion is that it is better to check this project: https://github.com/cwsimmons/esdi_interface

Get in contact with him and create a SMD interface board. Then It think with some fiddling in the firmware it might be possible to read SMD disks as he does with ESDI.

 

[antiquekid3]

My opinion is that it is better to check this project: https://github.com/cwsimmons/esdi_interface

Thanks! I've been in touch with Chris and will see what we can do over the next couple of months.

 

[alexwill]

SMD definitely feels like deep-end territory compared to more modern interfaces, especially with all the controller-specific formatting expectations and the variability in sector structures.