[Simh] Looking for clues: MAKECD; CDROM format?

[Timothe Litt]

On 10-May-15 21:35, Clem Cole wrote:
>
> On Sun, May 10, 2015 at 5:47 PM, Timothe Litt <litt at ieee.org
> <mailto:litt at ieee.org>> wrote:
>
>      It might be Ultrix CDFS - anyone know that format/a linux tool?
>
>
> This question is causing some random bits in my memory FS to slowly be
> retrieved but have not been active for 20+ years I fear.   ;-)
>
> My memory is that Ultrix CDFS was strange for a UNIX FS or CDs and
> some of what you describe sounds about right.  IIRC Ultrix used 512
> bytes for the block size, when "normal" CDs used 1024.  We had a funky
> Unix system in ZK which we used to write the CD masters for ultrix and
> VMS - I want to stay it named Young something (youngbloods so some
> such - I've forgotten).  Again, Armando may remember - but I think Fed
> Cantor did hte interfacing,
>
> I remember, you had to have very special media to write them, in those
> days since the CD writers were not forgiving.   It took a source media
> created a CD image on a raw disk first with whatever parameters you
> were using for the CD like block size, then did a bit map copy from
> the disk to the CD and IIRC correctly we used an funky ANSI tape
> program to write the masters.
>
> Standard ISO CD were's 1024 bytes, but could not handle Unix or VMS
> style file attributes.  So Ultrix did not use the ISO format, as folk
> has support for for full case, extended file attribute etc of UFS etc,
> i.e it was before rockridge extensions were standardized for ISO.   By
> the time of Tru64, Rockridge was standardized for the Unix community
> (and ISO) and I think that was some how used, but I pretty sure Ultrix
> did not. 
>
> But I do think the DEC tools of time to write most CD's were based on
> Ultrix which interfaced to the box in ZK.   I looked for some docs on
> the ultrix format, I had at one time, but can not find them.  I'll
> keep looking, but I fear I lost much of that in the flood in my old
> condo about 25 years ago.   I'm going to have dinner with another pack
> rat tomorrow night and I will ask him if he thinks still has any of
> the Ultrix docs stuffed away.  If I can find it, I'll try get it
> scanned and pass it on.
>
> Clem
>
Thanks.

That all sounds about right.  Except that the standard sector size for
CDROM is 2048 (usable, after EDC).
There's also mode 2, which is 2336 usable, with no EDC. DEC wouldn't
have used that.

VMS read the 2048 byte sectors, and the device driver mapped the 512
byte LBNs to the right fractional sector. 
VMS also could put its (FILES-11/ODS) file structure on a CD - actually
many Pathworks & DOC CDs were dual-format;
Both the ISO9660 & FILES-11 structures were present, and because the
mount processes look for the filesystem
root in different places, everything just works.  Perhaps Ultrix does
the same thing to present 512-byte LBNs.
I suppose it might have written true 512 byte sectors - but I'm not sure
that works with the readers.

We (my 36-bit hat) probably just wrote the ANSI tapes & sent them to ZK.

I wonder if what I have is a text header (perhaps for the label?) + data
in "compress" format.  LZW would explain the
occasional few bytes of cleartext.  So maybe one dd's the header off to
one file, then dd's the rest of the file thru
compress?  The ASCII hex "4b9c4" is 309700.; perhaps the size of the CD
data?  If in 2K sectors, that would be
~634MB, or about the size of a CD.  The extracted binary (assuming I got
that right) is 171M, which would be ~3.5:1
compression.

Hmmm, the last cleartext is at 7f6, then at 800 the binary starts.... 
If I dd  skip=4, the resulting file isn't
a recognizable format. (and so not compress.)  But it this feels like
the right track.  

In any case, if all this is correct, the format of the "funky ANSI tape"
is also interesting, as I guess
that's what I have.

Not that archeology isn't fun.

Starting at 0x800, the first few bytes are (non-ascii):

0000000 25c10d04 120057c0 01140462 40430009
0000020 54041011 75500401 040800dc 005c0196
0000040 010a0020 00807005 150c4240 001404c6
0000060 6001709f 1d000287 27c07cc0 102a00dc

This communication may not represent my employer's views,
if any, on the matters discussed. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150511/f7b5504f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150511/f7b5504f/attachment-0001.bin>