I use Cam's format for my tape images as well.

Aaron

----


Cam's Paper Tapes

These are the paper tapes which came with the Lab8/e that I received from the 
good people at Temple University. These were read by the high-speed reader 
connected to the pdp-8, sent out to the "console" where they were captured 
by a PC and stored on disk.

There are about 164 tapes, each one in its own file, named 0001.PT through
0164.PT. The whole clump of files has been ZIPped into a file named
CAMSPT.ZIP.

The files are simply uncompressed byte streams and you could punch them onto 
paper tape directly and end up with a usable tape.

The original tapes typically had the following format:

        Some garbage
        Some leader
        The actual data
        Some leader
        Some garbage

The leading garbage was usually punches which, when looked at visually, 
spelled something out - typically the tape ID number and COPYRIGHT DIGITAL 
EQUIPMENT. Sadly, the tape ID was often as not covered up by the printed 
label so it could not be read electronically. I therefore took the liberty 
of stripping off the original leading garbage and replacing it with a header 
which is simply ASCII text which replicates whatever was printed on the 
label followed by a CTRL/Z. There are a number of concerns here:

1) If you grab one of these tape files and wander off with it, it contains an 
embedded "label" so you can find out at a later time or place what tape you 
have.

2) On a PC system if you TYPE the tape file, the TYPE utility will spit out 
the ASCII text showing the tape label and then stop at the CTRL/Z.

3) If you actually punch these onto real paper tape and go to use them, you 
will have to skip over the header, but there was garbage you would have had 
to skip on the original tapes as well.

4) If you go to use these on an emulator, you will probably need some way to 
skip over the header. If your emulator has no facility for this it is the 
fault of the emulator. Sorry folks, real paper tapes had crud at the front, 
and the paper tapes came first.

5) The file INDEX.TXT contains the headers from all the files, along with 
file size information.

In the discussion below LEADER refers to characters with only channel 8
punched (200 octal, 80 hex).

The original BIN and RIM format tapes were generally of the form:

        Garbage       (punched letters)
        Blank tape    (various lengths)
        Leader        (various lengths)
        Data
        Leader        (various lengths)
        Blank tape    (various lengths)
        Garbage       (various amounts)

and these tapes have been converted to:

        Garbage       (ASCII header)
        Leader        (240 characters)
        Data
        Leader        (240 characters)

ASCII format tapes were generally of the form:

        Garbage       (punched letters)
        Blank tape    (various lengths)
        Leader        (various lengths, possibly zero)
        Data
        Leader        (various lengths, possibly zero)
        Blank tape    (various lengths)
        Garbage       (various amounts, possibly zero)

and these tapes have been converted to:

        Garbage       (ASCII header)
        Blank tape    (240 characters)
        Data
        Blank tape    (240 characters)
        

For pdp-8 newbies, note that in pdp-8 ASCII the high order-bit of the byte is 
always ON. If you want to look at or work with pdp-8 ASCII data on your PC 
you have to strip the the high-order bit off first.

In most of these tapes, the data consists of a single blast. Some, however, 
have two or more blasts of data seperated by leader and/or blank tape.

All tapes have been checked one way or another for integrity. In the case of 
BIN format tapes, I computed the checksum from the PC file and compared it 
with the on-tape checksum. Other format tapes were read and checksummed 
twice; if the checksums matched we knew that at least they had read the same 
both times.

The headers at the front of the tapes match the printed labels as closely as 
I could manage. I tried hard to be accurate, but make no guarantees. Any
additional comments I added are enclosed in angle brackets <like this>.

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

Cam Farnell
cfarnell@adan.kingston.net
Kingston, Ontario, Canada