From rfs@kepler.unh.edu Mon Mar  2 03:17:40 1992
Return-Path: <rfs@kepler.unh.edu>
Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
	id AA21599; Mon, 2 Mar 92 03:17:36 EST
Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB)
	id AA23226; Mon, 2 Mar 92 03:17:24 EST
Received: from kepler.unh.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03299; Mon, 2 Mar 92 02:51:08 EST
Received: by kepler.unh.edu id AA11067
  (5.65c+/IDA-1.4.4 for PDP8-lovers@ai.mit.edu); Mon, 2 Mar 1992 02:51:06 -0500
Date: Mon, 2 Mar 1992 02:51:06 -0500
From: Robert F Spence <rfs@kepler.unh.edu>
Message-Id: <199203020751.AA11067@kepler.unh.edu>
To: PDP8-lovers@ai.mit.edu
Subject: subscribe

subscribe


Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 6 Mar 92 04:37:54 EST
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Fri, 6 Mar 1992 04:37:47 -0500
Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13504; Fri, 6 Mar 92 04:18:02 EST
Received: by watsun.cc.columbia.edu (5.59/FCB)
	id AA27262; Fri, 6 Mar 92 04:17:55 EST
Date: Fri, 6 Mar 92 4:17:54 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Randomness
Message-Id: <CMM.0.90.0.699873474.lasner@watsun.cc.columbia.edu>

Date: Fri, 6 Mar 92 4:17:54 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Randomness



Just testing the list for someone not sure he's still on it.

Also, there is some -8-related stuff going on intermittently on
alt.folklore.computers of interest to this group.

cjl (Occasionally wearing flame-retardant clothing)


Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sat, 7 Mar 92 04:26:11 EST
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sat, 7 Mar 1992 04:26:08 -0500
Received: from uccvma.ucop.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07326; Sat, 7 Mar 92 04:02:14 EST
Message-Id: <9203070902.AA07326@life.ai.mit.edu>
Received: from UCCVMA.BITNET by uccvma.ucop.edu (IBM VM SMTP V2R2)
   with BSMTP id 2974; Fri, 06 Mar 92 09:07:02 PST
Date: Fri, 06 Mar 92 09:07:01 PST
From: ISSBAL@uccvma.ucop.edu
To: pdp8-lovers@ai.mit.edu
Subject: Info, please...

Date: Fri, 06 Mar 92 09:07:01 PST
From: ISSBAL@uccvma.ucop.edu
To: pdp8-lovers@ai.mit.edu
Subject: Info, please...

From:    Bruce Lane  ISSBAL @ UCCVMA  (510) 987-0014
Subject: Info, please...

Hi... I'm curious about the PDP8-LOVERS newsgroup, as I own a PDP-11/34A
system. Could you tell me a little more about it, please? I may want to
subscribe.

Thanks!

==Bruce


Mail:    Telecommunications Services
.        Office of the President, University of California
.        300 Lakeside Drive, Room 3010
.        Oakland, CA 94612-3550


From setala@mdata.fi Wed Mar 11 07:01:28 1992
Return-Path: <setala@mdata.fi>
Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
	id AA02666; Wed, 11 Mar 92 07:01:19 EST
Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB)
	id AA06735; Wed, 11 Mar 92 07:01:24 EST
Received: from fuug.fi by life.ai.mit.edu (4.1/AI-4.10) id AA02673; Wed, 11 Mar 92 06:43:40 EST
Received: from mdata.fi by fuug.fi with UUCP id AA01974
  (5.65c/IDA-1.4.4 for PDP8-lovers@ai.mit.edu); Wed, 11 Mar 1992 13:42:12 +0200
Received: by mdata.fi (5.65c/1.10)
	id AA08481; Wed, 11 Mar 1992 02:34:07 +0200
Date: Wed, 11 Mar 1992 02:34:07 +0200
From: Saku Setala <setala@mdata.fi>
Message-Id: <199203110034.AA08481@mdata.fi>
To: PDP8-lovers@ai.mit.edu
Subject: subscribe setala@mits.mdata.fi

subscribe setala@mits.mdata.fi

--Saku Setala
setala@mits.mdata.fi


