17 Apr
2003
17 Apr
'03
11:55 a.m.
Tony - thanks for the pointers with the LIF format.
I am glad it was of help...
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?
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).
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?
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