From: [email-masked] (Wolfram Urbanek)
Date: Wed, 11 Mar 92 13:41:54 EST

unsubscribe   [email-masked]

Date: Fri, 13 Mar 92 01:49:16 EDT
From: [email-masked] (Ethan Dicks)
To: [email-masked]
Subject: Short test

Date: Fri, 13 Mar 92 01:49:16 EDT
From: [email-masked] (Ethan Dicks)
To: [email-masked]
Subject: Short test

This is a test to see if I can send stuff to the listserv.  I was told that
there was a problem with my address as listed.

Ob PDP-8 question:  Does anyone have any docs on the original 8?  I have
one complete (and one disassembled) unit, but the cards were re-arranged
to make an ad photo look better.  The damn photographer didn't like all
the holes in the ALU section and bunched up the cards.  To see the
results of his efforts, look at the Software Results Ad on the back of
"CPU Wars" by Chas. Andres.  The machine in the ad is one of the machines
I own.  The other is mostly covered in offset ink :-P

-ethan

Date: Sat, 14 Mar 92 6:07:37 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

Date: Sat, 14 Mar 92 6:07:37 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

From:   Charles Lasner ([email-masked])
To:     [email-masked]
Subj:   Announcement of new Kermit-12 utilities

    Currently available at watsun.cc.columbia.edu via ftp in
/pub/ftp/kermit/d/k12*.* are two new files: k12enc.pal and k12dec.pal.
The new files have internal dates of 1-Mar-92.

    These are the newly updated ENCODE and DECODE programs for moving
around OS/8 binary files.  There is a new feature added to both, the
ability to deal with "raw" image data.  Consider the following usage:

.R ENCODE
*BIGGY.EN<RXA1:/I=756

When the input specification is a device only AND the /I switch is given
AND a non-zero equals parameter is given, then the ENCODEd file is
created containing the entire logical device for the length specified in
the equals parameter.  In the example, the length of an RX01 in OS/8
terms is used.

    Note that the device need not be an OS/8 "legal" structure, and
there is no individual input file significence either.  The user must
set the length to whatever is appropriate.  Too large a number could
result in program abort due to handler-reported input error.  The
minimum length is 1; a zero-value is the same as leaving out the
parameter.  (This is a restriction of OS/8 itself.)  Input data always
starts at OS/8 logical record 0000.

    Note that the device must be definable within the scope of the
selected OS/8 handler itself, since it is used for all input I/O using
"raw" sequential calls.

    For example, an OS/8 bootable RX01 standard-format diskette would be
acceptable for encoding here, while a WPS document disk would not be.
The reason is that the handler does not access track zero (not a WPS
issue) and also does all reads in 12-bit mode, while WPS documents are
written in 8-bit mode, portions of which are lost when using a 12-bit
mode handler.

    By using another (user-written) handler that supplies 8-bit
transfers, the WPS document disk CAN be successfully transferred to
ENCODE format intact.  (Note: there are no current 8-bit mode handlers
for RX02 and RX50, just RX01; this is a separate problem being addressed
elsewhere.)

    Output DECODing is accomplished in a symmetrical manner:

.R DECODE
*RXA1:<BIGGY.EN/I=756

The equals parameter need not be exact, but must be at least as large as
the parameter used when encoding.  A smaller value can be used to limit
the transfer deliberately where appropriate.  For example, using =7 will
only transfer the first seven records of the encoded file onto the
target device.  If the encoded file contains a valid OS/8 device in
complete image form, this amount will suffice to transfer only the
directory to the target device.  This effectively aborts the transfer,
so the user can look at the directory with DIR, etc., to determine
suitability of the larger transfer, etc.

    Warning:

    This usage writes over the output device starting at logical record
0000.  The (possibly present) previous OS/8 structure will be destroyed.
This is the intended function of this usage as the new data is meant to
be moved to the beginning of an empty device.

    Overall program operation for all other operations remains
unchanged.  As before, program documentation is contained in the source
files.  Except for the new image transfer feature, the programs are
totally compatible with their previous respective versions.  (Note, the
latest and previous versions are NOT compatible with older versions!)

    There are no plans to upgrade the .BOO format encode and decode
programs, since the .BOO format has no checksum protection.  This is
deemed a necessary feature in a complete device image transfer, due to
the likelihood of a long file, etc.  Since the maximum length of an OS/8
file is limited to 4088 records, the raw input will of necessity be
limited to somewhat less than this size of records, depending on the
efficiency of the run-length compression inherent in the data encoding.

cjl