From rfs@kepler.unh.edu Wed Mar 11 08:19:19 1992
Return-Path: <rfs@kepler.unh.edu>
Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
	id AA19052; Wed, 11 Mar 92 08:19:11 EST
Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB)
	id AA03954; Wed, 11 Mar 92 08:19:21 EST
Received: from kepler.unh.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03394; Wed, 11 Mar 92 08:05:49 EST
Received: by kepler.unh.edu id AA17535
  (5.65c+/IDA-1.4.4 for PDP8-lovers@ai.mit.edu); Wed, 11 Mar 1992 08:05:47 -0500
Date: Wed, 11 Mar 1992 08:05:47 -0500
From: Robert F Spence <rfs@kepler.unh.edu>
Message-Id: <199203111305.AA17535@kepler.unh.edu>
To: PDP8-lovers@ai.mit.edu
Subject: unsubscribe rfs@kepler.unh.edu

unsubscribe rfs@kepler.unh.edu


From urbanek@pender.ee.upenn.edu Wed Mar 11 14:07:21 1992
Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
	id AA24189; Wed, 11 Mar 92 14:07:19 EST
Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB)
	id AA08476; Wed, 11 Mar 92 14:07:30 EST
Received: from linc.cis.upenn.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08629; Wed, 11 Mar 92 13:43:52 EST
Received: from PENDER.EE.UPENN.EDU by linc.cis.upenn.edu
	id AA17859; Wed, 11 Mar 92 13:43:49 -0500
Return-Path: <urbanek@pender.ee.upenn.edu>
Received: by pender.ee.upenn.edu
	id AA05163; Wed, 11 Mar 92 13:41:54 EST
Date: Wed, 11 Mar 92 13:41:54 EST
From: urbanek@pender.ee.upenn.edu (Wolfram Urbanek)
Posted-Date: Wed, 11 Mar 92 13:41:54 EST
Message-Id: <9203111841.AA05163@pender.ee.upenn.edu>
To: pdp8-lovers@ai.mit.edu


