Subject: [[email-masked]: Subscription.]
From: [email-masked] (Robert E. Seastrom)
To: [email-masked]
Date: Wed, 1 Jan 92 19:47:19 EST

From: [email-masked] (Robert E. Seastrom)
Date: Wed, 1 Jan 92 19:47:19 EST
To: [email-masked]
Subject: [[email-masked]: Subscription.]

Return-Path: <[email-masked]>
Date: Mon, 30 Dec 91 12:53:31 -0500
From: Dan Lingman <[email-masked]>
To: [email-masked]

...

I have for sale a PDP11/10 with 2 teletypes, Volker-Craig Terminal
(25-27 inch monitor(not sure about size, 2 8 inch drives, a faceplate
and main board (wirewrapped) off a PDP 8/3 and a couple of shopping
bags full of cards for the PDP 8/3 (I am not sure which cards are in
the 11/10 - I can check. 
I am asking for best offer plus shipping. If you are interested, Please
get back to me as soon as possible, as I will be holding an auction
soon, and if these have not been spoken for, they get added in to that.

Please keep in mind that shipping will be from Thunder bay, Ontario Canada.

Date: Thu, 2 Jan 92 1:50:18 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

Date: Thu, 2 Jan 92 1:50:18 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

To:     [email-masked]
From:   Charles Lasner ([email-masked])
Subj:   New Year's Resolutions, etc.

    To ring in the new year, let's resolve to help our architecture by
giving it a "shot in the arm" in certain ways.  I have been doing some
things of late toward this end.

    A recent project has been to do the tedious task of total
disassembly of the DECmate II and III ROMs.  It is necessary to "bite
the bullet" this way to finally totally understand just what a DECmate
*really* is/is not relative to a *real* PDP-8.

    The ultimate goal is to produce operating systems for the entire
line of PDP-8's, not just a family of slightly dissimilar systems that
are separately bound to different models for no good reason other than
the way they "hatched."  (This means all DECmates and PDP-8, -12 models
except for the -5 and -8/s which are too "brain-dead" as originally
implemented.)

    My personal resolution is to produce P?S/8 V 9.x and to spearhead
OS/8 V5.

    The current status of P?S/8 a/o V 8Z is that the RX01/02
single-density version will run on any -8 suitably configured (RX8E
plugged into a DW8E or actual Omnibus as necessary with an RX01 or RX02,
or DSD-210 with Omnibus interface and 1-4 drives with the same bus
considerations).  VT78 or VT278 with 1-2 pairs of RX01 or RX02 is also
supported.

    The DECmate II with the RX78 option is also supported for 1-2
RX01/02 pairs, except that there is no direct way to boot such a system;
the hardware only boots RX50 and/or RD51 hard disk.  A "re-boot" program
can be used that boots an RX01/02 system from either of the two "real"
boot devices.  Unlike all previous machines, the RX78 option requires an
extra operation:

RX8E's ignore the 6750 IOT, but VT78 and VT278 use the instruction as
SEL - LOAD DRIVE PAIR SELECT per AC[11].  Power-on defaults to pair zero
for compatibility with the RX8E.  The DECmate II goes further, and
requires AC[0] also be set.  IF AC[0] is clear, the RX50 is selected.
Thus up to four pairs of drives are possible on a DECmate II.  (If the
RD51 is present, only 1-2 pairs of RX50 can be connected.)

    The P?S/8 RX01/02 diskette uses handlers that obey the DECmate II
convention completely, thus this system can be "re-booted" by using an
appropriate loading program.  (The basic RX01/02 program is used with an
appropriate SEL instruction and AC bit combination.)

    BTW, it is recommended that all OS/8, etc. RX01/02 handlers be
upgraded to support the SEL operation so that operation is possible on
the DECmate II as well as earlier machines.

    There is no current support in P?S/8 for RX50 or RD51 volumes, but I
am narrowing the gap with current efforts.  (Mostly a matter of what to
do, not how to do it :-).)

    There are still some problems when run on DECmates:

P?S/8 supports a HLT instruction in the keyboard monitor via a HALT
command.  On PDP-8's with front panels, pressing continue is the
appropriate action.  Clearly, if you don't have a hardware method of
continuing, you should avoid the command :-).  Similarly, system I/O
error disposition optionally consists of HLTing the CPU with the AC
containing a device-dependent error.  This option should be avoided if
the requisite hardware is not present.

    VT78 and DECmate I initiate a register dump when the CPU halts;
continuing is impossible on these systems, so the same reasoning applies
on these systems.

    The DECmate II (likely III and III+ also) uses a CPU HALT screen
panel with the ability to either reboot, enter setup, or continue at the
user's option.  This would seem to satisfy the P?S/8 HLT requirement,
but there is a problem with the current slushware:

    When the CPU halts, the last console output character is lost.
P?S/8 waits for TSF to skip and outputs a <CR> character, then waits for
the TSF to skip again and outputs a <LF> character, and then halts.
(The user typed HALT<CR> and expects HALT<CR><LF> to be echoed.)

    The net effect is that the next line's prompt overlays the previous
line because the <LF> is "swallowed" as a result of the slushware's
swap-in of the transient HALT-handling routine.

    The best method to repair this situation is to improve the slushware
to be more PDP-8 compatible; it is likely that there is some
context-switch error in the existing code.  The P?S/8 code is totally
"legal" -8 code and should be maintained.  (It is possible to evade the
problem by waiting for the <LF> and then either doing nothing or output
a "sacrificial" <NUL> character before the HLT.)

    There are no other problems with running RX01/02-based P?S/8 on any
family member machine because the instruction set is restriced to the
classic PDP-8 (and LINC-8) only in *all* system programs.

    The device 03/04 problem mentioned in earlier discussions has
already been solved using the software "^C-detect bit" method.  (If
there is sufficient interest, I will repeat the particulars of this
method, especially as it relates to OS/8 V5.)  This is why there are no
restrictions within P?S/8 induced by the DECmate.  All prior PDP-8
functionality is still present.  (Contrast this with the truly sorry
state of OS/78 V4 and OS/278 V2 which are "wimpy" subsets of their OS/8
predecessors :-(.)

OS/8 V5 considerations leave much to do.  I don't intend to do it all
myself, but I will rework quite a lot of the stuff.

    OS/8 needs the 03/04 upgrade already worked out in P?S/8.  This will
allow a specification for all programs to upgrade to.  The rest of the
problems are more "internal" to major OS/8 components such as the
keyboard monitor, ABSLDR, ODT, BATCH, PIP, etc., as well as all handlers
for DECmate-connected disks and ports, etc.  I intend to concentrate my
efforts in this major hunk of the system.  I hope my efforts will be
answered by others contributing consistent efforts on some of the other
programs that run "under" this much of OS/8 (such as Fortran, Basic,
Pascal, etc.).

    The problems of upgrading both P?S/8 and OS/8 for DECmate-cognizant
use are so significent that it is necessary to literally start from the
beginning.

    Accordingly, I am working on the loading ROMs and slushware of the
DECmate II and up.

    As of this writing, I have completely dis-assembled the DECmate II
and III ROMs I have had contact with.  (The DECmate II ROMs are known as
19H and 19N, and also an earlier version apparently known as 31Z which
can't support a hard disk or recent slushware versions.  DECmate III
uses a ROM apparently known as 32H.)  The sources are profusely
documented using all "available" information.  There are a few "sore
spots" in that the code is clearly documented as to what it's doing, but
there is no information currently available as to "why" the code is
there :-).

    The sources produce accurate binary versions of the ROMs themselves
as independently verified using a ROM blaster to read out the ROM
contents.  (Many utilities had to be written just to be able to read the
various ROMs as PDP-8 code; there are four different formats of ROMs
involved - a set of three for the DECmate II and a different format for
the DECmate III.  Part of the work was done on another machine and the
ROM information was transferred using another set of PDP-8 utilities
written primarily for the purpose as well as KERMIT-12.)

    One major set of facts learned from all this effort is the precise
format of the "slushware" which is loaded in prior to any OS boot
operation.

    The format of the slushware is variable.  Only recent loading ROMs
are compatible with recent releases of the slushware on the various
bootable diskettes (and hard disks).  Older slushware should be loadable
on machines with newer loading ROMs; certain features will be missing in
these earlier versions.  Presumably the operating systems on these
earlier media doesn't require the newer fetures available in later
slushware versions.

    I have successfully accessed the slushware code uses in recent
systems which is version 422.  This is found in such places as the
System Test Diskette V 4.5 (BL-HV86A-MV) and various WPS releases.

    It is necessary to upgrade existent OS/278 diskettes to this level
of slushware in order to use them on the DECmate III.  (There may be
certain specific problems using OS/278 features on the DECmate III, such
as using the supplied OS/278 COMM port handler which is slightly
"ignorant" of DECmate III differences from the DECmate II.  This can
eventually be fixed.  The released DM-101 OS/278 diskettes have
slushware too old for DECmate III usage at all.)

    I have developed the source code for the slushware to the point of
zero assembly errors, but it is still too soon to call it PDP-8 "code"
even though it is correct in the absolute binary sense.  (Still a lot of
"blind" disassembler quirks and no comments :-(.) Enough has been
observed to realize that there will be some form of "feedback" between
the slushware and the loading ROMs.  This will likely lead to some
revision of the loading ROM sources to more accurately portray the
system interaction.  (Some code is unreferenced in the ROM directly, but
is referenced by slushware calls just discovered, etc.)

    Clearly the full "exposure" of all DECmate internals will reveal the
path to follow to allow common systems as proposed.  When the slushware
and ROM sources are finalized, they will be released on the net in
accessible ways, such as on the newly-created PDP-8 archive available
through anonymous FTP, etc.

    I would appreciate anyone's input regarding this major effort being
undertaken virtually without any help from DEC whatsoever, a truly
classic case of "reverse engineering" in its truest sense.  If anyone
has any slushware version newer than 422, or any DECmate II, III, III+
ROM versions differing from the four I mentioned, please contact me.  I
intend to produce a variant slushware version to incorporate additional
features, etc., so I want to start from the "best" copy available.  (I
also welcome any gripes against this version which would tend to
recommend using an older release as a base :-).)

    So, let's all welcome 1992 as the year of P?S/8 V9 and OS/8 V5, as
we go into the FOURTH DECADE of PDP-8-type machines.  (LINC and PDP-5
are 1962 designs :-) :-) :-).)

