HP 85 tapes

Wed Feb 27 04:58:22 CST 2019

Christian,

the TAPDUP binary and associated utility programs in BASIC was used to
create EPROMs with programs and data for the 9915 Series-80 box.

It can be used to read the directory record and then to read tokenized
PROGrams as data on a file-record base - not at low record level.
The package also contains programs to massage the PROG data into BASIC DATA
statements for creating EPROM burner files.

You could use it to read the tape directory and individual PROG files but
right now I am not aware of a program which would write this data back to a
tape.
You would open the directory, look up a file and then OPEN IMAGE it. Next
you would READ RECORD IMAGE$ the program record by record.

In the end you have not gained much compared to the simple COPY statement.
Except for the copy of the directory with attributes and security flags.

Alternative:
There are also READSECTOR binary programs for reading raw 256 byte
records/sectors from disks. They also work on the tape ":T" but seem to
start their record count after the directory records. On disks, record 0 is
the first real sector.

So, to get the complete binary content one could use 
C$=CATALOG$  from TAPDUP to read the directory record
READSECTOR N,R$,D from to read the subsequent raw "data" records.

Here are my notes on some of the functions in this binary program:

The TAPDUP Binary (Notes by M. Hepperle)
This binary contains functions to read tapes (HP-85, 9915) at low level. It
does not handle disks.
The program was part of the "Tape Duplication and EPROM Programming Pack"
(09915-10010).
As the original software was not available the binary was re-assembled from
an assembler source file.
This source file was obviously created by disassembling the original binary.
It was found at M. Craggs web site:
http://www.biblewitness.org/technical/HP_Series-80/HP-85/ASSM .
Martin Craggs home-made disassembler produced many unnecessary DRP and ARP
statements, which could be cleaned up to improve readbility.

Functions in the TAPDUP binary:

C$=CATALOG$
Return the directory record of the tape in form of a 512 byte buffer (2
records).
C$ must be DIMed to at least 512.

OPEN IMAGE F$
Find the file F$ and open it for reading.
ERRN=67: file not found

T=READTYPE
Return the file type of the currently opened image
(the file image must be opened by a preceding call to OPEN IMAGE)
34 = PROG

N$=READNAME$
Return the file name of the currently opened image
(the file image must be opened by a preceding call to OPEN IMAGE)

R$=READ RECORD IMAGE$
Read the next record of the currently opened file.
The record has a length of 256 bytes.
Reading can be continued by another READ RECORD IMAGE$ until ERRN=71
indicates a read behind the end of the file.
See lines 440 ff in IMAGE program for a typical reading loop. 
(the file image must be opened by a preceding call to OPEN IMAGE)
ERRN=71: end of file reached.

CREATE IMAGE S$,I,J,K
3 numeric parameters

WRITE IMAGE R$
Write record to (where?) "Error 244: No file open"

WRITE CATALOG C$
Writes the catalogue back to disk.
C$ must contain a valid catalog structure, otherwise your tape will be
unreadable afterwards.

READLOGLEN
Read the logical record length, which is 256.

Another useful function in the Program Development ROM
C$=CHECKSUM$(S$)
Return the IBM SDLC CRC checksum of the given string (the length of the
checksum is two bytes).

Example: dumping the tape catalog
Each catalog entry is 12 bytes

10 DIM C$[512]
20 C$=CATALOG$
30 K=1
40 FOR I=1 TO 504 STEP 12
50 FOR J=1 TO 12
60 PRINT C$[K,K];
70 K=K+1
80 NEXT J
90 PRINT
100 NEXT I
110 PRINT
120 END

Tape documentation lifted from Everett Kaser's Series-80 Emulator (I hope
Everett won't sue me for this blatant copyright infringement):

TAPE LAYOUT
-------------------------------------------------------
The HP-85 tape cartridges contained at most 43 files.
File 0 was always the TAPE DIRECTORY, and was always
4 records long.  Files 1-42 were the user-created files.
The tape itself had 2 TRACKS, 0 and 1.

There were TWO COPIES of the TAPE DIRECTORY, one in
records 0 and 1 of file 0, and a second in records 2 and 3
of file 0.  Record 2 was an exact duplicate of record 0,
and record 3 was an exact duplicate of record 1.  Only
one record of the directory could be read into memory at
a time, so the system had to keep track of whether the
first 1/2 or the second 1/2 of the directory was in memory
(or neither).

Each DIRECTORY RECORD consisted of 21 12-byte directory
entries, which equals 252 bytes.  The final 4 bytes of
each record as follows:
  252	directory segment flag (0 or 1).
  253	FILE# of file that wraps from the end of TRACK 0 to
  		the beginning of TRACK 1.
  254	(2 bytes) RECORD# of first record of the split file
  255		that's on TRACK 1.

Each DIRECTORY ENTRY consists of 12 bytes, allocated thusly:
  BYTES	DESCRIPTION
  -----	---------------------------------------------
  0-5	ASCII FILE NAME, blank filled
  6		EXTENDED File Type
  7		FILE TYPE
  8-9	# RECORDS in the file
  10-11	# BYTES in each record

The FILE TYPE is thus:
  BIT	DESCRIPTION
  ---	-----------------------------------------------
   0	No directory name listed
   1	Soft write protect
   2	Extended file type (****)
   3	Binary Program (BPGM)
   4	Data file (DATA)
   5	BASIC Program (PRGM)
   6	Empty file (NULL)
   7	Next available file

The most significant bit of the EXTENDED FILE TYPE byte will
signify extended file type as well as BIT 2 of FILE TYPE, but
it shouldn't be used, as a bug in the system doesn't clear that
bit if you purge the file.  The lower seven bits allow the
differentiation between various extended file types (****).