unsubscribe   urbanek@pender.ee.upenn.edu


Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 13 Mar 92 10:58:16 EST
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Fri, 13 Mar 1992 10:58:04 -0500
Received: from saqqara.cis.ohio-state.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22463; Fri, 13 Mar 92 10:02:04 EST
Received: by saqqara.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA17799; Fri, 13 Mar 92 09:49:08 -0500
Received: by n8emr.uucp (Ohio AMPR Gateway Smail3.1.16.1 #16.30)
	id <m0lP8ME-0000InC@n8emr.uucp>; Fri, 13 Mar 92 04:15 EST
Received: by uncle.uucp (/\=-/\ Smail3.1.16.1 #16.29)
	id <m0lP8QP-0000ycC@uncle.uucp>; Fri, 13 Mar 92 04:19 EST
Received: by jcnpc.uucp (/\=-/\ Smail3.1.16.1 #16.30)
	id <m0lP7mm-0002HEC@jcnpc.uucp>; Fri, 13 Mar 92 03:38 EST
Received: by kumiss.UUCP (V1.15/Amiga)
	id AA002uq; Fri, 13 Mar 92 01:49:16 EDT
Date: Fri, 13 Mar 92 01:49:16 EDT
Message-Id: <9203130549.AA002uq@kumiss.UUCP>
From: kumiss!erd@cis.ohio-state.edu (Ethan Dicks)
To: pdp8-lovers@ai.mit.edu
Subject: Short test

Date: Fri, 13 Mar 92 01:49:16 EDT
From: kumiss!erd@cis.ohio-state.edu (Ethan Dicks)
To: pdp8-lovers@ai.mit.edu
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


Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sat, 14 Mar 92 06:24:52 EST
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sat, 14 Mar 1992 06:24:26 -0500
Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20220; Sat, 14 Mar 92 06:07:51 EST
Received: by watsun.cc.columbia.edu (5.59/FCB)
	id AA29730; Sat, 14 Mar 92 06:07:38 EST
Date: Sat, 14 Mar 92 6:07:37 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Message-Id: <CMM.0.90.0.700571257.lasner@watsun.cc.columbia.edu>

Date: Sat, 14 Mar 92 6:07:37 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu

From:   Charles Lasner (lasner@watsun.cc.columbia.edu)
To:     pdp8-lovers@ai.mit.edu
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


From bson@ai.mit.edu Sun Mar 15 22:12:43 1992
Return-Path: <bson@ai.mit.edu>
Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
	id AA11233; Sun, 15 Mar 92 22:12:38 EST
Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB)
	id AA27184; Sun, 15 Mar 92 22:12:50 EST
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA23746; Sun, 15 Mar 92 22:00:19 EST
Received: by rice-chex (4.1/AI-4.10) id AA13433; Sun, 15 Mar 92 22:00:14 EST
Date: Sun, 15 Mar T  22:00:13 EST
Message-Id: <9203160300.AA13433@rice-chex>
From: Jan Brittenson <bson@ai.mit.edu>
To: PDP8-lovers@ai.mit.edu, setala@mdata.fi
Subject: Re:  subscribe setala@mits.mdata.fi

Done.


From bson@ai.mit.edu Sun Mar 15 22:20:29 1992
Return-Path: <bson@ai.mit.edu>
Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
	id AA14469; Sun, 15 Mar 92 22:20:26 EST
Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB)
	id AA30050; Sun, 15 Mar 92 22:20:37 EST
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA23753; Sun, 15 Mar 92 22:00:29 EST
Received: by rice-chex (4.1/AI-4.10) id AA13440; Sun, 15 Mar 92 22:00:23 EST
Date: Sun, 15 Mar T  22:00:22 EST
Message-Id: <9203160300.AA13440@rice-chex>
From: Jan Brittenson <bson@ai.mit.edu>
To: PDP8-lovers@ai.mit.edu, rfs@kepler.unh.edu
Subject: Re:  unsubscribe rfs@kepler.unh.edu

Done.


Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sun, 15 Mar 92 22:46:50 EST
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sun, 15 Mar 1992 22:46:48 -0500
Received: from churchy.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24419; Sun, 15 Mar 92 22:27:49 EST
Received: by churchy.gnu.ai.mit.edu (5.65/4.0)
	id <AA17276@churchy.gnu.ai.mit.edu>; Sun, 15 Mar 92 22:27:47 -0500
Date: Sun, 15 Mar 92 22:27:47 -0500
From: bson@gnu.ai.mit.edu (Jan Brittenson)
Message-Id: <9203160327.AA17276@churchy.gnu.ai.mit.edu>
To: pdp8-lovers@ai.mit.edu
Subject: All these "request" replies

Date: Sun, 15 Mar 92 22:27:47 -0500
From: bson@gnu.ai.mit.edu (Jan Brittenson)
To: pdp8-lovers@ai.mit.edu
Subject: All these "request" replies

   My aoplogies regarding all these replies. I didn't notice that
requests also sent to pdp8-lovers got that address copied into the
carbon copy list in my acks. (The Unix "new mail reader" syndrome.
:-))


						-- Jan Brittenson
						   bson@gnu.ai.mit.edu


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Sat, 28 Mar 1992 05:41:57 -0500
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sat, 28 Mar 1992 05:41:52 -0500
Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10321; Sat, 28 Mar 92 05:07:06 EST
Received: by watsun.cc.columbia.edu (5.59/FCB)
	id AA01763; Sat, 28 Mar 92 02:14:29 EST
Date: Sat, 28 Mar 92 2:14:28 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Message-Id: <CMM.0.90.0.701766868.lasner@watsun.cc.columbia.edu>

Date: Sat, 28 Mar 92 2:14:28 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu

From:   Charles Lasner (lasner@watsun.cc.columbia.edu)
To:     PDP8-Lovers@ai.mit.edu
Subj:   Status of the DECmate bootable volume problem (Note: very long;
        important to the concerned intended audience.)

    I have done some recent work on the problem of boot-volume
destruction on DECmates using OS/278 Version 2.  I would like to obtain
some user "feedback" regarding the direction taken to solve one of the
stickier problems of this system.

    The ultimate goal is a replacement system currently dubbed OS/8
Version 5.  V5 will run on any -8 family member (no -5's or -8/s's) thus
obsoleting all previous versions that have limited application due to
"creeping" design problems.

    At the current time I am concentrating on DECmate-specific problems