cjl

Date: Mon, 6 Jan 92 11:07:42 PST
From: [email-masked] (Paul Hardy)
To: [email-masked], [email-masked]
Subject: diassembling ROMs

Date: Mon, 6 Jan 92 11:07:42 PST
From: [email-masked] (Paul Hardy)
To: [email-masked], [email-masked]
Subject: diassembling ROMs

This will certainly be a learning experience.  Listings might be available
somehow from DEC on some of this stuff though.  I once disassembled the
M9312 boot PROM, then found out that I could have gotten a commented listing
from DEC.  However, I certainly learned some things in the process by figuring
out everything for myself -- such as the method for printing out an octal
digit -- rotating a bit of the number into the carry bit, then shifting
this into the ASCII digit being constructed.  I was also puzzled by the
last section of the code, which it seemed there was no way to get to, until
I decoded a device PROM and discovered that they jumped to absolute memory
locations in that last section of the boot PROM.  Good luck!

                                   --Paul

Date: Thu, 9 Jan 92 18:03:24 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

Date: Thu, 9 Jan 92 18:03:24 EST
From: Charles Lasner <[email-masked]>
To: [email-masked]

From:   Charles Lasner ([email-masked])
To:     [email-masked] mailing list, Comp.sys.dec.micro
Subj:   What about a DECmate is NOT a PDP-8?         (quite long :-))

    This article's purpose is to reveal the issues involved in
