Subject: RE: HP storage formats on ss80 protocol disks

From: "Peter Brown" <[email-masked]>
Date: Thu Apr 17 07:57:29 2003

Hi Joe, Bill, Tony,

Sorry for the delay in replying - the 'proper' job takes precedence 
unfortunately!

Joe - bit of a typo on my part the 9133 appears to be CS/80.  Can you 
explain the differences between CS/80 and SS/80?  I seem to remember that CS 
stands for Command Set and SS stands for Sub Set but other than my lack of 
knowledge is complete.

I have an HP 1000 based system (the 5451c) that runs 7900 and 7906 drives - 
are these CS/80 based too?  It would be useful if I could back the software 
up on these.

I think that the HP ISA card just allowed you to put DOS partitions on HPIB 
disks not read partitions in other formats.

How can I tell if the drive is from an HP 9000 200 or an HP 9000 300 series 
system?  Do you still have your HP LIF foramt description document? - any 
chance of a copy?

Bill - Thanks for clarifying the HP 88500A harware capabilities

Tony - thanks for the pointers with the LIF format.

I took your byte tables and overlaid them with the data blocks that I am 
pulling off the disk and they agree very well (all of the record position / 
record length values seem to be correct).

I have a few questions.

The volumme label / descriptor block, bytes 16-19, returns a directory 
length of 1 but when I directory the disk I get around 280 filenames.  A 
directory of one block would only support 32 files - where am I going wrong?

In the tracks per surface, Number of surfaces, Records per track fields I 
get all zeros - does this just mean that the drive does not report them?

What is the LIF file structure for text files?

Thanks for your replies

Cheers

Peter Brown

_________________________________________________________________
Get Hotmail on your mobile phone http://www.msn.co.uk/mobile

---

From: Joe <[email-masked]>
Date: Sat Apr 19 13:22:42 2003

Peter,

At 12:52 PM 4/17/03 +0000, you wrote:
>Joe - bit of a typo on my part the 9133 appears to be CS/80. 

    I doubt it. The 9133/9134 A, B, D and H are all SS-80. That's why I asked which model you had. SS-80 in a hard drive is unusually.

 Can you 
>stands for Command Set and SS stands for Sub Set but other than my lack of 

   I don't know the details except that SS-80 is supposed to be a sub-set of the CS-80 protocall. I had a manual with the instruction set for CS-80 but I gave it to Steve Robertson for their use in writing a CS-80 driver for HIPLOS for the HP 1000s. I do still have a document titled "HP Flexible Disk Drive Command Set" that describes what I assume to be SS-80 altough it doesn't specificly say so. I've never seen the docs for Amigo protocall but I think that a couple of list members have them. Frank McConnel comes to mind.

>
>I have an HP 1000 based system (the 5451c)

    I've been meaning to E-mail you and find out more about your HP 1000. Can you give me more details about it? BTW yesterday I just found another one buried in storage that I'd forgotten about. It's a M series.  I also picked up the cable that you wanted. I can ship it with the manual. More on that by direct E-mail.

 that runs 7900 and 7906 drives - 
>are these CS/80 based too?  It would be useful if I could back the software 

   I don't have any info on the 7900 so I can't tell you anything about it. But the 7906 is an Amigo/MAC interface. I don't know if the Amigo portion is the same as that used for the older floppy disk drives but I assume that it is or that it's at least close. I'm not sure what all is required to support SS-80/CS-80 on the HP 1000s but it definitely needs more than the Amigo/MAC inteface.

>disks not read partitions in other formats.

   I knew it put MS_DOS format on the drive but I thought that it might have some lower level commands that would let you write a driver to read HP formats. What you describe, MS-DOS format - no HP format support, is the same as what the HP 110 Portable and Portable Plus do with the HP 9114 disk drive.

>system?  

   Unless you just happen to know where it came from, the only what that I know of is to connect it to a 9000 200/300 and boot it and do a CAT. I thought that you might know the history of the drive.

Do you still have your HP LIF foramt description document? - any 
>chance of a copy?

    I don't think I have it any more. I gave it to someone that was researching the LIF formats and trying to come up with a way to use the HP LIFUTILS in a predictable manner.

    Joe

---

From: [email-masked] (Tony Duell)
Date: Sat Apr 19 13:24:25 2003

> Tony - thanks for the pointers with the LIF format.

I am glad it was of help...

> directory of one block would only support 32 files - where am I going wrong?

Actually, a single block will hold 8 filenames...

As to where the problem is, I don't know. Maybe this is one of the 
differences between various LIF formats. The HP71 HPIL manuals says 

'Bytes 16 through 19 indicate the number of records in the directory, 
which is fixed whren the medium is initialised, but varies from medium to 
medium'

There must be some way for the machine to find out the directory size 
for 2 reasons -- firstly to determine whether there's space in the 
directory for another file, and secondly to determine the start block of 
the first file on the disk (== first block after the directory). 

> get all zeros - does this just mean that the drive does not report them?

Probaly. There's no reason for a user program to ever need this 
information, all it needs is the total size of the volume (and I think 
there's a CS/80 command for that).

> What is the LIF file structure for text files?

The easiest way to answer this is for me to post the source of my program 
to turn such files into unix-style text files (streams of bytes with 
newlines to mark the end of lines). Here it is. It's GPLed, so feel free 
to hack about with it.

------
/* hptext.c -- a filter to process HP text (LIF1) files */
/* 2000 A. R. Duell, and placed under the GPL */

/* An HP text file, also known as a 'LIF file type 1' consists of a 
   number of records. Each record starts with a 2 byte length (high byte 
   first), and contains that number of bytes. A record length of 0xFFFF 
   indicates the end of the file. A record length of 0xFFFE indicates a 
   null record.

   Note that if the record length is odd, then an extra dummy byte is placed
   at the end of the record. Thus the total length (header+data) of any 
   record is even.

   See HP71 Software IDS volume 1, section 11.2.8.1 for further details

   This filter decodes such files into a stream-of-bytes, with the ends 
   of records being marked by \n characters. */

#include<stdio.h>

#define END_LEN 0xFFFF 
#define NULL_LEN  0xFFFE

unsigned int record_length(void)
  {
    /* Get 2 bytes from standard input, and return the record length that
       they specify. Return 0xFFFF if end-of-file occurs */

    unsigned char data[2]; /* Buffer to store the 2 bytes in */
    if(fread(data,sizeof(char),2,stdin)!=2)
      {
        /* This is the end of the physical file, so return an end-of-file
           marker */
        return(END_LEN);
      }
    else
      {
        /* Return the record length */
        return((data[0]<<8)+data[1]);
      }
  }

void copy_chars(int length)
  {
    /* copy length characters from standard input to standard output */
    int c; /* Character to copy */
    int i; /* counter */
    for(i=0; i<length; i++)
      {
        if((c=getchar())==EOF)
          {
            /* Quit at physical end of file, and let the 
               next call to record_length end the program */
            fprintf(stderr,"hptext: Unexpected end of file \n");
            break;
          }
        putchar(c);
      }
    printf("\n");
    if(length&1)
      {
        /* If the length is odd, get the dummy byte */
        c=getchar();
      }
  }

int main(int argc, char**argv)
  {
    int length;
    while((length=record_length())!=END_LEN)
      {
        if(length!=NULL_LEN)
          {
            /* Copy non-empty records */
            copy_chars(length);
          }
      }
    exit(0);
  }

---------------

-tony