because most of the problems are present there.  (It is a relatively
simple matter to recover classic PDP-8 compatibility in most of the
programs because that was the actual original design specification.
Newer "maintainers" didn't know this however, nor did their managers
:-).  I have already screened OS/278's release of PAL8 and CREF and find
no specific dependencies, which is why they are distributed with
Kermit-12.  The rest need the same attention;  undoubtedly a few BSW's
and CAF's and IAC-rotate combinations will turn up and can be
eliminated.)

    Statement of the Problem: boot-block destruction.

    Several perfectly reasonable OS/8 commands exist that have one thing
in common:  Logical record 0000 on SYS: is zapped for some specific
purpose.  For example, the command SET SYS OS/8 reads in SYS:'s record
0000, and then modifies relative word 4, then writes the record back.
The only change involves word 4, which can be HLT or CLA HLT or OSR HLT
or CLA OSR HLT.  The four combinations were defined for various
less-than perfect implementations of defining the system as OS/8, OS/78,
OS/278, and VT/278. (The last exists only in OS/78 V4 primarily for the
DECmate I.)  Surprisingly enough, this command even exists in OS/278
Version 2.

    The use of BUILD to create a new OS/8 system is another familiar
operation that writes out the desired information on record 0000 to form
the system bootstrap block.  Alternatively, the system can be created
from a .SY file using the PIP /Y option.

    Users who wish to change the default year-group for their system
need to update record 0000 using FUTIL or other utility so that the last
word of the record which is loaded in location 07777 contains the proper
value.  For example, distributed versions of OS/278 now claim a year
more than 8 years ago for any directory operation such as the DIR
command.  By using the proper value in the year-group bits, the system
date can be more accurate by default.  (Typing in a DATE command to set
the date fixes this of course, but the default is wrong until you do
this.)

    On all systems prior to OS/278, all of these operations work fine
and are of no consequence.  Use of them on OS/278 causes the system to
become NON-bootable!

    To make matters worse, the system is NOT delivered set to OS/8, so
many programs cannot be used with the R, RUN, or GET commands.  (This is
traceable to OS/78 V1 which is also coincidentally OS/8 V3D.  The entire
"feature" is one of those "less is more" things invented by a
long-departed manager.  All subsequent versions support this, but OS/278
is "stuck" with it.)  Attempts to use SET SYS OS8 not only don't work,
an additional "feature" is a warning message that the system isn't set
to SET SYS OS278.  However, restoring OS/278 mode doesn't repair the
boot volume problem!  (There is a kludged workaround for floppies only,
but no possible repair for hard disk.)

    So what's wrong here?

    The underlying cause of the problem is the writing on logical record
0000 of the boot device, either RX50 or RD51D.  I have analyzed the
exact cause:

    The DECmates are started in an onboard ROM of which I have
disassembled most, if not all of the known variations.  (Anyone who
believes I missed their machine is encouraged to get in contact with me.
I can give a short program to find out which version is in the machine.)

    In order to be a bootable volume, the ROM checks a small section of
data using a designated "validity check" routine.  The method consists
of reading in the affected area (track 1, sector 1 of the RX50 in drive
zero, or record 0000 of the startup volume) and checking a few bytes for
a specific pattern.  If the test passes, the volume is bootable, else we
see the all-too-familiar giant blinking floppy on the screen.

    The key to the problem is that the ROM checks a few BYTES, NOT
WORDS.  OS/8 handlers operate in 12-bit word mode, not 8-bit byte mode.
This is a rather curious quirk of the design, since the bootstrap is
always accomplished in 12-bit mode!  (I guess someone felt it
unreasonable to write on the disk the way you intend to read it :-).)

    The problem is that when you write on the disk in 12-bit mode (even
using the "same" data that was there beforehand), you selectively
destroy data relative to subsequent 8-bit mode usage.

    This is not a new phenomena, as many -8 peripherals work this way,
such as RX01 and RX02.  The RX50 and RD51D aren't any different, except
in the particular way the 8-bit-only data is destroyed:

    RX01/02's written in 12-bit mode destroy the last 1/4 of the sector