"admitting" the DECmate into the PDP-8 "family" as it usually is
defined.  Due to certain shortcomings stemming from past blunders, etc.,
open issues remain (a/o this writing) that prevent totally unconditional
acceptance.  Hopefully, a "path" can be defined to alleviate the
problem.

    Reader commentary is encouraged; please post to the newsgroup, or
reply to the author (or mailing list) as necessary, etc.  Current
efforts will benefit from your responses.

1.  So, just what IS a PDP-8?

    For the purposes of this article, a PDP-8 is a "complete" 12-bit
system which meets ALL of the following requirements:

    a)  A CPU with 4K/8K or more memory which is totally software
        compatible with the classic 1965 PDP-8 instruction set or
        better.  This requirement covers all DEC 12-bit products (except
        the PDP-5 and PDP-8/s) sometimes referred to as the "Family of
        8" from the PDP-8 through the PDP-8/a, VT-78, and all DECmates.
        Also included are various 8-clones from companies such as
        Fabritek, DCC, Intersil, CESI, and various Eastern Bloc
        countries (the Hungarian TPA, etc.).

    b)  One or more block-replaceable storage devices such as a disk or
        DECtape.  There are in turn several requirements placed on the
        hardware interface to the disk:

        i.  It must be possible for the device to define blocks of data
            in multiples of 128 12-bit words that can be read/written as
            a block.  For OS/8 purposes, logical records consisting of
            256 12-bit words must be definable;  P?S/8 merely requires
            the 128 word block grouping.  OS/8 additionally demands the
            ability to read the first 128 words without destroying any
            memory beyond the 128 word buffer.  Further, when writing
            OS/8 may supply only 128 words of meaningful information,
            and will allow the second 128 words of the logical record to
            become undefined contents as a result, but the entire 256
            word record must still be readable without error at a later
            time despite the "short" write function.

        ii. For OS/8 purposes, a disk device handler must be viable to
            control all read/write operations to the device according to
            OS/8 calling and loading conventions.  The overall size of
            the handler is preferably one page long, but two pages is
            the absolute maximum allowed.  (On many devices, handlers
            this size are a tradeoff of viability versus good error
            handling, if any!  Further, device performance may be
            compromised as well to allow the disk handler to "fit" into
            only two pages.)  If a disk is not required to be a boot
            device, a two-page non-system handler is allowed which has
            effectively more code space due to lack of reserved
            locations used by the rest of the operating system.

            For P?S/8 purposes, a disk device handler must be viable to
            control all read/write operations to the device according to
            P?S/8 calling and loading conventions.  The overall size is
            preferably one page long, but nine pages is the absolute
            maximum allowed.  This significently larger number than OS/8
            allows certain operating environment advantages such as
            better device performance and/or error handling, etc.
            Further, P?S/8 handlers can have optional features used to
            assist binary loader utilites accomplish read-only loading
            of programs.  (P?S/8 systems that support this optional
            feature can load binary files while maintaining device
            write-protect;  OS/8 cannot support this feature ever.)

    c)  There must be an interface to a system console using device
        03/04 that is TOTALLY COMPATIBLE with the classic console
        interface first introduced on the PDP-5 in 1962.

    There may be other optional equipment present such as parallel or
