• Please review our updated Terms and Rules here

Imaging DEC VMS CDs - Block size considerations

Mal

Experienced Member
Joined
Apr 3, 2008
Messages
91
I've just been messing around with imaging some original DEC VAX/VMS CDs (original distributions of the operating system). I was expecting that making ISO files of the original CDs, and then burning those ISOs back to blank CD-R disks on a PC would require an optical drive that has a block-size jumper. I assumed this because I thought that PC drives expect media to have a block size of 2048 bytes, and VAX machines expect media to have a block size of 512 bytes.

Anyhow, I'm a little confused because I've just been using a SATA DVD R/W drive in a cheap modern-ish desktop system, and to my surprise I was able to successfully make an ISO of a VAX/VMS 6.1 CD in that drive (and "install" VMS from that ISO in a VAX simulator in SIMH) and then write out the ISO in the same drive to a blank CD-R disk (which I then used to successfully install VMS 6.1 on a real MicroVAX 3100 Model 90).

What I don't understand is why this worked. Have modern optical drives become sufficiently intelligent that they can figure out (or fudge?) block size, or has block size always been irrelevant to reading and writing ISO images to/from CDs (perhaps it's only relevant to accessing files within the ISO image)?

(the imaging was done under Ubuntu 14.04 using command line tools. "dd" was used to read the original CD, and "wodim" was used to write the ISO out to a blank disk. I've documented the process in some detail here -> http://avitech.com.au/?p=605).
 
Are you really sure of the format of the CD's?
I'm not sure block size matters in this case.
If they confirm to ISO 9660 with or without extensions, almost any operating system that had a CD-ROM drive available should be able to read it.
 
VMS CD's don't necessarily use the ISO 9660 filesystem. However, that doesn't prevent you from making a binary image, calling a ".ISO" and burning it with ISO tools. The same thing is true for other OS CD's that are not ISO-filesystems, like SGI IRIX CD's. You can treat them as 'ISO images' for bit-for-bit copying purposes, but they aren't actually ISO9660 filesystems.

My Hobbyist OpenVMS CD's are ODS-2 filesystem archives, as far as I recall, and there are tools to deal with them at a filesystem level in Linux.

As to the blocksize, that isn't important except on the actual VAX (or other machine requiring the 512 byte blocks), in my experience.
 
If DEC didn't implement some goofy copy protection, like the map CDs for my truck's navigation system use, I'm not surprised you could copy them in a modern PC.

-J
 
IIRC, DEC didn't bother with copy protection because the whole licensing system makes that pretty much irrelevant. You can freely copy the CDs all you want, but you'll still need a license to activate non-bare-bones mode.
 
VMS CD's don't necessarily use the ISO 9660 filesystem. However, that doesn't prevent you from making a binary image, calling a ".ISO" and burning it with ISO tools. The same thing is true for other OS CD's that are not ISO-filesystems, like SGI IRIX CD's. You can treat them as 'ISO images' for bit-for-bit copying purposes, but they aren't actually ISO9660 filesystems.

My Hobbyist OpenVMS CD's are ODS-2 filesystem archives, as far as I recall, and there are tools to deal with them at a filesystem level in Linux.

As to the blocksize, that isn't important except on the actual VAX (or other machine requiring the 512 byte blocks), in my experience.

^^^^^^ This. When you use dd to read a device to a file and then copy the file back to a CD, the block size doesn't matter. The writing tool takes care of getting the image data on the CD, but it does no internal formatting. As long as the CD drive in the VAX is able to communicate in 512 byte blocks then you are fine. Internally, the CD will still be in ODS-2 format, but your tools never know and don't care.
 
Back
Top