only.  Whether accessed in 8-bit or 12-bit mode, the first 3/4 of the
sector is unmodified when written back.  (If the RX50 worked this way,
the problem wouldn't exist :-).)

    The RX50 and RD51D work identically to each other, but differently
from the RX01/02.  In these devices, each 12-bit word occupies two 8-bit
bytes, thus destroying 1/4 of the bits in each byte pair.

    The validity test consists of the following algorithm:

    Reading the sector in, using 8-bit mode, we can number the bytes as
Byte[0] through Byte[511].  The first test performed is:

    Byte[0]-Byte[1] = 000

    Failing this test the volume is non-bootable.  On OS/278 volumes,
these bytes are always 000 before and after 12-bit writing and aren't
problematic.

    The second test is:

    Byte[3] = 000

    Failing this test the volume is non-bootable.  In OS/278 volumes
this byte is also 000 before and after 12-bit writing and isn't
problematic either.

    The third test is more complicated:

    Index := Byte[2]*2+2

    Index will be calculated as 06 as a result of the fact that
Byte[2]'s contents is 002 both before and after 12-bit writing.  This
isn't problematic YET:

    Byte[Index] AND Byte[Index+1] AND 8 = 8

    Assuming these bytes are read into 12-bit memory right-justified,
what's being demanded is that these two bytes are 0010 under a mask of
0010.  In the OS/278 boot record, they are both 0010 before and after
12-bit writing, so there isn't a problem YET:

    Byte[Index]+Byte[Index+1]+Byte[Index+2]+Byte[Index+3] = 255

    Again assuming right-justified 12-bit data, what's being demanded is
that the sum of the four bytes is 0377 under a mask of 0377.  This is
CHANGED by 12-bit writing.  The "before" byte values (in octal) are:

    0010
    0010
    0011
    0346

    The "after" byte values are:

    0010
    0010
    0011
    0006

    One of them was destroyed thus making the volume non-bootable.

    There is a minor complication of test 3: if any part of it fails,
calculate:

    Index := Index-2

    Then repeat all of test 3.  If it fails the second time, the device
is non-bootable.  For RX50's, the four affected bytes are located at
offset 004-007 while the RD51D bytes are at offset 006-011.  The test is
designed to pass either case normally.  The 12-bit mode writing destroys
the same relative byte in the same manner regardless of device.

    Other non-tested bytes are apparently "reserved" and contain mostly
all zeroes, except for one byte containing 0010.  All of them are
unchanged by 12-bit writing.

    The underlying format for 12-bit write is as follows:

The first of two bytes is unaffected and represents the low-order 8 bits
of the 12-bit word.  The second byte consists of 4 zero bits followed by
the original high-order 4 bits of the 12-bit word stored in the
low-order 4 bits of the 8-bit byte.

    Thus the 0346 byte is reduced to 0006 by the 12-bit write that
destroys the boot block.  This code is in every DECmate II and DECmate
III ROM version I have disassembled (5 total as of this writing).

    So how do we fix it?

    This is the stickier part of the problem.  I need some user
information to confirm the magnitude of the problem "outside" of the
DECmate.  One of my goals is to prevent loss of any avenue of
transmission of DECmate media, especially if avoidable.

    The apparent problem stems from DEC's attempt to "standardize" on
just what boot-volume headers look like.  The 12 bytes "reserved" in the
DECmate boot-block header apparently "conform" to a DEC-wide
specification, presumably with arbitrary assignment according to some
"master list" somewhere.

    For example, it is my understanding that a Micro-11 equipped with
RX50 can copy DECmate-specific RX50's completely (under RT-11 at least)
because the RT-11 RX driver recognizes the DECmate's "signature" as
requiring the copying of track 0.  (RX01 and RX02 avoid referencing
track 0, while DECmates require it to be copied for boot purposes.  The
"slushware" partially resides on track 0.)

    The "short" fix involves changing the signature bytes to a form
immune to 12-bit mode writing.  There are several possible variations
that will work on the DECmate, but I need some good information about
just what "foreign" systems require for DECmate recognition of RX50.

    It is likely that this method is acceptable for hard-disk bootable
volumes, which aren't likely to "travel" too far from the DECmate
physical box :-).

    It is also possible to write an "export" utility in 8-bit mode that
