Subject: unsubscribe [email-masked]

From: Robert F Spence <[email-masked]>
Date: Wed, 11 Mar 1992 08:05:47 -0500

unsubscribe [email-masked]

---

From: Jan Brittenson <[email-masked]>
Date: Sun, 15 Mar T 22:00:22 EST

Done.

Date: Sun, 15 Mar 92 22:27:47 -0500
From: [email-masked] (Jan Brittenson)
To: [email-masked]
Subject: All these "request" replies

Date: Sun, 15 Mar 92 22:27:47 -0500
From: [email-masked] (Jan Brittenson)
To: [email-masked]
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
						   [email-masked]

Date: Sat, 28 Mar 92 2:14:28 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

Date: Sat, 28 Mar 92 2:14:28 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

From:   Charles Lasner ([email-masked])
To:     [email-masked]
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 ([email-masked])

Date: Mon, 30 Mar 92 14:51:31 -0500
From: [email-masked] (Richard Chapman)
To: [email-masked]

Date: Mon, 30 Mar 92 14:51:31 -0500
From: [email-masked] (Richard Chapman)
To: [email-masked]

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