serial printer ports, communications ports, additional disk drive units,
additional/separate disk systems/units, additional terminals, additional
memory, etc., but these are beyond the primary requirement.  Support for
these may vary or be application-specific, etc.

    OS/8 requires 8K of main memory (12K for two-page handler boot
devices);  P?S/8 requires 4K of main memory (8K for nine-page handler
boot devices).  P?S/8 also requires an additional 3K for alternate
console support routines which is non-overlapping in the case of a
nine-page boot device system.  P?S/8 and OS/8 tend to handle certain
devices in a like manner.  For example, both systems handle DECtape as a
one-page boot device; RX01 is a multiple-page boot device for either
system.  In both cases P?S/8 requires exactly 4K less memory for a
mimimal system based on the same device.

2.  So what's wrong with a DECmate?

    Clearly, item a) above is satisfied in all DECmate models.  The 6120
instruction set is a proper superset of the classic PDP-8 and the
PDP-8/e or a, and all models are equipped with 32K, dual stack pointers,
CP memory, etc.  (EAE is not supported, but other machines share this
restriction, e.g., the PDP-8/l.)

    Item b) above is (theoretically, see below) also not a problem.  The
DECmate I comes equipped with 1-2 pairs of RX01/02, and optionally
supports 1-4 RL02s.  DECmate II comes with 1 pair of RX50, and
optionally an additional RX50 pair and/or 1-2 pairs of RX01/RX02 or a 5
Meg or larger hard disk.  (The hard disk and RX01/02 options are
mutually exclusive.  Hard disk size extends up to 64 Megs or more; my
own system is 64 Megs.)  DECmate III comes with 1 pair of RX50.  DECmate
III+ comes with a single RX50-compatible drive and a hard disk (usually
20 Megs.).

    Unfortunately, all DECmates (other than the DECmate I) have a
