🚀 go-pugleaf

In article <1992Sep26.012605.22410@news.cs.indiana.edu> azamora@cs.indiana.edu writes:
>Does anyone have or know where I could get online copies of DEC's PDP-8  
>diagnostics?  Specifically I would like an online listing of Instruction Test  
>1, Instruction Test 2, and Instruction Test 2B.
>
>Thanks,
>
>Tony

Currently there is no such facility per se, however, we now have an archive
at ftp.telebit.com in /pub/pdp8 courtesy of Eric Smith.  Since it's just
starting up, we are still sorting out just exactly how to put the relevant
stuff there.  Obviously paper-tape-original diagnostics belong there, but
in what form?

As part of the Kermit-12 package I have written several utilities to handle
different format files that may be what's needed.

While many unix-oriented sites use uuencode/uudecode, this was not chosen, in
part because of the "slop" in its implementation.

A more robust form has been created, using some features requested by the
Kermit group to overcome uuencode's weaknesses.  This format is generally
known as PDP-8 ENCODE format.  Specific improvements are:

1)	Uses a more robust character set: bi-Hexadecimal.  Only letters and
numbers need be uniquely translatable, and no concern for upper/lower case.
As a consequence, each character has only 5 bits of binary information in it,
as opposed to uuencode's 6.  However, ENCODE can get through "paths" that
uuencode cannot.

2)	Supports PDP-8-oriented compression.  While not a comprehensive
compression method, any-data repeat-compression is supported.  This is
important in PDP-8 files because repeated sections of identical data could
be HLT instructions (7402 octal) that only repeat when looked upon as 12-bit
words.  Many compressions schemes only work for 8-bit byte representations
of files, and then sometimes only for special cases of data, such as all
zeroes bytes, and then sometimes only for somewhat limited repeat counts.
It is true that some data is a string of all 0000 12-bit words, which when
represented a few bits at a time would compress down in zero-data repeat
systems, but items such as the packed representation of binary paper-tapes in
OS/8 .BN format wouldn't compress in a zeroes-only system; ENCODE format will
compress this data effectively.

3)	Supports an overall file checksum to prevent "hoping" that a file
was received intact.  It is unlikely that a delivered file will be actually
defective yet pass the checksum test.

4)	Is more robust against e-mail quirks such as the conversion of the 
file's contents merely because the first characters on a line happen to look
like the word "from".  In this format, that construct never happens, because
all lines are surrounded by non-data delimiters.

5)	The file format supports a command set.  In theory, this makes it
more of a "tar" than a uuencode format, but current programs only support
a single binary file within the encoded file.  An explicit (FILE XXXXXX.XX)
command is used to indicate the imbedded file's filename.  The OS/8 utilities
recognize this command as the default name of the decoded file, although the
user can override this with an explicit filename at the command level.

	Additionally, there are comment commands to help embellish the 
information content about the file.  The usual things automatically generated
are some "advertising" comments about the utility, version, etc., and some
comments about the date the original file was created, as well as the date
the encoded file was created.  By providing file date information, the
file can carry with it information for date reconstruction should it be
derived from untrustable sources, or even have passed through OS/8 systems
with directories set for no additional information words (AIW), which is
an option that is sometimes set in OS/8 when the directory covers many
small files, such as binary paper-tape files.

Currently, ENCODE files are only supported by OS/8 family systems, but as
such, any OS/8 file is supported at the 12-bit binary level, thus an image
of any file can be delivered intact.  In addition, entire devices can be
transmitted in ENCODE format using the so-called "image" mode switches.
The device may be split into two roughly equal parts if desired.  If
decoded onto a device of equal or larger size at the target system, all files
and the directory are delivered together intact; devices with larger inherent
size should then be readjusted using OS/8 PIP to restore their true size.  By
using the image switches to split the encoded image into two parts, it is
possible to take advantage of this mechanism on an OS/8 system as minimal
as two drives of equal size to each other and to the contents of the image
file.  For example, a dual-drive RX01 system can be used to recreate an
RX01 image because you can create a system diskette containing only the
DECODE.SV program and one of the split files while placing a target diskette
in the other drive.  After running the decoder on one half, a similar disk
with the other half is used.  Afterwards, the other drive now contains a
complete image of the transmitted RX01 disk.