resets the bytes to their original state for use on the foreign systems,
but this requires conscious effort on the part of the user.  (Note also
that the export utility would recover "damaged" RX50's and/or RD51D
volumes if applied to the current deficient OS/278 system.)

    The "long" fix involves a roundabout process:

    There is no hope to modify the system handler directly to cause it
to write record 0000 in 8-bit mode from 12-bit data, as this requires
among other things a buffer to place the data in, or at least a lot of
quirky code.  OS/8 handlers are tight enough as it is.

    However, since this is a DECmate-specific problem, there may be a
DECmate-specific solution:

    The DECmate supports executive "panel requests" to perform a variety
of functions.  I am currently disassembling a copy of version 422 of the
"official" release of the slushware.  (I believe this is the stable
final version; anyone got a newer one?  Please contact me if so.  I will
eventually post all older ones I have as well.)

    Version 422 supports certain "new" features over prior versions, but
apparently all versions have a few bugs, especially in the VT-220
emulator code.  A newer still release is warranted, and I am committed
to (eventually) accomplishing this for these sundry purposes.

    In the process of modifying the slushware, it may not be possible to
easily incorporate an additional panel request feature, but it's
probably accomplishable.  This would be a panel request to "fix" record
zero of the current boot volume by applying the standard signature to it
in 8-bit mode.

    While there is really quite a lot of free memory in the panel area,
there is a limited amount of LOADABLE memory from the boot device.  I
believe that the current code is almost at the upper limit of load size.
There may be two ways to get more load space back:

1)  There may be a spare sector on the slushware data area.  It could be
used to load more code.  If I can make the slushware "smart" enough to
load the extra sector, this would provide ample working space to
implement the proposed changes.  (This is not confirmed information;
until I finish disassembling the slushware, I can't vouch for this with
any certainty.)

2)  There exists a semi-obsolescent routine within the slushware that is
large enough to provide the needed code space for the proposed change.
This is what the current routine (which may be expendable) is provided
for:

    Early versions of the DECmate II do not support a hard disk.  Some
of this may involve hardware ECO's, but every machine I have ever seen
either works just fine, or requires a ROM upgrade only.  (Contact me for
information on how to tell what version you have.  If you already have a
hard disk, you know this doesn't apply to you :-).)  (However, without a
lot of rewiring, the GRAPHICS OPTION can't function in these early
machines!)  These early ROMs have several other problems besides
inability to support a hard disk.

    Apparently, there was a design change to the written format of the
slushware code space.  One sector is always written in 12-bit mode; the
other sectors are all written in 12-bit mode only in some early
slushware revisions; most versions have the other sectors written in
8-bit mode.  The use of 8-bit mode makes the rest of the slushware code
capable of being 1/3 longer than the 12-bit version.  (Most recent
versions are definitely over the 12-bit load limit, and thus are written
out in 8-bit mode.)

    These early ROMs are unaware of the format change, and proceed to
load in all of the sectors in 12-bit mode!  The referenced routine
checks to see if the load was accomplished in 8-bit mode or 12-bit mode.
(The routine itself resides in the first sector that is ALWAYS read in
12-bit mode.  There is a mode flag that newer ROM versions set to
indicate their awareness of the variant load formats and the proper use
of 8-bit mode loading.)

    If the referenced routine finds that the rest of the load is
uselessly accomplished in 12-bit mode, it proceeds to RELOAD all of the
other sectors in 8-bit mode, using coding "lifted" from the newer ROM
revisions.  (These RX50-based systems take a REAL long time for all of
this to happen, about twice as long as any newer version :-).)

    After all of this "fixup" is accomplished,  the code space lies
dormant, i.e., is once-only.  Replacing the routines with the designated
boot-volume fixing code would render a newer slushware release
incompatible with these early ROM machines.  (Note: these machines were
SUPPOSED to be factory-recalled and upgraded for free.  I have already
encountered two of them with the old ROMs still in them, as well as the
lack of the graphics-required hardware changes.  I can provide
replacement ROMs to interested parties who contact me through the mail,
etc.)

    Additionally, these older ROM versions don't completely function:
There are supposed to be executive calls to simulate HALT, call SETUP,
boot an RX50, etc.  In addition, should the machine actually halt, the
HALT panel is required to handle it properly.  Any attempt to use any of
these functions on machines controlled by the old ROMs causes the same
unexpected result: you are put into the SETUP screen.  (For one of the
actions, this is actually correct, namely the CALL SETUP function
request, but a surprising alternative for all others :-).)

    Further, recent slushware versions allow enabling the COMPOSE
CHARACTER key, but only if an internal table is present.  This early ROM
version lacks the table as well :-(.

    So, there is a clear mandate to upgrade the ROMs on these older
machines, but if this overall method is chosen to solve the original
boot-volume problem, then the unmodified machines are "locked out" from
the improvments.

    It is still too early to determine if this admittedly drastic action
is the only method available to accomplish the "long" form of the fix.
Hopefully, the spare sector method will be available.  However, changes
affecting the terminal emulator could require additional space as well.
It would be helpful to have the slushware be self-contained for all
functions, especially since the terminal emulator is used for all
software systems on the DECmate, NOT just OS/278.  (I do expect to "bum"
some words out of the existing code as well :-).)

    If the "short" form of the fix is acceptable, I can publish it.  The
current one I use involves making a one-word change with FUTIL to either
RX50 or RD51D.  (Different changes, but still one word each.) Perhaps
some -11/VAX experts can give ideas for a suitable change "palatable" to
all systems.  If an export utility is written, its use obviates this
problem (as long as it's used :-).)

    Please help me get a consensus view on this problem.  The sooner I
solve it, the faster I can get back to other more "conventional"
problems like device 03/04 console incompatibilites, etc. as well as the
derivative results of this work such as OS/8 V5 or another release of
Kermit-12, etc.

cjl (lasner@watsun.cc.columbia.edu)


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Mon, 30 Mar 1992 15:42:11 -0500
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Mon, 30 Mar 1992 15:42:08 -0500
Received: from cloyd.cs.cornell.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08426; Mon, 30 Mar 92 15:08:51 EST
Received: from ELLI.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.65/I-1.98P)
	id AA06058; Mon, 30 Mar 92 14:51:31 -0500
Date: Mon, 30 Mar 92 14:51:31 -0500
From: chapman@cs.cornell.edu (Richard Chapman)
Message-Id: <9203301951.AA23522@elli.cs.cornell.edu>
Received: by elli.cs.cornell.edu (5.65/N-0.12)
	id AA23522; Mon, 30 Mar 92 14:51:29 -0500
To: pdp8-lovers@ai.mit.edu

Date: Mon, 30 Mar 92 14:51:31 -0500
From: chapman@cs.cornell.edu (Richard Chapman)
To: pdp8-lovers@ai.mit.edu


Thanks to the generous provision of drawings and maintenance manuals
by Val Fucich, my pdp-8/L now seems to be running properly (I found
two out-of-place flip chips). Future plans include rounding up some
peripherals, extra memory, etc. For now, I have the base cpu with 4k
core connected to a tty-33. I have no pdp-8 software except what I
hand assemble. What I wonder is -- is there a way to get software over
the net? Here is my plan: 

I have the RIM loader. Can someone send me a file with the BIN loader
in RIM format (in any format you like -- I'll write code to punch a
paper tape from your file by hooking up a tty with punch to an rs232
port). Then I can toggle in the RIM loader on the pdp8, load the BIN
loader, then load any BIN-format files I can get my hands on, either by
punching tape or letting the PC or workstation emulate a tty's tape reader.

1) What about a cross-assembler I can run on my unix workstation or
PC?  (any cross-compilers out there?). Again, I can convert output
from the cross-assembler to BIN format, hook up the PC to the -8 and
download if I can get the BIN loader. If a cross-assembler goesn't
exist, I will consider writing one that compiles under gcc, say, maybe
based on gas.  Maybe even patch gcc itself to output pdp-8 code (this
has been done for pdp-11 already).

What does anyone think of this? The only pdp-8 software I am aware of
that is available over the net that I know of is kermit, which I don't
think is does me any good at the moment (later...). Of course, as
always, I'll be happy to pay anyone for their trouble who is willing to
mail me paper tape (a couple of kind souls did this when I was getting my
first pdp-11 up and running :-)), or I'll come to pick things up within
a few hours drive of Ithaca, NY or Boston.  

Thanks a bunch, 
Richard Chapman