problem as currently implemented:

As distributed, the bootable volumes on a hard disk, or the contents of
a bootable RX50 diskette must contain a "signature ID" at the beginning
of the disk.   Failure to maintain this information causes the disk to
become corrupted and non-bootable.  This field is located on the disk
area logically referred to as block 0000, and CANNOT be maintained by
existing OS/278 handlers (see below).  Thus certain system operations
must be avoided to prevent system crashes which are totally "legal" and
proper (and necessary) features of OS/8.  (The DECmate I lacks this
problem.)

    Hopefully, this problem is fixable by modification of system
conventions or handler rewrites or both.  Some of this work is currently
in progress. (see below).

    Item c) above is the main "problem child."  The DECmate has a
"simulated" interface to the device 03/04 console, which is NOT totally
compatible, and the differences "matter."  While various
application-only systems such as WPS and COS have been written for the
DECmate, there is only OS/278 available for the DECmate II, which is a
problematic "step-child" of OS/8.

    OS/278 V2 was released to DECUS as DM-101, and eventually as DM-111,
the alledged sources of DM-101.  (DM-111 comes with a disclaimer that
the DM-101 running binary doesn't quite match the DM-111 sources!  I
have confirmed that this is at least partially true: the RD51 handler
sources are NOT identical to the running system.  Further, various
source comments are not totally accurate in describing the actual
hardware :-(.)

    OS/278 V2 comes with a long list of incompatibilities relative to
OS/8 and various in-between releases such as OS/78 V3 and V4.  Some are
documented in OS/278 files on the release diskettes; others were handed
out on notes distributed at the Spring, 1983 DECUS Symposium in New
Orleans during the OS/8 sessions.  Users such as myself can add known
introduced bugs to the list.  Some of these hinder Kermit-12
configuration, and are documented in K12MIT.BWR accordingly.  Others,
such as ODT's system crash when certain keys are pressed, etc., are well
known.

    Most of the incompatibilities stem from expedient changes made to
OS/8-OS/78 by a small group of "volunteers" within DEC.  Some are
ill-advised personal-preference changes (such as changing the prompt
character a few times!) while others are "band-aids" on certain
hardware-specific problems.  The release notes reveal that certain OS/8
commands are actually "hazardous to your health" and must be avoided in
OS/278 even though they are present!

    The console problem actually first surfaced in OS/78 V4, which was
written in an attempt to minimize the impact on OS/8 on the DECmate I.
When this "bastardized" system is used on either an -8 or DECmate I, it
behaves as a "wimpy" subset of OS/8 because certain features have been
totally dropped.

    What has happened is that the keyboard handling is limited to only
what can be done in simple-minded console routines known to only require
the compatible subset of both the -8 and the DECmates.  Former features
are excised out or are sometimes attempted as "fake" simulations of the
former feature.  OS/278 V2 takes this "lameness" to a higher level of
implementation, but some bugs have surfaced in a few utilities due to
lack of consistency, etc.

    Other problems with OS/278 are totally reversible, such as the
penchant for changing the prompt character (an unreleased version used >
as a prompt, not the OS/8 . or OS/278 }.), and certain RX handler
conventions arbitrarily incompatible with existing design, etc.  Most of
these "lesser" problems can be overcome merely by obtaining (through
disassembly if necessary) the sources of certain components of OS/278 to
allow certain changes to be made.  (Quite a few system components'
sources were NOT included in DM-111 :-(.)

    There are a few other slushware-related problems, such as
interaction between the simulated console and system HLT instructions,
etc., but these may also be fixable (see below).

3.  How to right the DECmate wrongs.

    To correct all of the DECmate problems will require a lot of effort,
but in theory all is doable.

    I have been recently doing work on overcoming the signature problem,
and a solution is in sight.  There are alternate signature values that
can bypass the corruption problem of the standard formula, assuming
these alternates are "acceptable" for all applications.  (It has not
been proven that all software accepts the alternate values, although
boot utilities accept the alternate values for a bootable volume's id,
and the ROM/slushware RX50 routines accept similar values for RX50.)

    An alternate method consists of implementing "smarter" handlers for
the various operating systems that depend on an upgraded slushware
version.  Slushware support can "repair" the signature area as
necessary, etc., with minimal impact on the handler implementation.

    The tradeoffs of these two methods will be the subject of a separate
discussion.  It is sufficient at this time merely to indicate that both
are theoretically viable; the better method will be chosen later.
Whichever method is implemented, the associated "hazards" will be
eliminated, and the attendant coding can be restored for full OS/8
compatibility.  P?S/8 supports a sufficiently large handler space that
the handler doesn't share OS/8's problem in this area.  P?S/8 will
undoubtedly use one of the two methods, but implemented in a more
straight-forward way within the handler itself.

    I have nearly completed a large project of disassembling the DECmate
II, III ROMs and slushware.  When this is completed, it will be possible
to define the slushware "repair" function mentioned above if deemed
necessary.  The alternate signature value was derived by observing the
code that validates the signature field itself.

    The completed source code for the ROMs and slushware will allow
slushware upgrade.  A bug associated with losing context of the
simulated console output during response to a HLT instruction will be on
the list of slushware problems to fix at that time.  Other improvements
may be definable as well, such as easily re-mapped key translations.
(Someone suggested making COMPOSE CHARACTER into an alternate ESC key to
bring TECO command completion back to the left hand, etc.  COMPOSE
CHARACTER (re-mapped to ESC) and the CTRL key could optionally be
swapped, etc. These translations would be possible using a simple PRQ
trapped function call to upgraded slushware.)

    The main problem with the console is NOT completely solvable; the
interface is simply not compatible, and cannot be changed.  What can
change is the system's demands on the interface to allow the DECmate
subset compatibility to be sufficient.

    P?S/8 has already been adapted to depend on merely this form of
subset compatibility.  The main issue is to define a software abort (^C)
bit so that the hardware need not "remember" this status as is currently
demanded by OS/8.  All generic P?S/8 programs detect ^C using the subset
instructions only, and then set the soft bit if required.  The keyboard
monitor is also able to sense the hardware re-read of a ^C character if
P?S/8 is running on a (pre-DECmate) compatible machine, so programs
which by nature are NEVER run on DECmates (such as the TC08 DECtape
Formatter) need not be upgraded to this specification.  All generic
system programs, such as PAL, must completely conform to the
specification however.

    OS/8 can also be modified to incorporate an analogous scheme that
implements a "soft" abort bit; a tentative model has been defined.  When
this is implemented, the DECmate keyboard interface will be acceptable
(just barely).

    The DECmate console output interface emulation is only slightly
incompatible with the PDP-8.  By careful design it is possible to use
completely compatible output routines on all PDP-8s and DECmates.  Only
one minor quirk of the interface is not supported on the DECmate having
to do with testing and clearing the flag which is avoidable.  By
demanding rigorous control of the output flag in all programs, this
problem is easily solved.  Most programs already conform to this minor
restriction; there seems to be no reason for any inherent problem other
than enforcing the rules.

4.  What else should be done?

    As long as this much effort is being applied, there are a few other
areas to clean up:

    Certain components of OS/8 have become "obscure" in more recent
system releases such as RESORC, etc.  Part of this is a "political"
problem such as the abandonment of programs such as BUILD, etc., as well
as various older handlers (the "Pre-Omnibus" edict).  This situation is
totally reversible since sources of all of these OS/8 components are
available.

    It is necessary to scan all programs for inadvertant use of superset
instructions requiring more than the classic PDP-8 instruction set.
These instructions have "crept" into the code over the years.  Most of
these problems are oversights introduced by programmers unaware of the
requirement (to avoid BSW, IAC RAR, CAF, etc.).

    Some OS/278 code is inexplicably flawed; certain basic system
functions such as the SAVE command just don't work!  Comparing the code
to an older version should reveal the problem.  (If it isn't broke,
don't fix it.  But they fixed it anyway, so now it's broke.  So now you
have to fix it.)

    Interrupt-driven routines should make a special-case check for
DECmate operation because the interrupt operations will likely be too
inefficient for DECmate use.  They should be abandoned in favor of
simple-minded non-buffered output routines on a DECmate.  Some of this
reasoning needs to be applied to OS/8 Fortran IV and BASIC.

5.  So will a DECmate ever be accepted as a PDP-8?

    Some "purists" will never accept the DECmate as a PDP-8, because
they want all of the onus placed on the DECmate to be totally PDP-8
compatible with no change.  Clearly this will never happen.  Since much
of OS/78 V3 and following isn't PDP-8-compatible currently, this is
clearly a time for a code cleanup; the DECmate merely brings this
problem to a head.  It is unacceptable that there isn't one single
version for all models (P?S/8 never had this problem, never will! :-)).

    By applying a little more effort, OS/8's dependence on some of the