So, perhaps someone should put together a "suite" of binary diagnostic files
and place them in the archive as "part 1" and "part 2" of an image of an
RX01 diskette containing many diagnostics as .BN files.  Such files wouldn't
be unreasonably long for a net-accessable archive such as ftp.telebit.com.
RX01 images are about the smallest popular OS/8 device, and thus represents
a useful "size" for this purpose.  Those with larger devices can reprocess the
files accordingly.  It isn't necessary to have RX01 hardware to create such a
file, just modify the directory size of the device using OS/8 PIP so it
matches the size of an actual RX01, then copy the intended files onto the
"shortened" device, and then use ENCODE.SV to create the image files.

An alternate method:

If we restrict ourselves to binary paper-tape files, there is an alternate
method available to better interact with non-PDP-8 systems.  The binary 
paper-tape file can be viewed as nothing more than a sequential list of
8-bit frames which the BIN loader happens to be able to load into memory of
a PDP-8.  Thus the objective then becomes to merely create an image of the
data as sequential bytes.  This is the scheme currently being used with
several PDP-8 simulators, etc., which expect the file to be a sequential
stream of bytes on the native system's file structure.

Towards this end, I have also included in the Kermit-12 package a pair of
utilities to support .BOO format.  While not as robust as ENCODE format,
.BOO format is still somewhat better for the purpose than uuencode format, 
and is widely supported, especially on PC's.  Programs to process .BOO format
have been written in assembler, C, PASCAL, FORTRAN, and even BASIC.  If the
BASIC version is used, it is recommended that it only be used for one purpose:
to acquire the binary of a faster version; the binary executable of a .BOO
decoder written in C is distributed as part of the PC Kermit package.  This
file is itself encoded in .BOO format, thus another decoder is needed first
to process it before it can be used.  The BASIC program is short enough to
be typed in if the need arises towards this purpose.  In any case, the
executable .BOO decoder runs at a decent rate for all subsequent decoding
purposes.

With a PC-based .BOO decoder, it is possible to convert .BOO files to
binary format.  The Kermit-12 ENBOO.SV program will convert OS/8 .BN files
into .BOO format files suitable for sending to other systems with .BOO
decoders.  Assuming the original file was on paper tape, OS/8 PIP is used to
convert it to .BN format.  This file would then be encoded with ENBOO.SV
and sent as an ASCII file to the PC where it is decoded into a binary file.
The resultant file is a stream of 8-bit bytes as in the original binary
paper tape.  Note that OS/8 .BN files are either the result of using PIP
with the /B option on paper-tapes, or perhaps the binary output of an
assembly.  In any case, the resultant file on the other end of the
transmission is in a format suitable for loading with a BIN loader.

The only file "distortion" induced by this process is that OS/8 PIP /B
modifies the paper-tape binary to have a short standard leader and trailer
length, followed by an innocuous ^Z for an end-of-file indicator.  Since the
^Z character follows the trailer characters, a proper loader never sees
this.  Unless the file is meant to be uses with an actual paper-tape reader,
this lossage is not problematic.  OS/8 paper-tape punch handlers can be
used with PIP /B to recreate longer leader/trailer sections if desired.

Files in this format should be called xxxxxx.BIN to remind us that only a
BIN loader is capable of loading them; as such they have no other PDP-8
operating system significence at that point.  As long as the file is
describing the 32K addressing space, any BIN loader will handle it.  If the
file was meant to be used with the KT8A extended address space (128K) it will
function only if the loader recognizes the KT8A data-field extensions.  Since
there are so few files requiring this, it's not likely to be a problem.

Diagnostics are not likely to appear in source form, but are often distributed
with write-ups containing a poor xerox copy of a listing.  If hardy individuals
type up the sources (and verify the accuracy!) of these files, perhaps these
ASCII source files of diagnostics and other programs could be distributed
in the archive as well.  Appropriate binary and documentation files could be
provided for those not requiring source files as well.

cjl