HP 85 tapes

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 (****).