more quirky aspects of the console interface will be eliminated.  All
important programs can be easily upgraded to OS/8 Version 5
compatibility.  Space permitting, programs can even make the changes
contingent on recognizing which system is in use, etc., to allow use on
older releases as well, but the main goal is to unify the system, not to
encourage continued fragmentation.

    With wide-spread acceptance of OS/8 Version 5 as the OS/8 version of
choice (and the P?S/8 alternative being as flexible), the DECmates will
finally become acceptable to the Family of 8.

cjl

Date: Mon, 20 Jan 92 11:09:11 +0100
From: [email-masked] (Ignatios Souvatzis)
To: [email-masked]
Subject: forwarded message from Richard Chapman
Reply-To: [email-masked] (Richard Chapman)

Date: Mon, 20 Jan 92 11:09:11 +0100
From: [email-masked] (Ignatios Souvatzis)
To: [email-masked]
Subject: forwarded message from Richard Chapman
Reply-To: [email-masked] (Richard Chapman)
X-Mailer: GNU Emacs 18.57.11
X-Face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a<zYep+xKF
 #bT*3R^y:c[\`nu#xM!i{rBU4aDa5rjv{gYpG}Ia/%nEQ)#k`%i+5=<BUNMyI@ZJ99=(t<D`cNq8{7
 _2c{-MG7.mD[47~'BmMl-duJ3?oiTogca-c:dNgOZUEM@-$'5ZwAXe
X-Planation: X-Face can be viewed with "faces". Contact [email-masked]
        for details or ftp iuvax.cs.indiana.edu, directory pub/faces

Just read this in alt.folklore.computers. As I can't help him myself,
and he probably isn't subscribed to the list (If he had sent the
request here, I would have got it through the list...) I'm forwarding
it. You should better reply to R.C. than to me or to the list.
			Ignatios Souvatzis
------- Start of forwarded message -------
From: [email-masked] (Richard Chapman)
Newsgroups: alt.folklore.computers
Subject: my pdp-8 can't add
Date: 17 Jan 92 02:07:40 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

Being unable to find a worthy cause to donate my non-deterministic
pdp-8 to, I've decided that my next project should be to try to fix
it. I acquired it at an auction for $5, and this is the first time in
my life I've programmed a pdp-8. The only documentation I've got is a
copy of _Introduction to Programming_ for a pdp-8/E that tells me
instruction formats. No schematics or maintenance info at all. Maybe
someone here can help.  The machine is a bare pdp-8/L with 4k core. I
toggle in programs on the front panel and run them. I haven't bothered
with trying to get a tty hooked up yet, since the cpu itself has a
problem.  Here is the problem:

If I toggle in the following program to load the accumulator and
increment it add infinitum (all numbers are in octal; don't flame my
lack of knowledge of pdp-8 assembler syntax; I'm assembling by hand)

   addr   contents   mnemonic                comment
   1000   7200       CLA                     clear accumulator
   1001   1204       TAD 1004                load acc with contents of 1004
   1002   7001       IAC                     increment acc.  
   1003   5202       JMP 1002                jump to 1002
   1004   3000                               this is data

The accumulator has the following contents as I single step through
the program: xxxx, 0000, 3000, 3001, 3002, 3003, 3004, 3005, 3006, 3007, 3000, 
3001, 3002, ... ,3006, 3007, 3000, ... 
so there is never a carry into the 8's bit. 

If I change location 1004 to hold 3010, that bit loads correctly, but
the third IAC zeroes it, i.e. the sequence of accumulator values becomes
xxxx, 0000, 3010, 3011, 3002, 3003, ...

So, it looks like everything but that bit of the accumulator is
working.  Addresses are calculated correctly; loads and stores work.
I can load into that bit and clear it, but ALU operations don't set it
correctly. Maybe it is a single bad transistor or ttl chip or
something. Can anyone point me to the right place in the innards of
the beast? I would love a reply like "swap flip-chip modules blah and
blah and see if the problem goes to bit 7. If so, replace flip-chip
blah." If only it were that easy... Any help appreciated. 

Richard "Manuals? we don't need no steenking manuals!" Chapman
------- End of forwarded message -------

Date: Fri, 24 Jan 92 11:51:27 -0500
From: [email-masked] (Richard Chapman)
To: [email-masked]

Date: Fri, 24 Jan 92 11:51:27 -0500
From: [email-masked] (Richard Chapman)
To: [email-masked]

First, thanks to all those who responded to the message that was
forwarded by a kind soul to this mailing list. Now I am on the list,
and that problem is "fixed". The reason for the quotes is that I think
I may have removed the symptom but not the disease. The M220's in the
accumulator seems okay; permuting them didn't have any effect. The
thing that did have an effect was removing an M516 module from the
rear of the backplane, the front of a group of three magenta
flip-chips off in a corner. Several things here; maybe the flip-chips
are in the wrong places, maybe someone just shoved them in when the
machine was junked. I don't know. I think the chart that needs to be
consulted is called "Utilization of modules". Or, something else is
wrong and somehow I disabled the bad boards somehow by pulling the M516,
which is labelled "positive bus receiver". Help?

Now, all the instructions except IOT seem to work. All the IOT instructions
(I tried the instructions 600x (turn interrrupts on/off, etc, 604x
(control the tty printer) and 603x (control the tty reader)) suffer
from two problems:

1. They set the two's bit in the accumulator
2. They skip the next instruction (some instructions are supposed
to do this, based on a flag value, but not all of them, right?)

For example, if I run a 6046 (TLS) instruction at address 1000 with
0241 in the accumulator, I get ascii 0243 printed on the tty, 0243 in
the accumulator, and the next instruction executed is the one at address
1002. My impression is that I should get 0241 in the accumulator and 
address 1001 next. Help?

Here is a description of what modules are where, if you turn the
machine upside down and take the cover off. As far as I know the only
things that should be in there are the cpu, 4k core memory and support
logic (the green and white), and the interface to a teletype (magenta
in the back). Thanks for any help you can give,

Richard Chapman 

		       FRONT

A		B		C		D
M220------------M220		M113		M111
M220------------M220		M700		M700
M220------------M220		M216		M115
M220------------M220		M113		M310
M220------------M220		M216		M310
M220------------M220		M111		M310
M617		M617		M216		M310
M617		M617		M115		M160
M160		M160		M119		 --
M115		M216		M117		 --
M160		M111		M115		M113
M160		M113		M117		M111
M115		M119		M113		M310
 --		 --		M113		M310
 --		 --		 --		M216
 -- 		 --		M360		M617
G020		G020		G221		G221
G020		G020		G221		G221
G020		G020		+------------------+
W025		W025		|	core	   |
W025		W025		+------------------+
G228		G228		G221		G221
 --		G228		G221		G221
G624		G624		G228		G228
G624		G624		M002		 --
G826------------G826		M623		M623
G785------------G785		M115		M623
 --		 --		M660		M906
 --		 --		M660		M906
M516		 --		M707------------M707
M516		 --		M706------------M706
M111		 --		M452		W076D

		       REAR