From cjl@maestro.com  Ukn Jun  3 13:59:33 1994
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA11123; Fri, 3 Jun 94 13:57:12 EDT
Date: Fri, 3 Jun 1994 09:20:22 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Some more PAL considerations, etc.
To: pdp8-lovers@ai.mit.edu
Cc: Charles Lasner <cjl@maestro.com>
Message-Id: <Pine.3.07.9406030922.A6649-f100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 

As several people (this started on alt.sys.pdp8) have been concerned about
PAL assembler features (presumably for the purpose of being written into
cross-assemblers for -8 code on unix, etc.), I want to address two major
areas of compatibility, namely conditional assembly and the proper
implementation of LINC mode cross-assembly.  (Note: conditionals appear
profusely in many programs such as OS/8 family systems' source code,
significant user programs, etc.  LINC code is found in various programs
designed primarily to run on the LINC-8 and PDP-12.  Often, due to poor
implementation, the code is "uglified" to make it PALatable, but not doing
the right job by the LINC architecture, etc.)

Conditionals.

In the world of PAL code, there are four standard conditionals, and a wish
list of others which do exist in certain assemblers.  For most purposes,
the four basic ones can do most (but not all!) of the features that are
generally needed:

	IFZERO	expr	Assemble the following code if the expression
result is zero else flush the following code.

	IFNZRO	expr	Same only if non-zero.

	IFDEF	symbol	Same only if the stated symbol is currently
defined.  Note that the argument *must* be a symbol while any expression
(which must be present!) is allowed in IFZERO and IFNZRO.

	IFNDEF	symbol	Same as IFDEF only if the stated symbol is
currently not defined.

All conditionals use the same general form:

	IFxxxx	expr!symbol	<code to be conditionally assembled which
can be multiple lines>

The "<" starts the conditionaly assembled statements and the ">" ends the
conditional section.  Note that in fact the "<" is what ends the
expression scan following the IFxxxx since otherwise the conditional code
itself would be part of the expression being evaluated!

In the IFZERO and IFNZRO case, anything is allowed as long as it returns a
value, i.e., if it were not a conditional, it would generate a 12-bit
value that would get assembled as an outputted value at the current
location counter.  Here are some semi-perverse examples of what is, and
what is not allowed:

	IFZERO	1	<this is never assembled>

This is perfectly legal and is one way to create a comment.  In
conjunction with the use of XLIST, it can be cosmetically used to document
code, etc.

	IFNZRO	(FOO)	<this likely is assembled>

In this case the current page literal gets created as a byproduct while
its address is returned as the subexpression value.

	IFZERO	A=3	<syntax error>

This is specifically not allowed because no value is returned, rather the
statement is being used as an equate to define a symbol.

	IFNDEF	J+1	<syntax error>

This is not allowed because IFDEF and IFNDEF use a restricted form of the
expression scan that only allows precisely a single symbol name.

	IFDEF	OCTAL	<likely will assemble>

This is allowed, since a pseudo-op is certainly defined.  Should it
matter, the value returned through the expression scan is the 12-bit
address of where the routine that handles the directive is.  Thus, the
following could make sense:

	IFZERO	2741-OCTAL	<the assembler with the OCTAL routine at 2741>

except for one thing: In general, pseudo-op directives aren't allowed in
expressions!  However, this is legitimate in the IFDEF and IFNDEF cases:

	IFNDEF	PQS	<PQS=0>
	IFNZRO	PQS	<P?S/8 PAL assembler specific code that PAL8 can't
handle goes here>

The reason this is valid hinges on two things:  Both PAL8 and P?S/8 PAL
allow pseudo-ops in IFNDEF and IFDEF.  the PQS pseudo-op is not a defined
symbol in PAL8 thus the IFNDEF is true during pass 1 of the assembly, thus
defining it as 0000 is allowed.  (In P?S/8 PAL, the PQS symbol is both
defined and specifically a pseudo-op, thus *not* redefinable!  But it can
be checked whether it's defined or not, etc.)  Thus, if PAL8, this is an
ordinary symbol that was set to a value of 0000.  If P?S/8, the PQS symbol
returns its 12-bit routine address value which is never 0000 and thus
drives the conditionalized code as stated in the example, etc.  In P?S/8
PAL, the PQS pseudo-op doesn't have any functional associated action as a
directive, and is present merely to allow this particular usage.  (Note:
there are other P?S/8 PAL unique directives; any could have been used for
this purpose, but one could hope that eventually PAL8 supported them!  In
any case, PAL8 lacks the notion of an assembler-specific feature
currently, thus assuming the other pseudo-ops got implemented but a
self-ID'ing symbol did not, this code involving the PQS directive would
always function as intended, etc.  Of course I welcome someone
implementing the PAL8 directive in an analogous way, etc.)

There is also a subtle issue regarding the execution of directives.  The
following code is *not* legal in PAL8, even though it's fine in both the
PAL10 cross-assembler for PDP-8 code (that runs on the TOPS10 system on
PDP-10's) and in P?S/8 PAL: 

	OCTAL	13

The problem is that the demented expression scan of PAL8 has "holes" in it
where certain perverse cases are allowed while others are not.  In this
case, the reason is that there is a need to prevent attempts such as:

	OCTAL=1

which is clearly illegal.  But in the clumsy implementation, the following
otherwise reasonable statements aren't allowed:

	TAD	(DECIMAL -10)
	DCA I	(OCTAL	1777)

Thus, in general, in PAL8 you are limited to pseudo-ops being used alone
in a statement while in PAL10 and P?S/8 PAL you can use them more freely
as long as you aren't attempting to redefine them.

In the example of IFNZRO PQS the PQS directive is being executed. 
Similarly, PAL10 and P?S/8 PAL would allow:

	IFNZRO	DECIMAL

which returns the 12-bit address of the DECIMAL directive for the benefit of
the expression scan but also as a byproduct executes the DECIMAL
directive.  That of course changes the current numeric radix.  The PQS
directive is essentially a NOP regarding its action, thus it merely
returns the 12-bit address value to the expression scan.  Note in the
DECIMAL case, the expression returned is the address of the DECIMAL
pseudo-op in P?S/8 PAL because the rest of the expression is null.  In
PAL8 the returned expression value is 0000 because the rest of the
expression is null.  This isn't a consequence of the conditional, but
rather the specifically different interpretation of what is allowed to be
in the same statement with certain pseudo-ops, etc.  Additionally, PAL8
would likely treat the result as a vacuous expression and give an error
message.  Either assembler will complain about clearly vacuous statements
such as:

	IFZERO	<syntax error>

since there is no scannable expression at all.

So, the code to check which of the two assemblers this is couldn't work
for a PAL8 equivalent in the current PAL8, since PAL8 wouldn't let us
access it this way!  Of course one could always add an ordinary permanent
symbol to PAL8 that would be equivalent to the following:

	PAL8=1
	FIXTAB

except of course that this would be done for you already, etc.  This would
allow a similar form of PAL8-specific conditionals, except that you could
always modify the symbol while in P?S/8 PAL you cannot:

	IFNDEF	PAL8	<PAL8=0>
	IFNZRO	PAL8	<PAL8 specific code>

	PAL8=	0	/ACCIDENTALLY REDEFINED THE SYMBOL PAL8!

The accidental usage ruins the conditional should it appear before the
conditional testing statement, etc. while the P?S/8 PAL method is immune
to this.  In fact, the statement PQS=0 is in fact illegal in P?S/8 PAL and
leads to an error message in the same way as either assembler disallows:

	OCTAL=0

since redefining a pseudo-op is illegal, etc.

Another issue of conditionals surrounds the problem of nested
conditionals.  Conditionals as currently implemented (and there are
literally hundreds of programs and many thousands of usages that depend on
this!) define the following:

<	Only legal as the termination of an expression within the context
of a conditional in progress.

>	Ignorable.  If the conditional fails then all of the
conditionalized statement is flushed including this > character.  Assembly
continues after the > character as if the conditional had never occured. 
It could be argued that the assembler should "remember" that a non-flush
has occurred, i.e., that a conditional succeeded and prevented statement
flush, but in point of fact, generally the presence of trailing >
characters is ignorable.  In some idealized assembler, extra > characters
that do not balance against < characters could be complained about, but in
P?S/8 PAL, they are merely ignored because they could be the result of
highly nested conditionals that didn't flush earlier, etc.

There is a curious issue here however:  the definition of just how to
flush the input.  As currently defined, conditionals are completely
nestable.  Thus, as a conditional flush is being performed, < characters
could be encountered that are part of a conditional statement within the
flushed area.  Thus, encounters with < merely up the flush count and >
characters decrement the flush count; reaching a count of 0000 terminates
the flushing operation.

But what of < and > characters within comments?  The current definition is
that there is *no* distinction made!  Perversely, programmers have
incorporated balanced "pairs" of the characters within their comments! 
(Kind of reminiscent of a similar situation used by TECO macro writers;
some versions of TECO have an "old macro" flag to handle it both ways, etc.)
Thus, a practical assembler must at least implement the compatible
brain-dead method to avoid rewritting a whole bunch of rather tricky
source lines that use these quirks to the fullest, etc.  Thus, while we
would like to see statements of the form:

	IFNZRO	TEST	<TAD I	FOO>	/COMMENT

What we instead see is:

	IFNZRO	TEST	<TAD I	FOO	/COMMENT>

and we have to allow it.  There are too many examples to bother
restricting ourselves to what we would rather see, etc.  A newer assembler
could consider an option switch to disallow the latter, but the default
better be to allow it!

Depending on whether in PDP8 or LINC mode, the I pseudo-op takes on two
different functions and values.  In PDP-8 mode, I causes the need to OR
into the expression 0400 to enforce the indirectness bit, and also to
check whether this is valid.  (If already indirect, this is an "II"
(Illegal Indirect) error.)  Thus, I is not only a pseudo-op to first check
if indirectness is not currently present else complain and then force
indirectness, but also returns a value, namely 0400.  In LINC mode, I
merely OR's into the expression the value 0020 and has no other meaning,
since it's context dependent as to what the 0020 accomplishes (and is
beyond the province of the assembler to check for).  (In LINC mode, I can
mean several things:

	LDA I;3		/LOAD AC WITH 0003

Note that this is two statements sometimes stated as:

	LDA I
	3

In any case, ORing 0020 into the symbol for LDA is what's required.  What
it means is that immediate addressing has been specified; the argument
lies in the next word.

Alternatively, the programmer could use:

	LDA; 3		/LOAD THE CONTENTS OF 0003

In this case, the I is not present, and the next word is taken as the
address of the operand.  Clearly the assembler cannot determine whether
the I should be present or not.

In yet another case:

	ADA I	10	/AUTO-INDEX ADD THROUGH THE UPDATED CONTENTS OF 0010

This works just like the PDP-8 instruction TAD I 10 in that locations 1
through 17 (called Beta registers) are all auto-increment when used this
way.  The usage makes no sense unless the address is within this range. 
Indeed, it must be that way as making it 0000 causes the above cited form
where the next word is either the address of the operand, or if 0020 is
OR'ed into the instruction the next address is the immediate operand itself.

Additionally, the usage

	ADA	10	/POINT THROUGH 0010 BUT DON'T BUMP

is the use of 10 as merely a pointer *without* auto-increment.  (A useful
feature the PDP-8 lacks!  Once the auto-index is updated in -8 mode, you
can't reference it again as that would again increment it.  Instead, if
the pointer is needed again, 0010's contents have to be moved elsewhere. 
Indeed, LINC coding changes the rules about whether or not auto-indexing
is the best way to handle lists, etc.  In -8 mode, clearly auto-indexing
should be avoided if multiple accesses are required, or alternatively two
auto-index registers are allocated if the multiple accesses are
guaranteed, else it's better to not use auto-index registers at all and
use explicit ISZ instructions when the pointer update is required, and
additionally, the nuisance value of specifying ADDRESS-1 instead of
ADDRESS is avoided, etc.  But in LINC mode, you can do it both ways with
the same register, thus LINC code needs a rethink of how best to implement
similar things, etc.  In any case, the assembler has no business
determining whether I should be present or not in these situations, etc.)

A similar situation exists with a small handful of LINC instructions that
refer to the set of Alpha registers which is 0000-0017, not 0001 to 0017. 
In this case, a location less than 0020 is always required because the
usual case of four addressing modes doesn't apply:

	SET I	0;3	/SET 0000 TO 0003

In this case, the specified Alpha register is being set immediate to the
following value.

	SET	0;3	/SET 0000 to what's in 0003

Leaving the I out means the next word is a pointer.  Again, the assembler
has no business in this decision as to I's presence or absence, etc.

Taking the lead of the OS/8 program PAL12, P?S/8 PAL implements I to
provide the two variations correctly.  Additionally, due to lack of PAL8
parsing problems, P?S/8 PAL allows the syntax "I" without any other
subexpression which returns 0400 or 0020 accordingly.  This allows I to be
used in expressions such as:

	1+I

or	I+1

Remember that I forces indirectness bit in -8 mode  (0400) and immediate
mode (0020) in LINC mode by ORing the value into the expression.  Yet,
P?S/8 PAL allows expressions such as

	I I

or 	I+I

The reason for this is that simple expressions are *not* MRI scans. 
Without a leading TAD or whatever, I takes on the simple value of 0400
OR'ed into the latest sub-expression allowing simple arithmetic as
required, etc.  Quirky PAL8 parsing leads to strange restrictions such as

	0+TAD

is allowed while

	TAD

is not allowed.  Additionally

	TAD+0

is considered illegal on PAL8.

A consequence of this is that the FIXMRI instructions have to be of the form

	FIXMRI	CALL=	JMS I	0

While in P?S/8 PAL, this can be simplified to:

	FIXMRI	CALL=JMS I

It appears that PAL8's parsing method is that MRI scan demands an
argument, and that I is merely noted along the way.  As a further result,
contrived statements of the form:

	*1200

	TAD	TAD	.

Are legal in P?S/8 PAL but illegal in PAL8.  P?S/8 PAL pushes down the
state of MRI-in-progress in each scan call, while PAL8 merely does it
during ( or [ literal processing.  And as a further consequence, PAL8 gets
totally wrong (documented correctly; implemented wrongly) such things as

	TAD	(377)+1

so it assembles as if it were

	TAD	(377+1)

which is totally useless!

The Z pseudo-op takes on a different meaning entirely from I.  While I
forces indirectness in MRI scan situations, Z can be implemented one of
two different ways:

1)	Force page zero reference.  This was the reason it was left in; to
assemble old PAL II code (such as the most famous, the source of PAL III
written in PAL II), that ancient assembler was so brain-dead, it required
that the user ensure the page zero reference explicitly!  Thus, in PAL II
source code, you would often see:

	TAD I Z 10

Instead of

	TAD I	10

because PAL II was that ignorant.

Thus, Z compatibility means to force statements to be on page zero.  For
example:

	*200

	TAD Z	.

would generate a reference to 0000 instead of 0200!

This actually wasn't the intention of the implementors of the original Z,
rather to "help" the brain-dead PAL II to understand what every
PDP-8-based -8 assembler has known how to do since the days of PAL III,
namely to realize the actual page zero address of the operand, etc.

2)	Just ignore the Z.  P?S/8 PAL has flip-flopped on this one and has
finalized with this.  There doesn't seem to be any practical reason to
force page zero, since when writing your own code you shouldn't need it,
and literally all of the old code is already attempting page zero
reference whether the Z helps or not, etc.  I believe that PAL8
implementors were gravitating in this direction also.

In any case, I and Z are pseudo-op symbols in the permanent symbol table. 
Another reason why is that they must not be expunged when the EXPUNGE
command is given, since there's no way to redefine them!  (The EXPUNGE
command is used when a custom symbol table is being created, or perhaps to
eliminate seldom-used symbols from the table to get back more assembly
space, meaning it might make the difference as to whether an assembly can
be accomplished at all in smaller memory machines, and/or the assembly
goes faster when the table is smaller, etc.)

However, PAL8 chooses to implement them in a more brain-dead way:

Each symbol is held in radix-45 notation.  Thus, the largest symbol is
Z99999 leaving exactly 2 free bits in three 12-bit words for symbol types.
One of these four states is wasted as "This symbol is I or Z; handle
special" instead of merely being a normal pseudo-op.  The other cases (in
both P?S/8 PAL and PAL8) are:

Symbol is undefined

Symbol is defined



Symbol is permanent symbol

Symbol is not permanent symbol

(Permanent symbols can't be undefined!)


Symbol is an MRI

Symbol is a pseudo-op

In P?S/8 PAL, the fourth state is used more functionally:  The symbol is
defined by a label as opposed to merely an equated symbol.  This shows up
in the symbol table printout of P?S/8 PAL, but also has a specific usage
in LINC mode:

In LINC mode, the addressing rules are different.  The memory scheme is
basically a 10-bit space that should pass the symbol&1777 back to the MRI
processor for statements of the form:

	ADD	FOO

which returns FOO&1777 whereas -8 processing would return FOO&177 possibly
OR'ed with 0200 if it's a current-page reference only.  Else it's on page
zero or an illegal statement to be dealt with elsewhere (error messages or
generated link, etc.)

But LINC mode also has usages such as

	LDA;	FOO

where the FOO&1777 is required to prevent unwanted side-affects!  OR'ing
in unwanted bits can do strange things.  For example, 2000 causes the
instruction to use the DF not the IF, and in the case of
half-word-oriented instructions, 4000 sets which half-word is being
accessed.  Thus, it's crucial to return the 10-bit address, not the 12-bit
address.  A lot of PAL12 and DIAL-MS code uses stuff such as:

	LDA;	FOO&1777

or even

	LDA;	FOO&1777!2000

when the DF is required.  In any case, it's often a programmer's error
when the two hi-bits slipped in, etc.

To overcome this, P?S/8 PAL uses the defined-by-label property of the
symbol to know how to deal with it.  In LINC mode, label symbols are
stripped of the two hi-bits for their address value.  Equated symbols are
not stripped because when used for other purposes, they need their 12-bit
values explicitly.  (Note: anyone could ask for trouble by demanding an
equated symbol to be used as if a label symbol, but in such a case, the
user beware and AND and OR constructs better be used accordingly!)

Additionally, if the 2 hi-bits of the symbol differ from the current 1K
segment, the returned value is the SYMBOL&1777!2000 to force the DF bit as
the hardware requires.  (Again, unless the symbol is defined by label,
this is not performed and the 12-bit value is passed back unscathed, etc.)

(Note: P?S/8 PAL only stores the 12-bit address of the symbol.  A superset
of this feature would maintain 15-bit addresses to enhance both the symbol
table printout and the ability to implement the DF-sensitive feature. 
Thus, P?S/8 PAL will not handle the anomaly of a symbol defined in a
different field but in the same memory segment (field/4) as deserving the
!2000 operation, etc.)

Additional LINC mode changes are that in LINC mode, all operations are in
one's complement with end-around carry.  Note that the only way to
generate 0000 is directly, as expressions such as .-. generate 7777 (-0).

P?S/8 PAL also supports the DIAL-MS assembler pseudo-ops primarily created
for the benefit of LINC code, but actually general purpose:

	ASMSKP expr

This skips the number of lines of assembly input specified by expr.  A
value of 0000 means to not skip any.  Since one's complement arithmetic is
in effect in LINC mode, 7777 also means to not skip any!

	ASMIFM	expr	STATEMENT

The STATEMENT represents anything on the rest of the line, essentially a
conditional one-line flush depending on whether the expression is negative
or not.  Similarly there is

	ASMIFZ expr	STATEMENT

to assemble if the expression is zero and

	ASMIFN expr	STATEMENT

to assemble if the expression is non-zero.  Notice that they are often nested:

	ASMIFN	FOO	ASMSKP	10	/SKIP THIS AND THE NINE LINES THAT FOLLOW

This avoids the anomaly of the < and > which was probably on their minds
at the time, etc.  (DIAL-MS doesn't have the IFxxxx directives, etc.)

On the wishlist are directives from an obscure assembler for FLAP-like FPP
assember and much-more compatible -8 code that was written for DIAL-MS
specifically called FPPASM.  This assembler supports the directives  IFREF
and IFNREF referring to whether the symbol following (sort-of like IFDEF
and IFNDEF) was used so far in the assembly.  If not referenced, the
symbol isn't present in the table.  If referenced, it would be undefined
but in the table as such.  This allows source libraries to be created, to
be conditionally tacked onto the end of a program if required.  Of course
it can be fudged by IFDEF and IFNDEF, but that requires the programmer to
explicitly state them in some form of reference statement, and could be a
problem if defined because all assemblers will complain when a statement
defined by label is being attempted at a redefinition other than it's
current value.  The following is all legal:

	*200

	FOO=	.

	*200

FOO,

	*200

FOO,

	*200

FOO,	FOO=	.

but to be used with IFDEF/IFNDEF would require that the user already know
the address of the routine to avoid the error message, or alternatively,
the library be written with the awkward:

	FOO=	.

	.-.			/ENTRY POINT

instead of

FOO,	.-.			/ENTRY POINT

The IFREF/IFNREF eliminates this problem.  (These are on a P?S/8 PAL
wish-list and could also be added to PAL8.)

There is one additional LINC mode problem: anomalous symbol values.  PAL12
and P?S/8 PAL handle it in different ways.  (Note:  while a lot of good
work was done to create PAL12, a lot of its shortcomings stem from the
fact that it is an outgrowth of a very early PAL8 version that is quite
different from more recent versions.  Had the PAL12 authors waited a few
years, it would be a far better program!)  

Like DIAL-MS, PAL12 handles LINC mode symbols as a separate table.  This
leads to problems where some symbols cannot be referenced because it's the
"wrong" mode.

P?S/8 PAL avoids this by using only one table and a "swap" trick:  There
are only a handful of actually troublesome symbols such as:

I (handled elsewhere according to the current mode)

and non-MRI symbols such as SKP, HLT, NOP.

To solve this, each time the LINC and PDP mode change pseudo-ops are used,
the symbol table values are swapped out into a temporary area that is
initialized to the LINC values by default while the -8 values remain in
the main table.  (If the /9 switch is passed, an initial swap is performed
because the assembler then starts in LINC mode without an explicit LINC
directive in the source, etc.)

The reasons the tables are swapped is then they are also subject to the
user's use of EXPUNGE and equates and FIXTAB.  (Note: there are several
variant definitions of the SKP instruction for various LINC CPU's.  Thus,
different systems may need the ability to redefine the SKP definition,
which defaults to the PDP-12 normal value in the LINC table, etc.)

Thus, normal -8 and LINC code never clobber the tables, etc.  Only true
perversions such as deliberate use of two definitions of the same symbol
in the two modes demanding to be different wouldn't be handled by this
implementation.  (There is only one known problem anomaly:  The PDP
pseudo-op tells the assembler what mode to operate in.  On the LINC-8, the
value 0500 is a trapped LINC CPU instruction that is normally defined in
PROGOFOP to mean call (via JMS convention somewhere else) the PDP-8
subroutine located in field 0 whose address is currently in the LINC's AC.
In some sources, PDP=500 is found to carry this out.  To totally avoid
this, DIAL-MS, PAL12, and P?S/8 PAL have changed the symbols to avoid this
"collision"  by using PMODE and LMODE to change modes.  The symbols LINC
and PDP are ordinary (albeit permanent) symbols that can be redefined as
required.  Thus, the following is currently legal for LINC-8 code in P?S/8
PAL and uses features not available in either PAL12 or DIAL (DIAL has no
literals at all, and PAL12 can't handle literals in LINC mode):

	SEGMNT	2

	LMODE

	PDP=	500		/DEFINE PDP-8 CALL TRAP (DEFAULT IN P?S/8
PAL WAS 0002, THE PDP-12 INSTRUCTION VALUE)

	LDA I;	(FOO)		/GET ADDRESS OF -8 SUBROUTINE
	PDP			/CALL -8 ROUTINE
	HLT			/LINC HALT

	PMODE

FOO,	.-.			/-8 SUBROUTINE CALLED BY PROGOFOP FOR
LINC 0500 TRAPS
	JMP I	FOO		/RETURN TO PROGOFOP AND EVENTUALLY TO LINC CODE


As long as literals are avoided, and the appropriate use of equate
statements, &1777 and !2000 are applied, DIAL or PAL12 can handle (most
of) this, but P?S/8 PAL allows the code to flow as it should, etc.  (Note:
the PDP-8 addressing rules are used in the applications of the literals. 
This could conflict with long sections of LINC code!  Most LINC-8 and
PDP-12 programs use short LINC sections though, and further, since DIAL
doesn't even support literals at all, this isn't generally a problem!)

I lumped all of this together, because it gives would-be cross-assembler
implementors an idea of how the stuff interacts.  I think that being a
full-fledged -8 assembler is a bit more work than many people thought it
was!  (And we've discussed elsewhere stuff such as RELOC, etc.)

cjl


From taylor@umfort.ecsu.edu  Ukn Jun  6 12:38:55 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA06012; Mon, 6 Jun 94 12:37:48 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA22688; Mon, 6 Jun 1994 12:38:03 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA20122
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Mon, 6 Jun 1994 12:37:17 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA15145
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Mon, 6 Jun 1994 12:37:14 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA19727; Mon, 6 Jun 94 12:17:14 EDT
Return-Path: <taylor@umfort.ecsu.edu>
Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA19722; Mon, 6 Jun 94 12:17:05 EDT
Received: from [198.85.48.31] by mc.lcs.mit.edu id aa10296; 6 Jun 94 12:15 EDT
Received: from sun1.ecsu.edu by  umfort.ecsu.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA27379; Mon, 6 Jun 94 09:08:53 PDT
Date: Mon, 6 Jun 94 09:08:53 PDT
From: Taylor Harrell <taylor@umfort.ecsu.edu>
Message-Id: <9406061608.AA27379@ umfort.ecsu.edu >
To: pdp8-lovers@mc.lcs.mit.edu
Subject: subscribe
Status: RO
X-Status: 

subscribe pdp8-lovers Taylor Harrell


From bobsmith@opus.ai.mit.edu  Ukn Jun  8 20:44:52 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA26969; Wed, 8 Jun 94 20:43:46 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA12109; Wed, 8 Jun 1994 20:47:04 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA09847
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Wed, 8 Jun 1994 20:46:54 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA14656
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Wed, 8 Jun 1994 20:46:52 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA22990; Wed, 8 Jun 94 20:25:32 EDT
Return-Path: <rmsmith@opus.ai.mit.edu>
Received: from opus (opus.csc.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA22980; Wed, 8 Jun 94 20:25:25 EDT
Received: by opus (4.1/SunOS-RJD-1.11)
	id AA02405; Wed, 8 Jun 94 20:24:03 EDT
From: bobsmith@opus.ai.mit.edu (Robert Smith)
Message-Id: <9406090024.AA02405@opus>
Subject: recent acquistions
To: pdp8-lovers@ai.mit.edu (pdp8 lovers)
Date: Wed, 8 Jun 94 20:24:02 EDT
Cc: rmsmith@explorer.starlab.csc.com
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

I just acquired two 8a/400 boxes with G8018 power supplies,
processors, mem, moose regan memory managers, and so on.

I also got a raft of older omnibus boards that I do not have a 
need for (databreak, positive bus, lots of td8e boards, 
some analog boards, M833, some M8650s, etc).

I have gotten my old 8a running with a real front panel with switches!!!
I now have three complete 8a's and my complete (core mem) 8e.

What I need is some docs on the 8/a.  Like what do I have to do to
really use the push button switches on the front panel?

I would love to have an fpp8a.
I would love to know what the specs are on the G8018.

I have 7 of Larry Narhi's quad slu cards that I do not need.
(I have enough 8655s now that I am getting fat cause I already dumb
and happy!!)

I also acquired RL8a cards, 7 rl01 packs, 8 rk05 packs, a raft of paper
tape (oh, I have about 9 paper tape/punch interface cards) including some
old old stuff, and a pile of TU58 tapes.

I promised the guy I got all this from that I would get one of the machines up
and running for him so none of the complete machines is up for grabs.

give a shout!!
bob


From rmsmith@csc.com  Ukn Jun  8 21:37:02 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA27943; Wed, 8 Jun 94 21:35:54 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA19154; Wed, 8 Jun 1994 21:37:55 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA11824
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Wed, 8 Jun 1994 21:37:52 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA18201
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Wed, 8 Jun 1994 21:37:51 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA26433; Wed, 8 Jun 94 21:23:28 EDT
Return-Path: <rmsmith@csc.com>
Received: from csc.com (explorer.csc.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA26424; Wed, 8 Jun 94 21:23:21 EDT
Received: by csc.com (Smail3.1.28.1 #11)
	id m0qBYqC-0009sLC; Wed, 8 Jun 94 21:23 EDT
Message-Id: <m0qBYqC-0009sLC@csc.com>
From: rmsmith@csc.com (Robert Smith)
Subject: more data
To: pdp8-lovers@ai.mit.edu (pdp8 lovers)
Date: Wed, 8 Jun 1994 21:23:32 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 144       
Status: RO
X-Status: 

I have two working RK05 drives, I would be willing to swap one
for an rl01/02 ...

I have some RX01/RX02 drives...willing to swap for....

bob


From cjl@maestro.com  Ukn Jun  9 02:52:25 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA04020; Thu, 9 Jun 94 02:52:07 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA20236; Thu, 9 Jun 1994 02:54:21 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA24038
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 9 Jun 1994 02:54:14 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA07972
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 9 Jun 1994 02:54:13 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA08989; Thu, 9 Jun 94 02:31:35 EDT
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA08985; Thu, 9 Jun 94 02:31:33 EDT
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	(rama) id QQwtmw23000; Thu, 9 Jun 1994 02:31:30 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA03695; Thu, 9 Jun 94 02:27:49 EDT
Date: Thu, 9 Jun 1994 02:26:18 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: more data
To: Robert Smith <rmsmith@csc.com>
Cc: pdp8 lovers <pdp8-lovers@ai.mit.edu>
In-Reply-To: <m0qBYqC-0009sLC@csc.com>
Message-Id: <Pine.3.07.9406090216.A2965-9100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Wed, 8 Jun 1994, Robert Smith wrote:

> I have two working RK05 drives, I would be willing to swap one
> for an rl01/02 ...

I don't need any more RK05 drives either; I'll give you the RL01 drives
for the modules I need.  (You win in the weight-gain department :-).)

> 
> I have some RX01/RX02 drives...willing to swap for....

For some people, that's what makes their system viable, but the M8357 is
required, etc.

> 
> bob
> 

cjl


From cjl@maestro.com  Ukn Jun  9 02:55:03 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA04067; Thu, 9 Jun 94 02:54:48 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA20401; Thu, 9 Jun 1994 02:57:09 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA24128
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 9 Jun 1994 02:57:02 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA08084
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 9 Jun 1994 02:56:58 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA08976; Thu, 9 Jun 94 02:29:52 EDT
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA08972; Thu, 9 Jun 94 02:29:46 EDT
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	(rama) id QQwtmv22792; Thu, 9 Jun 1994 02:29:41 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA03669; Thu, 9 Jun 94 02:25:59 EDT
Date: Thu, 9 Jun 1994 02:17:10 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: recent acquistions
To: Robert Smith <bobsmith@opus.ai.mit.edu>
Cc: pdp8 lovers <pdp8-lovers@ai.mit.edu>
In-Reply-To: <9406090024.AA02405@opus>
Message-Id: <Pine.3.07.9406090209.A2965-c100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Wed, 8 Jun 1994, Robert Smith wrote:

> I just acquired two 8a/400 boxes with G8018 power supplies,
> processors, mem, moose regan memory managers, and so on.
> 
> I also got a raft of older omnibus boards that I do not have a 
> need for (databreak, positive bus, lots of td8e boards, 
> some analog boards, M833, some M8650s, etc).

I can use the analog boards to flesh out my not-quite complete LAB-8/e
machine.  

Note that the TD8E boards don't work without the ECO stuff I posted a few
years back.  Apparently DEC never fixed it themselves!

though I don't need them, I upgrade M8650 boards for people to have the
150x2^N baud rates instead of 110 baud using a better oscillator circuit. 
(Basically, I use the can type and trash the pulse transformer et al.)

> 
> I have gotten my old 8a running with a real front panel with switches!!!
> I now have three complete 8a's and my complete (core mem) 8e.
> 
> What I need is some docs on the 8/a.  Like what do I have to do to
> really use the push button switches on the front panel?

The panel isn't much different from the 8/e switches, except you have to
do it in octal.

> 
> I would love to have an fpp8a.
> I would love to know what the specs are on the G8018.

I am looking for exactly one 12-slot box with the G8018 in it so that I
can make a disk server for a PDP-12 using power-fail restart.  The G8016
in the typical 12-slot boxes don't support core memory.  Alternatively, I
have to blast an 82S126 pair in the option board so it will boot my SCSI
system directly, since there never was a DEC version of such a ROM, and
it's not that easy to get a blaster for these chips (not to mention the
chips themselves; they are blast once-only!)  (Alternatively, can anyone
figure out how to interface say 2716 or something in their place?)

> 
> I have 7 of Larry Narhi's quad slu cards that I do not need.
> (I have enough 8655s now that I am getting fat cause I already dumb
> and happy!!)

I have one and one of those back panels that takes two.  If I can get
another cable and another card, I can make it look like a DZ-11 :-).

> 
> I also acquired RL8a cards, 7 rl01 packs, 8 rk05 packs, a raft of paper
> tape (oh, I have about 9 paper tape/punch interface cards) including some
> old old stuff, and a pile of TU58 tapes.

I could use an RL8A or two.  I will give anyone that wants them some RL01
drives as I have too many (about 10 drives!).  A friend who reads this
group desparately needs the M840 reader/punch card.  (I have only one and
it's on my PC04.)

> 
> I promised the guy I got all this from that I would get one of the machines up
> and running for him so none of the complete machines is up for grabs.
> 
> give a shout!!
> bob
> 

Shout! Shout!

cjl


From jones@pyrite.cs.uiowa.edu  Ukn Jun  9 14:34:53 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA14469; Thu, 9 Jun 94 14:34:40 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA28195; Thu, 9 Jun 1994 14:37:27 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA25481
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 9 Jun 1994 14:37:21 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA04929
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 9 Jun 1994 14:37:19 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA05298; Thu, 9 Jun 94 14:16:48 EDT
Return-Path: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA05287; Thu, 9 Jun 94 14:16:42 EDT
Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322)
	  on Thu, 9 Jun 1994 13:16:40 -0500 id NAA06192 with SMTP 
Received: by pyrite.cs.uiowa.edu (5.59/890218) 
	  on Thu, 9 Jun 94 13:16:18 CDT id AA01470
Date: Thu, 9 Jun 94 13:16:18 CDT
From: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Message-Id: <9406091816.AA01470@pyrite.cs.uiowa.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Bob Smith's hardware surplus
Status: RO
X-Status: 


I need an M8360 data break card:  I have an M8350 posibus card, and I'd
like to be able to test my BEO1 (OEM TC01 variant) with my posibus to
negibus converter.  The BE01 really belongs to my 8/L, whenever I can
get that machine up.

I could use an M868 and funny cable to connect it to a TU56 (TD8E):
Someone's mailing me a TU56 and I need some way to run it on an Omnibus.
A TC08P is what I'd really like, but a TD8E would do (sure, I know it's
inferior, but with an RX01 for a system device, the big point is media
compatability with older machines, and it's just right for my 8/F with
short backplane and relatively feeble power supply.

A DEC M840 paper-tape reader-punch interface:  I have an IOmec Digitronics
9602 paper tape reader interface for my IOmec 2540 photoelectric paper
tape reader, but I have no documentation for the board or the cable from
the board to the reader.  The DEC board might be preferable to reverse
engineering the IOmec board (I do have full documentation for the reader
itself), and since I also have a pair of Remex model 550 high speed punches
(without documenation), a punch interface board would be handy!

M8650 asynch I/O boards:  I have 3 of them, but I'd like a 4th so each of
my OMNIBUS machines can have 2.  I have the wherewithal to convert them
to 150 baud (and up), and I've debugged two broken ones so far.  I have
an M8655 I'd rather not deal with (it works fine, but I'm willing to trade
it for about anything), and I have an M865, if anyone really wants that.

Finally, I have 2 RX01 dual floppy drives but only one M8357 board.
Another M8357 would be nice to find.

And of course, I'll always be willing to take an 8K core module for
my PDP-8/F; I have two good 8K SRAM modules for it from Monolithic, but
they're real space heaters (8x12 2102 SRAM chips!), and the 8/F power
supply can barely handle them.

					Doug Jones
					jones@cs.uiowa.edu


From maxwell@acsu.buffalo.edu  Ukn Jun  9 17:01:24 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA17902; Thu, 9 Jun 94 17:01:02 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA16943; Thu, 9 Jun 1994 17:02:51 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04901
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 9 Jun 1994 17:02:31 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA25431
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 9 Jun 1994 17:02:11 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA25335; Thu, 9 Jun 94 11:15:13 EDT
Return-Path: <maxwell@acsu.buffalo.edu>
Received: from lictor.acsu.buffalo.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA25331; Thu, 9 Jun 94 11:15:11 EDT
Received: (maxwell@localhost) by lictor.acsu.buffalo.edu (8.6.8/8.6.4) id LAA29359 for pdp8-lovers@ai.mit.edu; Thu, 9 Jun 1994 11:15:10 -0400
Date: Thu, 9 Jun 1994 11:15:10 -0400
From: John H Maxwell <maxwell@acsu.buffalo.edu>
Message-Id: <199406091515.LAA29359@lictor.acsu.buffalo.edu>
To: pdp8-lovers@ai.mit.edu
Status: RO
X-Status: 

After several attempts to email directly, I guess I need to waste some
bandwidth. Sorry.

-----

Hello Bob,
    Your posting to pdp8-lovers gives me hope to finally get an RL8a for my
PDP8-a. I've been looking for quite a while since no DEC brokers even know
what a PDP-8 is! I did find one dealer willing to sell the board to me
"as-is" for $35. Being a student, I can't really afford to take a chance.
    Let me know if you have any available (as the story usually goes: "you
should have let me know a couple of days ago, I had tons!" :-) and what you'd
want for it. Thanks.

     Cheers,
       John Maxwell                maxwell@acsu.buffalo.edu
       S.U.N.Y. at Buffalo


-----

Please excuse this posting.


From slb22@columbia.edu  Ukn Jun  9 19:47:18 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA21269; Thu, 9 Jun 94 19:46:47 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA04740; Thu, 9 Jun 1994 19:49:09 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA12479
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 9 Jun 1994 19:48:59 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA12210
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 9 Jun 1994 19:48:58 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA22292; Thu, 9 Jun 94 19:31:26 EDT
Return-Path: <slb22@columbia.edu>
Received: from mailhub.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA22288; Thu, 9 Jun 94 19:31:22 EDT
Received: from ciao.cc.columbia.edu by mailhub.cc.columbia.edu with SMTP id AA10763
  (5.65c+CU/IDA-1.4.4/HLK for <pdp8-lovers@ai.mit.edu>); Thu, 9 Jun 1994 19:31:18 -0400
Message-Id: <199406092331.AA10763@mailhub.cc.columbia.edu>
To: bobsmith@opus.ai.mit.edu (Robert Smith)
Cc: pdp8-lovers@ai.mit.edu (pdp8 lovers)
Subject: Re: recent acquistions 
In-Reply-To: bobsmith@opus.ai.mit.edu (Robert Smith) 's message of "Wed, 08 Jun 1994 20:24:02 EDT."
             <9406090024.AA02405@opus> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 09 Jun 1994 19:31:18 -0400
From: Seth "the Lesser" <slb22@columbia.edu>
Status: RO
X-Status: 

Robert Smith said:
[...]
> What I need is some docs on the 8/a.  Like what do I have to do to
> really use the push button switches on the front panel?

I have a huuuge book of 8/a documentation, incorporating preliminary versions
of the tech specs on the processor, DKC8-AA i/o and prog-console ifc, KM8-A
memory mgr, and all of the various memory and power-supply boards.  Includes
complete print sets of all of the above.

If that's what you want/need, I'll be glad to trade copies for any
DECtape-related documentation or specs.

Seth L. Blumberg, M.S.E.  \  So they used a micrometer on her thumbnail. . . .
slb22@columbia.edu          \ Once again, fear and superstition triumphed over
CUSFS President-in-Exile      \           science and technology.
    > No one I know shares my opinions, least of all Columbia University. <


From John_Wilson@mts.rpi.edu  Ukn Jun 10 01:20:33 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA27820; Fri, 10 Jun 94 01:20:02 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA27161; Fri, 10 Jun 1994 01:21:48 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27137
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Fri, 10 Jun 1994 01:21:37 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA05460
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Fri, 10 Jun 1994 01:21:35 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA07061; Fri, 10 Jun 94 00:57:18 EDT
Return-Path: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA07057; Fri, 10 Jun 94 00:57:14 EDT
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41);
	id AA04675; Fri, 10 Jun 94 00:56:59 EDT for PDP8-LOVERS@AI.MIT.EDU 
Date: Fri, 10 Jun 94 00:56:52 EDT
From: John_Wilson@mts.rpi.edu
To: PDP8-LOVERS@ai.mit.edu
Message-Id: <4367387@MTS.RPI.EDU>
Subject: M8357
Status: RO
X-Status: 

jones@cs.uiowa.edu:
>Another M8357 would be nice to find.
 
I already posted about this on alt.sys.pdp8 but not here...
M8357's are still available brand new from DECdirect for $118.
So it just depends on how badly you want one.
 
John Wilson


From bobsmith@opus.ai.mit.edu  Ukn Jun 10 09:46:33 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA03730; Fri, 10 Jun 94 09:46:10 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA00765; Fri, 10 Jun 1994 09:49:33 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA07803
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Fri, 10 Jun 1994 08:51:03 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA07535
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Fri, 10 Jun 1994 08:50:56 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA16393; Fri, 10 Jun 94 08:32:18 EDT
Return-Path: <rmsmith@opus.ai.mit.edu>
Received: from opus ([192.5.222.87]) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA16387; Fri, 10 Jun 94 08:32:13 EDT
Received: by opus (4.1/SunOS-RJD-1.11)
	id AA01628; Fri, 10 Jun 94 08:30:42 EDT
From: bobsmith@opus.ai.mit.edu (Robert Smith)
Message-Id: <9406101230.AA01628@opus>
Subject: 8 modules
To: pdp8-lovers@ai.mit.edu (pdp8 lovers)
Date: Fri, 10 Jun 94 8:30:41 EDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Follow up to my lastest acquisition (I should say HAUL!!):
I will post an inventory of what I have after I figure out
what is left after the responses from folks so far.

I have a bunch of papertape reader punch modules, a bunch of 
PROM and PROM/RAM modules (the 1k variety I think), a bunch
of cassette interface modules, and like I said a raft of TD8e 
interfaces.

I will try to get this inventory done by tomorrow night, and get it
posted.

bob


From slb22@columbia.edu  Ukn Jun 11 22:46:37 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA05619; Sat, 11 Jun 94 22:46:16 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA00801; Sat, 11 Jun 1994 22:49:37 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA00863
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sat, 11 Jun 1994 22:17:17 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA04944
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sat, 11 Jun 1994 22:17:11 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA07647; Sat, 11 Jun 94 22:03:35 EDT
Return-Path: <slb22@columbia.edu>
Received: from mailhub.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA07640; Sat, 11 Jun 94 22:03:31 EDT
Received: from merhaba.cc.columbia.edu by mailhub.cc.columbia.edu with SMTP id AA04342
  (5.65c+CU/IDA-1.4.4/HLK for <pdp8-lovers@ai.mit.edu>); Sat, 11 Jun 1994 22:03:28 -0400
Message-Id: <199406120203.AA04342@mailhub.cc.columbia.edu>
To: erd@kumiss.infinet.com (Ethan Dicks)
Cc: pdp8-lovers@ai.mit.edu
Subject: Re: PDP-8 docs 
In-Reply-To: erd@kumiss.infinet.com (Ethan Dicks) 's message of "Fri, 10 Jun 1994 17:07:37 EDT."
             <9406102107.AA01d7d@kumiss.infinet.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 11 Jun 1994 22:03:27 -0400
From: Seth "the Lesser" <slb22@columbia.edu>
Status: RO
X-Status: 

Ethan Dicks said:
> 
> Let's see... Looking through my easily accessible docs... (i.e., the ones
> actually *in* my house)

> "RK8-E Disk & Control" (B-DD-RK8-E) [2 copies]
I could use that.

> "PDP-8/E computer engineering drawings" (A-ML-PDP8/E-0-AD) [2 copies]
I really could use that.

> "DKC8-A Engineering Drawings" (B-DD-DKC8-A) [ or, perhaps, MP-0DKC8-A0]
Already got that.

> Randomly titled DF-32 docs (D-BS-DF-32-0-0) [ for -8 and -8/S]
I could maybe use that.

> And now... the good stuff...

> "KK8-A Engineering Drawings" (B-DD-KK8-A-A) [about 50 pg]
Already got that.

> "TU56 DECtape transport engineering drawings" (A-ML-TU56-0-AP) [about 20 pg]
I will do whatever is necessary to convince you to give or trade me a copy of
that.

> "TD8-E DECtape control engineering drawings" (A-ML-TD8-E-B) [about 30 pg]
That would be good too. (If there's anyone out there with TC08 drawings, I'll
do whatever's necessary to get those, too.)

> I probably have a little more stuff than that, but I don't have ready access
> to it.

Well, that's my wish list....

--
Seth L. Blumberg, M.S.E.  \     The whole thing was an accident.  No saboteur
slb22@columbia.edu          \ could have been so wildly optimistic as to think
CUSFS President-in-Exile      \    he could destroy an airplane this way.
    > No one I know shares my opinions, least of all Columbia University. <


From slb22@columbia.edu  Ukn Jun 12 04:07:12 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA08542; Sun, 12 Jun 94 04:06:58 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA26326; Sun, 12 Jun 1994 04:10:29 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA25587
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 12 Jun 1994 04:10:27 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA27206
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 12 Jun 1994 04:10:25 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA15297; Sun, 12 Jun 94 03:48:40 EDT
Return-Path: <slb22@columbia.edu>
Received: from mailhub.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA15293; Sun, 12 Jun 94 03:48:37 EDT
Received: from konichiwa.cc.columbia.edu by mailhub.cc.columbia.edu with SMTP id AA26465
  (5.65c+CU/IDA-1.4.4/HLK for <pdp8-lovers@ai.mit.edu>); Sun, 12 Jun 1994 03:48:36 -0400
Message-Id: <199406120748.AA26465@mailhub.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Re: PDP-8 docs 
In-Reply-To: prp@ssd.intel.com 's message of "Fri, 10 Jun 1994 15:44:07 PDT."
             <9406102244.AA16293@SSD.intel.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 12 Jun 1994 03:48:36 -0400
From: Seth "the Lesser" <slb22@columbia.edu>
Status: RO
X-Status: 

prp@ssd.intel.com said:
> As I mentioned to Seth privately, I am also interested in 8/a docs. I have
> only a little and it seems pretty superficial.

I already posted this list privately to Bob Smith <rmsmith@csc.com>.  For
everyone else's benefit, here's what I have.

(Note that all of this comes from the PDP-8/a Miniprocessor Users Manual
[EK-8A002-MM-001], edition of Nov. 75; I have no ECOs or other documentation
past that point in time, and there are a number of typos and thinkos I'm aware
of, plus many more I probably haven't noticed.  The print sets seem clean,
though.)

General 8/a system description, including installation and acceptance test.
    45 pgs.
Omnibus interfacing.  Note that the 8/a Omnibus has a few gotchas not present
    in the 8/e, and the timing logic has changed to accommodate slow memories.
    39 pgs.
KK8-A CPU description (M8315, etch rev D, with diffs from rev C).  Includes
    the Programmer's Console logic, though this is actually on the DKC8-A I/O
    option board (M8316).  81 pgs.
Descriptions of all the memory systems for the 8/a: MR8-A, MS8-A, MR8-FB, and
    8K and 16K core (MM8-AA and -AB).
DKC8-A I/O option (multifunction board including SLU, PLU, crystal clock, and
    programmer's console interface logic).  29 pgs.
KM8-A memory extension (also includes power fail/auto restart and bootstrap
    logic).  42 pgs.
Power supplies (both semiconductor [with G8016 regulator] and core [with G8018
    regulator]).  20 pgs.
Maintenance and troubleshooting, spare parts list, module pictorials, and
    jumper and switch settings for all modules mentioned above.  33 pgs.

Print sets:
Drawing directory and ROM specs from the DKC8-A print set, but not the rest.
    6 pgs.
PDP-8/a unit assembly, backplane and power supply.  19 pgs.
KK8-A (M8315) CPU (etch rev D).  48 pgs.
MS8-A (M8311) semiconductor RAM.  6 pgs.
MR8-F (M8349) EPROM.  8 pgs.
MR8-A (M8312) ROM.  7 pgs.
MM8-AA (G649) 8K core base board.  11 pgs.
MM8-AB (G650) 16K core base board.  11 pgs.
(Sorry, no drawings of the H219[AB] core mats.)
KM8-A (M8317) memory ext/power fail/bootstrap.  38 pgs.

If any of this is useful, let me know.

OBTW: Why is one so strongly cautioned against running a TD8-E in an 8/a
system *unless* it uses core memory? Timing difficulties? That would mean
it could stand the 1.5us fixed cycle length of the 8/a, but not the
distortions that NTS STALL produces in a semiconductor machine.  Am I
right?

--
Seth L. Blumberg, M.S.E.  \     The whole thing was an accident.  No saboteur
slb22@columbia.edu          \ could have been so wildly optimistic as to think
CUSFS President-in-Exile      \    he could destroy an airplane this way.
    > No one I know shares my opinions, least of all Columbia University. <


From jones@pyrite.cs.uiowa.edu  Ukn Jun 12 18:55:18 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA16859; Sun, 12 Jun 94 18:55:01 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA01126; Sun, 12 Jun 1994 18:58:25 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA03139
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 12 Jun 1994 18:58:22 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA11373
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 12 Jun 1994 18:58:21 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA09934; Sun, 12 Jun 94 18:37:58 EDT
Return-Path: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA09930; Sun, 12 Jun 94 18:37:49 EDT
Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322)
	  on Sun, 12 Jun 1994 17:37:46 -0500 id RAA08393 with SMTP 
Received: by pyrite.cs.uiowa.edu (5.59/890218) 
	  on Sun, 12 Jun 94 17:37:24 CDT id AA04150
Date: Sun, 12 Jun 94 17:37:24 CDT
From: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Message-Id: <9406122237.AA04150@pyrite.cs.uiowa.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Permission to photocopy DEC documentation
Status: RO
X-Status: 


My letter of permission to copy DEC documentation is from

  Joe Cannava,
  Program Manager
  DEC
  PO BOX 9501
  Merrimack, New Hamshire  03054-9501

  (603)884-5111

The letter is dated July 27, 1992.  I got it by phoning Digital Direct,
and asking the operator to transfer my call to the person who can give
me permission to copy old DEC documentation.  Many transfers and holds
later, I was told to send a FAX to Jean Sullivan at DEC stating what I
wanted to copy and why.

In my letter, I was explicit that the reason for my copying was to help
preserve antique DEC hardware, and that I didn't intend to sell copies,
although trading them for stuff from other antiquarians was mentioned.
The letter of permission required that all copies include a DEC copyright
notice and a statement that the copies were reprinted by permission.
All in all, the requirements seem very fair, and the permission letter
they sent seems very generous.

BTW.  I have recently managed to get a complete PDP8-I maintenance
manual, volumes 1 and 2.  I recently got a photocopy of an 8/L manual,
volume I, and my 8/I stuff came with some key bits of volume 2 of the 8/L
docs (including the board maps for the CPU and for the expansion box),
but these are in a shambles, tattered and crumpled.  If anyone wants
to swap copies of the stuff I have for a good copy of 8/L volume II,
I'd be happy.
				Doug Jones
				jones@cs.uiowa.edu

PS: What's wrong with places like Kinkos?  In Iowa City, at least, all
the photocopy places are 4 or 5 cents a page, and an extra penny for
good paper.  Our in-house copy shops at the university are convenient,
but unless you have a long print run (over 20 copies) that can be
offset, they're not that much less expensive.


From cjl@maestro.com  Ukn Jun 12 23:16:47 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA19525; Sun, 12 Jun 94 23:16:37 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA03079; Sun, 12 Jun 1994 23:20:16 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10748
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 12 Jun 1994 23:20:14 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA23520
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 12 Jun 1994 23:20:11 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA19261; Sun, 12 Jun 94 23:05:52 EDT
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA19257; Sun, 12 Jun 94 23:05:44 EDT
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	(rama) id QQwubc11332; Sun, 12 Jun 1994 23:05:39 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA19221; Sun, 12 Jun 94 23:01:30 EDT
Date: Sun, 12 Jun 1994 22:06:17 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Sender: Charles Lasner <cjl@maestro.com>
Reply-To: Charles Lasner <cjl@maestro.com>
Subject: Re: PDP-8 docs 
To: Seth the Lesser <slb22@columbia.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <199406120748.AA26465@mailhub.cc.columbia.edu>
Message-Id: <Pine.3.07.9406121736.A15911-d100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Status: RO
X-Status: 



On Sun, 12 Jun 1994, Seth the Lesser wrote:

> Omnibus interfacing.  Note that the 8/a Omnibus has a few gotchas not present
>     in the 8/e, and the timing logic has changed to accommodate slow memories.
>     39 pgs.

Can you enumerate the differences?

> OBTW: Why is one so strongly cautioned against running a TD8-E in an 8/a
> system *unless* it uses core memory? Timing difficulties? That would mean
> it could stand the 1.5us fixed cycle length of the 8/a, but not the
> distortions that NTS STALL produces in a semiconductor machine.  Am I
> right?

I am unaware of anything in an 8/a per se that is a problem.  However, I
think this merely means that they want the KK8F (-8/e) CPU for speed. 
Certainly it at least means that the stalling MOS memory would slow things
down too much.

In essence, this is the worst-case timing consideration:

Using the dumb ROM code (my friend wrote it; I called it dumb to his
face!) is the slowest viable code anyone would think of running on it. 
This code is slower due to overhead of being in a ROM in another field
from where the RAM that the variables are stored in, etc., i.e.,
unavoidable overhead, but also compounded by the use of naive code for
checksum calculation.

In essence, the DECtape checksum is the EQU calculation of Equivalencing
all data with 77 taken six bits at a time.  The result is itself written
to the tape and EQU'd with the running checksum when read back.  The
result has to be 77 if the data was read correctly, etc.

But, it's not necessary to implement an EQU function, because the EQU is
merely the one's complement of the more-easily implemented XOR function. 
Furthermore, the entire operation is completely associative, thus you can
complement once at the end and not have to along the way each calculation.

While there certainly is enough space in the ROM, what's short as a
resource is time.  The ROM runs as slow memory as it is setting ROM STALL
L and has the cross-field overhead of periodic CDF instructions to both
the caller's data field and to the ROM's field(s).  (The code is in field
7, but the variables are in field 0.  The user's field is a calling
parameter and must be treated as an independent that generates still more
CDF instruction overhead.  In typical handlers for program transfer
devices, you set a CDF to the user's buffer field and the code runs
directly, being indirect only to access the user's buffer, but not so in
the ROM case, etc.)

To make matters worse, the ROM code doesn't optimize out the EQU <-> XOR
operations per word, thus each word transfer has that much more overhead.

The cumulative effect, coupled with running on a slower 8/a CPU, perhaps
coupled with stalling MOS memory produces a fatal result:  The worst-case
jittery window of time required to transfer a word exceeds the time
available.  The result is to read the tape in error, or write unreadable
junk, or worse, partially deformat the tape.

Thus, reliable operation of the TD8E must be enhanced in as many ways as
are available:

1)	Use a faster CPU (KK8F)

2)	Don't use stalling MOS memories

3)	Don't run from a ROM.  Putting an image of the ROM into field 7 of
RAM could run faster enough than an actual ROM that it could work!

4)	Don't run the ROM code with its cross-field overhead

5)	Don't run the ROM code with its poor design that doesn't recognize
the mathematical equivalents of XOR and EQU done either during or after
the fact, etc.  BTW, DEC distributed an "offical subroutine" to call the
TD8E.  It also uses the poor code, but likely wouldn't be in a ROM at least!

6)	Perhaps use a KG8E to make the checksum calculation.  Note that no
DEC program ever did this, but the hardware does support 12-bit XOR which
can be used to create the required 6-bit EQU in far less cycles.

All TD8E timing problems are compunded by the condition of the heads and
guides.  Friction will tend to make the tape get "sticky" causing erratic
jitter as the tape releases after getting caught, etc.

Thus, unless you can guarantee that all necessary operations are completed
within the nominal 133 microseconds, you can overrun the tape and even
write where you ought not to, causing a deformatting, etc.  And this 133
microseconds could be quite a bit shorter if tape guide friction enters
into the picture, etc.

Towards the end of helping out the timing (assuming no KG8E hardware,
still by far the best way to solve the problem!) I have made some changes
to the way the tape is handled.  The P?S/8 TD8E system handler uses these
techniques to make the handler more robust against tape jitter disaster,
etc.  (And most of the techniques could be applied to the OS/8 equivalents.)

Additionally, I have commented on in the past about the infamous "non-ECO"
meaning a fix  to the board I was a party to, that corrects a mistake DEC
overlooked.  It only affects users of the system handler for OS/8, but any
TD8E code is entitled to expect the hardware to work as advertised! 
Copies of this document are available in the archives.

cjl


From jones@pyrite.cs.uiowa.edu  Ukn Jun 13 15:20:50 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA03949; Mon, 13 Jun 94 15:20:40 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA00136; Mon, 13 Jun 1994 15:24:09 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10126
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Mon, 13 Jun 1994 15:24:05 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA16915
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Mon, 13 Jun 1994 15:24:02 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA21363; Mon, 13 Jun 94 15:03:44 EDT
Return-Path: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA21353; Mon, 13 Jun 94 15:03:36 EDT
Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322)
	  on Mon, 13 Jun 1994 14:03:30 -0500 id OAA18935 with SMTP 
Received: by pyrite.cs.uiowa.edu (5.59/890218) 
	  on Mon, 13 Jun 94 14:03:08 CDT id AA04951
Date: Mon, 13 Jun 94 14:03:08 CDT
From: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Message-Id: <9406131903.AA04951@pyrite.cs.uiowa.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Convincing DEC that they made the PDP-5
Status: RO
X-Status: 

prp@ssd.intel.com wrote:
> I would recommend to anyone attempting this to write a very clear
> letter, and probably enclose a copy of Doug's letter from Joe
> Cannava. It will be necessary to explain that DEC really did make
> this stuff and that it really is no problem to make copies of the
> docs because its so old. Joe's letter might be sufficient precedent.

It's sad and a bit funny that we now have a problem convincing the
folks at DEC that they once made such machines as the PDP-5!  Perhaps,
in dealing with DEC, we should also include a copy of a short history
of DEC, perhaps the one from the alt.sys.pdp-8 faq or better yet, a
short summary page from Computer Engineering, a Digital Perspective
(is there a good one-page quote from that book that would do the job?)

Another alternative would be to include a photocopy of a full-page ad
for the machine in question.  The original ads for the PDP-5, for
example, are beauties!  Look in a good university library for Computers
and Automation, Feb. 1964 page 9 or May 1964 page 27.  "Now, you can
own a complete digital computer for what a core memory used to cost".
If someone has time, we ought to get good scans of these ads into the
archive -- but who's to give copyright permission for them?

Anyway, if anyone wants copies of the letter of permission DEC sent me,
send a postal address and I'll mail a photocopy.  I won't fax it to
you!  Faxing faxes degrades things too quickly, and if you've got to
fax a copy of the thing to DEC, let's not add insult to injury.

					Doug Jones
					jones@cs.uiowa.edu


From aad@lovecraft.amd.com  Ukn Jun 14 15:20:18 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA27864; Tue, 14 Jun 94 15:20:06 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA11458; Tue, 14 Jun 1994 15:23:32 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA21358
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 14 Jun 1994 15:23:26 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA18142
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 14 Jun 1994 15:23:23 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA15842; Tue, 14 Jun 94 15:02:22 EDT
Return-Path: <Anthony.Datri@amd.com>
Received: from amdext.amd.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA15837; Tue, 14 Jun 94 15:02:20 EDT
Received: from amdint.amd.com by amdext.amd.com with SMTP id AA18738
  (5.67a/IDA-1.5+AMD for <pdp8-lovers@ai.mit.edu>); Tue, 14 Jun 1994 12:02:13 -0700
Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA02513
  (5.67a/IDA-1.5+AMD for <pdp8-lovers@ai.mit.edu>); Tue, 14 Jun 1994 12:02:12 -0700
Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18)
	id AA03902; Tue, 14 Jun 94 13:56:42 CDT
Received: by lovecraft.amd.com (4.1/AMDC-1.20)
	id AA18258; Tue, 14 Jun 94 14:02:10 CDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41
          via MS.5.6.lovecraft.amd.com.sun4_41;
          Tue, 14 Jun 1994 14:02:10 -0500 (CDT)
Message-Id: <whzTumOXhG4B96gOAE@lovecraft.amd.com>
Date: Tue, 14 Jun 1994 14:02:10 -0500 (CDT)
From: Anthony D'atri <aad@lovecraft.amd.com>
To: pdp8-lovers@ai.mit.edu
Subject: Re: Convincing DEC that they made the PDP-5
In-Reply-To: <9406131903.AA04951@pyrite.cs.uiowa.edu>
References: <9406131903.AA04951@pyrite.cs.uiowa.edu>
Status: RO
X-Status: 

>It's sad and a bit funny that we now have a problem convincing the
>folks at DEC that they once made such machines as the PDP-5!  

Or the GIGI.


From emcguire@bucky.i2.com  Ukn Jun 14 16:43:45 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA29726; Tue, 14 Jun 94 16:43:17 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA28405; Tue, 14 Jun 1994 16:46:31 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27197
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 14 Jun 1994 16:46:18 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA28370
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 14 Jun 1994 16:46:12 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA20969; Tue, 14 Jun 94 16:27:23 EDT
Return-Path: <uucp@uu.psi.com>
Received: from uu.psi.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA20965; Tue, 14 Jun 94 16:27:22 EDT
Received: from fuller.UUCP by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP;
        id AA25499 for ; Tue, 14 Jun 94 16:08:37 -0400
Received: from bucky.intellection.com by fuller.i2.COM (4.1/SMI-4.1)
	id AA19676; Tue, 14 Jun 94 14:42:14 CDT
Received: by bucky.intellection.com (4.1/SMI-4.1)
	id AA10206; Tue, 14 Jun 94 14:42:14 CDT
From: emcguire@bucky.i2.com
Message-Id: <9406141942.AA10206@bucky.intellection.com>
Subject: Re: Convincing DEC that they made the PDP-5
To: aad@lovecraft.amd.com (Anthony D'atri)
Date: Tue, 14 Jun 1994 14:42:14 -0500 (CDT)
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <whzTumOXhG4B96gOAE@lovecraft.amd.com> from "Anthony D'atri" at Jun 14, 94 02:02:10 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 248       
Status: RO
X-Status: 

> 
> >It's sad and a bit funny that we now have a problem convincing the
> >folks at DEC that they once made such machines as the PDP-5!  
> 
> Or the GIGI.
> 

*laugh*  No, that's just funny.  If I were Digital, I would disclaim
the GIGI too!

Ed


From rmsmith@csc.com  Ukn Jun 14 17:28:02 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA00704; Tue, 14 Jun 94 17:27:57 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA09814; Tue, 14 Jun 1994 17:31:35 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA29988
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 14 Jun 1994 17:31:31 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA03854
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 14 Jun 1994 17:31:25 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA22939; Tue, 14 Jun 94 17:07:39 EDT
Return-Path: <rmsmith@csc.com>
Received: from csc.com (explorer.csc.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA22928; Tue, 14 Jun 94 17:07:27 EDT
Received: by csc.com (Smail3.1.28.1 #11)
	id m0qDfhp-0009suC; Tue, 14 Jun 94 17:07 EDT
Message-Id: <m0qDfhp-0009suC@csc.com>
From: rmsmith@csc.com (Robert Smith)
Subject: gigi followup
To: pdp8-lovers@ai.mit.edu (pdp8 lovers)
Date: Tue, 14 Jun 1994 17:07:37 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 535       
Status: RO
X-Status: 


In previous posts:
> 
> >It's sad and a bit funny that we now have a problem convincing the
> >folks at DEC that they once made such machines as the PDP-5!  
> 
> Or the GIGI.
> 

*laugh*  No, that's just funny.  If I were Digital, I would disclaim
the GIGI too!

Ed
Now, some folks remember Rick Merrill as the father of FOCAL.
Some remember his involvement with GiGi.

I remember the time his directory got filled with large characters that
he could not delete.

Does anyone remember the VT52 messaging system called finger???
bob


From cjl@maestro.com  Ukn Jun 14 17:40:59 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA00927; Tue, 14 Jun 94 17:40:42 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA12850; Tue, 14 Jun 1994 17:44:03 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA00976
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 14 Jun 1994 17:43:41 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA05288
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 14 Jun 1994 17:43:36 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA23974; Tue, 14 Jun 94 17:19:23 EDT
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA23968; Tue, 14 Jun 94 17:19:13 EDT
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	(rama) id QQwuhp17141; Tue, 14 Jun 1994 17:18:52 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA00449; Tue, 14 Jun 94 17:14:56 EDT
Date: Tue, 14 Jun 1994 17:12:40 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: Convincing DEC that they made the PDP-5
To: emcguire@bucky.i2.com
Cc: "Anthony D'atri" <aad@lovecraft.amd.com>, pdp8-lovers@ai.mit.edu
In-Reply-To: <9406141942.AA10206@bucky.intellection.com>
Message-Id: <Pine.3.07.9406141738.A29334-a100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Tue, 14 Jun 1994 emcguire@bucky.i2.com wrote:

> > 
> > >It's sad and a bit funny that we now have a problem convincing the
> > >folks at DEC that they once made such machines as the PDP-5!  
> > 
> > Or the GIGI.
> > 
> 
> *laugh*  No, that's just funny.  If I were Digital, I would disclaim
> the GIGI too!
> 
> Ed

Maybe we should start alt.sys.vk100 or vk100-lovers@ai.mit.edu

cjl (Wasn't Maurice Chevalier part of GIGI?)

ps: I thought the VK-100 was an outputting display terminal, so wouldn't
it better be labeled the GOGO if not the GIGO?


From slb22@columbia.edu  Ukn Jun 15 01:32:58 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA09384; Wed, 15 Jun 94 01:32:50 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA13794; Wed, 15 Jun 1994 01:36:22 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA20776
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Wed, 15 Jun 1994 01:36:15 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA09121
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Wed, 15 Jun 1994 01:36:14 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA17593; Wed, 15 Jun 94 01:21:05 EDT
Return-Path: <slb22@columbia.edu>
Received: from mailhub.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA17588; Wed, 15 Jun 94 01:21:03 EDT
Received: from ciao.cc.columbia.edu by mailhub.cc.columbia.edu with SMTP id AA08365
  (5.65c+CU/IDA-1.4.4/HLK for <pdp8-lovers@ai.mit.edu>); Wed, 15 Jun 1994 01:20:54 -0400
Message-Id: <199406150520.AA08365@mailhub.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Re: PDP-8 docs 
In-Reply-To: Charles Lasner <cjl@maestro.com> 's message of "Sun, 12 Jun 1994 22:06:17 EDT."
             <Pine.3.07.9406121736.A15911-d100000@maestro.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 15 Jun 1994 01:20:53 -0400
From: Seth "the Lesser" <slb22@columbia.edu>
Status: RO
X-Status: 

Charles Lasner <cjl@maestro.com> said:
> [I said:]
> > Omnibus interfacing.  Note that the 8/a Omnibus has a few gotchas not
> > present in the 8/e, and the timing logic has changed to accommodate slow
> > memories.
> 
> Can you enumerate the differences?

I don't have my dox to hand at this moment, but I believe I was thinking only
of the following:
*  presence of NTS STALL L
*  unavailability of +/- 20V power in semiconductor machines
*  slot-dependent use of some officially unassigned bus lines for AC OK L and
   BATT EMPTY L in semiconductor machines
*  use of one officially unassigned line for address expansion on 48K or 64K
   core machines (requires third-party hardware for address generation, but DEC
   core memory boards decode the extra address line)

The lack of a +/-20V supply hoses the AD8-E (at least, I *think* that's why
you're not supposed to use an AD8-E in an 8/a system).  The other problems
affect any board that depends on the officially allocated "test point" bus
lines, some of which are used for the signals mentioned above.  I don't know
whether there are any such.

Also, of course, the timing changes.  (8/a has 1500ns bus cycles with no
distinction between "slow" and "fast" cycles, and semiconductor memory boards
may increase this time to as much as 3400ns using NTS STALL.)

Probably an overstatement to call any of these "gotchas".  My apologies.

--
Seth L. Blumberg, M.S.E.  \       ``Jesus said, `Love thy neighbor as thyself.'
slb22@columbia.edu          \      Right.  If I did that, they'd have me up on
CUSFS President-in-Exile      \    charges.''   -- Davo White <white@icad.com>
    > No one I know shares my opinions, least of all Columbia University. <


From cjl@maestro.com  Ukn Jun 16 12:31:04 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA04206; Thu, 16 Jun 94 12:30:24 EDT
Received: from watsun.cc.columbia.edu ([128.59.39.2]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA12202; Thu, 16 Jun 1994 12:33:29 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA21963
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 16 Jun 1994 12:33:12 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA09113
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 16 Jun 1994 12:33:01 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA10310; Thu, 16 Jun 94 12:06:52 EDT
Return-Path: <cjl@maestro.com>
Received: from relay1.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA10245; Thu, 16 Jun 94 12:04:43 EDT
Received: from maestro.Maestro.COM by relay1.UU.NET with SMTP 
	(rama) id QQwuoe29376; Thu, 16 Jun 1994 12:01:41 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA00789; Thu, 16 Jun 94 10:26:23 EDT
Date: Thu, 16 Jun 1994 10:20:55 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: gigi followup
To: Robert Smith <rmsmith@csc.com>
Cc: pdp8 lovers <pdp8-lovers@ai.mit.edu>
In-Reply-To: <m0qDfhp-0009suC@csc.com>
Message-Id: <Pine.3.07.9406161049.A709-a100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Tue, 14 Jun 1994, Robert Smith wrote:

> Ed
> Now, some folks remember Rick Merrill as the father of FOCAL.

And some people remember him as Rick Focal.

> 
> I remember the time his directory got filled with large characters that
> he could not delete.
> 
> Does anyone remember the VT52 messaging system called finger???

How about: [exact wording is a recreation]

Excuse me for interrupting your terminal session, but there seems to be
someone on the system who is annoying people by interrupting their
terminal session.  Do you know who this person is?

[He answers, regardless]

Thank You!  Do you know the name of any other people who might know
something about this?

[Takes responses and then victimizes them as well]

cjl (not a participant in above)


From cjl@maestro.com  Ukn Jun 16 13:51:29 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA05962; Thu, 16 Jun 94 13:51:15 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA06931; Thu, 16 Jun 1994 13:54:57 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27766
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 16 Jun 1994 13:54:43 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA18873
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 16 Jun 1994 13:54:35 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA15226; Thu, 16 Jun 94 13:30:20 EDT
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA15218; Thu, 16 Jun 94 13:30:12 EDT
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	(rama) id QQwuoj27138; Thu, 16 Jun 1994 13:29:57 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA05346; Thu, 16 Jun 94 13:26:06 EDT
Date: Thu, 16 Jun 1994 12:38:15 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: PDP-8 docs 
To: Seth the Lesser <slb22@columbia.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <199406150520.AA08365@mailhub.cc.columbia.edu>
Message-Id: <Pine.3.07.9406161213.A709-d100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Wed, 15 Jun 1994, Seth the Lesser wrote:

> Charles Lasner <cjl@maestro.com> said:
> > [I said:]
> > > Omnibus interfacing.  Note that the 8/a Omnibus has a few gotchas not
> > > present in the 8/e, and the timing logic has changed to accommodate slow
> > > memories.
> > 
> > Can you enumerate the differences?
> 
> I don't have my dox to hand at this moment, but I believe I was thinking only
> of the following:
> *  presence of NTS STALL L

That's not new at all:

There originally was the MR8F aka "PROM-8M" memory that could allow SW to
enter it at its lowest implemented address as a boot, and also it was
conventional memory, except that it's a ROM throughout (well sorta).  Each
ROM location is 13 bits where the high bit says that this is a RAM
reference, and the low-order bits point to which member of an auxiliary
RAM said location actually lies in.  Thus, if you were careful, you could
specify unrestricted -8 code to run in it, etc.  (Most code need not be in
a RAM.  I think this is 1K overall with 256 RAM words, more than adequate.)

Needless to say, this was a *slow* memory, and needed to set the stall
line.  But the problem was that there wasn't a stall line to set!

So, they changed the crystal on the timing generator so each cycle was
3.6 microseconds, good enough to avoid the problem.  (BTW, they set the
jumper that slows the timing so all cycles would be 1.4 were it the
standard crystal.  No use going any slower than you have to!)

Then, they invented the first generation of the stall line implementation
using a whole lot of hand add/deletes.

Years later. the -8/a stuff appeared that also needed the stall line, such
as the MR8A/MS8A.  The MS8A is a 1K-4K RAM memory that can be
custom-slowed as the chips need.  It always needs the stall support in the
best case, etc.  The MR8A is vaguely the same as the MR8F, except that it
implements a memory window into an MS8A connected to it by an over-the-top
connector, not the Omnibus (these are quad cards).  Thus, again,
mostly-ROM -8 code can be written, with the added quirk that the data also
appears in the RAM area under its own normal address, etc.  (I don't know
which scheme is slower; the stall is really needed though.)

It turns out that the newer spec on how to implement the stall works fine
on the -8/a CPU, but these newer memories won't work on the old 8/e cpu
even with the stall implementation.  Thus, they redefine how to do it,
using even more manual add/deletes, etc.

The changes are so bad, production balks at doing it.  The result was a
compromise that created an alternate card designation (forget the number;
once had one in my hands: M8347?) that is essentially the same ECO level as
the M8330, except that it's always one ECO level off relative to the same
level M8330.  For several generations of rev, they tracked each other,
always one ECO level different, as the newer stuff was applied to both.

But after that point, you could always get a card that did support the
-8/a-style of stall correctly for a KK8F CPU, etc.  (Eventually, they
created a new rev to eliminate the variants, apparently including an
in-house test version that adds another gate.  Apparently there was
M8330-YA and YB, one of these being the test card, and the other being the
obsolete notation replaced by its own M-number for the no-stall card, etc.)

In any case, viable memory stall is a feature of reasonably late
production -8/e cards.  However, there *is* a gotcha associated with it:

If you have an -8/a CPU, it's tempting to use the stall during an IOT, and
it will work.  However, if the -8/e CPU is used with core, the use with an
IOT will cause the memory contents of the location containing the IOT to
be destroyed and replaced with 7777!

> *  unavailability of +/- 20V power in semiconductor machines

Not a buss consideration as much as a configuration consideration.  Note
that the 8A-500 replaces the battery with a core capability, albeit only
12 slots total, etc.

> *  slot-dependent use of some officially unassigned bus lines for AC OK L and
>    BATT EMPTY L in semiconductor machines

Yes, don't hang private stuff on those lines.  This is what implements
skip on power low, skip on battery empty, and alloes MS8CB and the like to
remain contents-live in a brownout situation, etc.

> *  use of one officially unassigned line for address expansion on 48K or 64K
>    core machines (requires third-party hardware for address generation, but DEC
>    core memory boards decode the extra address line)
> 

Not sure what you talking about here?  Of course the official fifth foot
signals allow expansion DEC's way to 128K and CESI's way to 512K.

> The lack of a +/-20V supply hoses the AD8-E (at least, I *think* that's why
> you're not supposed to use an AD8-E in an 8/a system).  The other problems
> affect any board that depends on the officially allocated "test point" bus
> lines, some of which are used for the signals mentioned above.  I don't know
> whether there are any such.

Can't say anything about test points, but AD8E needs the external
well-regulated lab reference supply of +/- 15V, not the 20V which is what
8/a core needs.  The AD8A is more convenient because all the stuff is on
the card.  (One Omnibus card replaces the whole set of 2-4 cards from the
original set.)  However, there are a few problems:

1)	It's slower than the AD8E which hurts certain programs.

2)	Apparently there's an incompatibility bug where a customer's
program flatout fails unless you use AD8E.

3)	I believe there's an extra mode not available in the -8/e set that
has to be reckoned with:  In the AD8E you get either no multiplexor thus
one input, 8 inputs, or 16 inputs.  In the AD8A you get 16 inputs that are
almost compatible with the AD8E, except that while in the AD8E all inputs
are analog differential (you get one or two cards, each with 8
differential channels on it), in the AD8A there are 16 single-ended
inputs.  If you require the differential inputs, you have to set a new bit
that pairs them off thus reducing it to 8 channels with differential
input.  This is a new mode bit to set not present in the AD8E.  (If you
use 8 channels and the input might be differential, always set the bit and
it works either way.  If you need more than 8 channels, you lose if
differential is required, and anyway the bit must not be set, etc.)

4)	To hook the AD8A to the clock requires a special kludge cable
since the AD8E uses over-the-top connectors to connect to the clock for
that function.  Note that all of the lab peripherals interconnect, since
the reference supply voltage goes through there as well.  (Note: if you
have both VC8E and AD8E, the ref voltage connector *must* be the one on
the AD8E, not the VC8E else it screws up accuracy due to loading, etc.)

> 
> Also, of course, the timing changes.  (8/a has 1500ns bus cycles with no
> distinction between "slow" and "fast" cycles, and semiconductor memory boards
> may increase this time to as much as 3400ns using NTS STALL.)

Nothing new.  For debugging the KK8F, just set the jumper so all cycles
are 1400ns.  Or 3600ns for the original PROM-8M.  Running slow isn't a
problem.

> 
> Probably an overstatement to call any of these "gotchas".  My apologies.

No, a good list to ponder.  Just wanted to make sure there weren't and
hidden bad gotchas :-).

> 
> --
> Seth L. Blumberg, M.S.E.  \       ``Jesus said, `Love thy neighbor as thyself.'
> slb22@columbia.edu          \      Right.  If I did that, they'd have me up on
> CUSFS President-in-Exile      \    charges.''   -- Davo White <white@icad.com>
>     > No one I know shares my opinions, least of all Columbia University. <

cjl


From prp@ssd.intel.com  Ukn Jun 19 03:04:13 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA00160; Sun, 19 Jun 94 03:04:07 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA24989; Sun, 19 Jun 1994 03:07:42 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA26524
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 19 Jun 1994 03:07:26 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA26312
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 19 Jun 1994 03:07:24 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA19314; Mon, 13 Jun 94 14:21:36 EDT
Return-Path: <prp@ssd.intel.com>
Received: from SSD.intel.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA19310; Mon, 13 Jun 94 14:21:34 EDT
Received: from t.ssd.intel.com by SSD.intel.com (4.1/SMI-4.1)
	id AA21288; Mon, 13 Jun 94 11:21:19 PDT
Message-Id: <9406131821.AA21288@SSD.intel.com>
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu, prp@ssd.intel.com
Subject: Re: Permission to photocopy DEC documentation 
In-Reply-To: Your message of "Sun, 12 Jun 94 17:37:24 CDT."
             <9406122237.AA04150@pyrite.cs.uiowa.edu> 
Date: Mon, 13 Jun 94 11:21:17 -0700
From: prp@ssd.intel.com
Status: RO
X-Status: 

Doug,

When I called Joe Cannava had left DEC. I believe Jean Sullivan was still the
contact and you do need to FAX her a letter to get permission. I couldn't find
my materials this morning so I don't have any more info right now.

I would recommend to anyone attempting this to write a very clear letter, and
probably enclose a copy of Doug's letter from Joe Cannava. It will be
necessary to explain that DEC really did make this stuff and that it really is
no problem to make copies of the docs because its so old. Joe's letter might
be sufficient precedent. The DECUS article might also help, if someone can
find it. It would be really good if someone could get blanket permission for
all of us to copy docs that are a) older than <?> years old and/or b) no longer
available from DEC.

Who's going to sign up to do this?

BTW, there were still some interesting documents available a year or so ago,
such as the three volume PDP-8/e Maintenance Manual set. The price was just
low enough to make it not worth the hassle of copying. But most of the stuff
we want is no longer available.

Also, I don't have anything against Kinko's price. I find them most reasonable
(plus they can copy huge drawings.) But they are a high volume place, and for
my most precious docs I worry about originals getting caught in the autofeeder
and copies not turning out the best they could.

Paul


From cjl@maestro.com  Ukn Jun 19 13:08:25 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA05707; Sun, 19 Jun 94 13:08:15 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA24451; Sun, 19 Jun 1994 13:12:02 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA13250
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 19 Jun 1994 13:11:52 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA27273
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 19 Jun 1994 13:11:51 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA26522; Sun, 19 Jun 94 12:47:03 EDT
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA26510; Sun, 19 Jun 94 12:46:55 EDT
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	(rama) id QQwuzj05502; Sun, 19 Jun 1994 12:46:44 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA05179; Sun, 19 Jun 94 12:42:50 EDT
Date: Sun, 19 Jun 1994 12:26:25 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: Permission to photocopy DEC documentation 
To: prp@ssd.intel.com
Cc: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>, pdp8-lovers@ai.mit.edu,
        prp@ssd.intel.com
In-Reply-To: <9406131821.AA21288@SSD.intel.com>
Message-Id: <Pine.3.07.9406191223.A4952-c100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Mon, 13 Jun 1994 prp@ssd.intel.com wrote:

> Doug,
> 
> When I called Joe Cannava had left DEC. I believe Jean Sullivan was still the
> contact and you do need to FAX her a letter to get permission. I couldn't find
> my materials this morning so I don't have any more info right now.

Pardon my pessimism, but this has been part of a decades-long pattern with
DEC.  The people you can convince to do something useful disappear. 
Sometimes, it seems that they just promise you stuff to get rid of you
knowing that they can string you along just long enough that they know
they will be either gone, or transferred into some other too-irrelevant
part of the company :-(.  It's pretty hard to find someone willing to buck
in-house bureaucracy that can possibly hurt them, and clearly can't
benefit them in the process, even when this is all opposed to their sense
of doing the right thing, etc.

My personal position is that thanks to extraordinary effort, a precedent
has been set.  Let's just do whatever we want for non-commercial purposes
and wait for the extremely unlikely event that someone in DEC will
misunderstand our intentions, then possibly threaten us with some form of
negative consequences.  In that unlikely event, you then produce the
original permission letter and point out to them that whatever was bugging
them is a consequence of the permission letter.  DEC clearly doesn't have
a legal department attempting to collect compensation from people daring
to distribute materials it barely can find anyone left in the company to
ever vouch for the fact that they ever made it!

> 
> I would recommend to anyone attempting this to write a very clear letter, and
> probably enclose a copy of Doug's letter from Joe Cannava. It will be
> necessary to explain that DEC really did make this stuff and that it really is
> no problem to make copies of the docs because its so old. Joe's letter might
> be sufficient precedent. The DECUS article might also help, if someone can
> find it. It would be really good if someone could get blanket permission for
> all of us to copy docs that are a) older than <?> years old and/or b) no longer
> available from DEC.

Good luck.  Hopefully the precedent angle will have the proper clout. 
However, I would interpret the likely response as further proof of DEC's
abandonment of the material, totally in line with the precedent, etc.  I
would always emphasize that the stuff in question is obsolete, the company
made it decades before they became a multi-national corporation, that
there is no current product line or cost center concerned with any aspect
of it, etc., and you don't expect that they even have any copy of the
material available, and further, that the material wasn't sold in a form
that was expected to survive this long, and exists merely due to your own
TLC and extraordinary efforts.  Also, in effect ask them for a "grant" for
your efforts, i.e., if they are willing to cover the costs of your
reproduction, you willing to give them a copy of the stuff as well, but
that your first order of business is to preserve history for purely
academic, etc. purposes.


On a slightly different issue:

The original -8 schematics are based on a set of symbols that sometimes
takes a bit to get used to.  The later stuff is all TTL with standard
logic symbols.  What about the possibility of scanning the stuff into a
CAD program to effectively produce originals that can be run off with
high-quality plotters, and also gives us machine-readable files of the
data while we're at it?

cjl


From amon@elegabalus.cs.qub.ac.uk  Ukn Jun 19 18:49:09 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA09450; Sun, 19 Jun 94 18:47:55 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA05425; Sun, 19 Jun 1994 18:50:12 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA23227
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 19 Jun 1994 18:50:04 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA12479
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 19 Jun 1994 18:50:01 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA09514; Sun, 19 Jun 94 18:30:20 EDT
Return-Path: <amon@elegabalus.cs.qub.ac.uk>
Received: from  elegabalus.cs.qub.ac.uk  (elegabalus.CS.QUB.AC.UK) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA09507; Sun, 19 Jun 94 18:30:18 EDT
Received: from  trajan.nextlab.cs.qub.ac.uk (trajan) by  elegabalus.cs.qub.ac.uk  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA15496; Sun, 19 Jun 94 23:30:22 BST
Message-Id: <9406192230.AA15496@ elegabalus.cs.qub.ac.uk >
Received: by  trajan.nextlab.cs.qub.ac.uk  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0a)
	id AA06353; Sun, 19 Jun 94 23:30:19 BST
Date: Sun, 19 Jun 94 23:30:19 BST
From: amon@elegabalus.cs.qub.ac.uk
Received: by NeXT Mailer (1.63)
To: pdp8-lovers@ai.mit.edu
Subject: Other related lists or news groups
Status: RO
X-Status: 

I'm not a reader of this group (although I did start out on PDP-8's).  
I'm wondering if there are similar groups for PDP-11 and PDP-10's?

I have a stack of old DecTapes written on the old cmua PDP-10 running 

TOPS-10 and have no way to read them. I'm beginning to think that
there is not a single working Dectape drive on planet Earth...

If anyone knows an appropriate group, or someone who is capable of
reading these tapes, please get in touch directly -- I'm not a reader  
or subscriber.



--
=======================================================================
      Individual Liberty	     Dale M. Amon, The only libertarian
   Individual Responsibility	 	   in Northern Ireland
  R.Means, 1988 LP Convention    	    amon@cs.qub.ac.uk
=======================================================================


From bqt@minsk.docs.uu.se  Ukn Jun 19 19:01:03 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA09589; Sun, 19 Jun 94 19:00:38 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA07283; Sun, 19 Jun 1994 19:04:14 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA23697
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 19 Jun 1994 19:04:11 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA13206
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 19 Jun 1994 19:04:06 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA09612; Sun, 19 Jun 94 18:41:13 EDT
Return-Path: <bqt@minsk.docs.uu.se>
Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA09608; Sun, 19 Jun 94 18:41:10 EDT
Received: from Minsk.DoCS.UU.SE by sunic.sunet.se (8.6.8/2.03)
	id AAA06042; Mon, 20 Jun 1994 00:41:09 +0200
Received: by Minsk.DoCS.UU.SE (Sun-4/630, SunOS 4.1.2)
 with sendmail 5.61-bind 1.5+ida/ICU/DoCS id AA09627; Mon, 20 Jun 94 00:41:08 +0200
From: Johnny Billquist  <bqt@minsk.docs.uu.se>
Date: Mon, 20 Jun 94 0:41:06 MET DST
Reply-To: bqt@minsk.docs.uu.se
To: amon@elegabalus.cs.qub.ac.uk
Cc: pdp8-lovers@ai.mit.edu
Subject: Re: Other related lists or news groups
In-Reply-To: Your message of Sun, 19 Jun 94 23:30:19 BST
Message-Id: <CMM.0.90.0.772065666.bqt@Minsk.DoCS.UU.SE>
Status: RO
X-Status: 

>I'm not a reader of this group (although I did start out on PDP-8's).  
>I'm wondering if there are similar groups for PDP-11 and PDP-10's?

There are. You have info-pdp11@transarc.com for pdp11, and a tops20 as
well as an ITS mailinglist for pdp10 people.

>I have a stack of old DecTapes written on the old cmua PDP-10 running 
>TOPS-10 and have no way to read them. I'm beginning to think that
>there is not a single working Dectape drive on planet Earth...

Well, I guess we can make you more happy. While you might have
problems finding a TOPS-10 machine with DECtapes today, there are
at least a few pdp8's with DECtape still running, and you can read
TOPS-10 tapes from OS/8. I don't remember the name of the utility off
hand, but I'm sure someone will remind me. :-)
My pdp8 with DECtapes is unfortunately stuffed away at the moment, but
I *know* others reading this list who have DECtapes running.

>If anyone knows an appropriate group, or someone who is capable of
>reading these tapes, please get in touch directly -- I'm not a reader  
>or subscriber.

Well, this should get both to you and the pdp8-lovers list.

	Johnny

Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From ds@netcom.com  Ukn Jun 20 00:02:32 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA14400; Mon, 20 Jun 94 00:02:11 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA15460; Mon, 20 Jun 1994 00:05:38 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04009
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Mon, 20 Jun 1994 00:05:28 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA28442
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Mon, 20 Jun 1994 00:05:26 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA20773; Sun, 19 Jun 94 23:50:11 EDT
Return-Path: <ds@netcom.com>
Received: from netcom.com (netcom3.netcom.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA20769; Sun, 19 Jun 94 23:50:08 EDT
Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom)
	id UAA23517; Sun, 19 Jun 1994 20:34:56 -0700
Date: Sun, 19 Jun 1994 20:34:56 -0700
From: ds@netcom.com (David Schachter)
Message-Id: <199406200334.UAA23517@netcom3.netcom.com>
To: pdp8-lovers@ai.mit.edu
Subject: TU-56 engineering drawings
Status: RO
X-Status: 

On Saturday, June 11, Seth "the Lesser" <slb22@columnbia.edu> asked about the
availability of TU56 DECTape Transport Engineering Drawings.  I may have a set
at home, but I won't be back until late October at the earliest.  If the
drawings are still needed then, "ping" me and I'll take a look.  (I think I
have them because I had to do some tape drive debugging a few years ago and I
recall marvelling at how DEC had done so much with so little.)

                                        -- David Schachter


 ______________________________________-_____________________________________
 David Schachter                                      Internet: ds@netcom.com
 801 Middlefield Road, #8                              CompuServe: 70714,3017
 Palo Alto, CA  94301-2916                After 10 am, voice: +1 415 328 7425
 USA                                                     fax: +1 415 328 7154


From cjl@maestro.com  Ukn Jun 20 04:53:31 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA16783; Mon, 20 Jun 94 04:53:27 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA26546; Mon, 20 Jun 1994 04:57:16 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14741
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Mon, 20 Jun 1994 04:56:56 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA12711
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Mon, 20 Jun 1994 04:56:46 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA26506; Mon, 20 Jun 94 04:38:48 EDT
Return-Path: <cjl@maestro.com>
Received: from relay1.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA26502; Mon, 20 Jun 94 04:38:40 EDT
Received: from maestro.Maestro.COM by relay1.UU.NET with SMTP 
	(rama) id QQwvbu27991; Mon, 20 Jun 1994 04:38:37 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA16695; Mon, 20 Jun 94 04:34:43 EDT
Date: Mon, 20 Jun 1994 04:33:58 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: Other related lists or news groups
To: amon@elegabalus.cs.qub.ac.uk
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9406192230.AA15496@ elegabalus.cs.qub.ac.uk >
Message-Id: <Pine.3.07.9406200457.A16691-a100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Sun, 19 Jun 1994 amon@elegabalus.cs.qub.ac.uk wrote:

> I have a stack of old DecTapes written on the old cmua PDP-10 running 
> 
> TOPS-10 and have no way to read them. I'm beginning to think that
> there is not a single working Dectape drive on planet Earth...
> 
> If anyone knows an appropriate group, or someone who is capable of
> reading these tapes, please get in touch directly -- I'm not a reader  
> or subscriber.

This is the group for multiple people who can read DECtapes.  I for one, etc.

cjl


From prp@SSD.intel.com  Ukn Jun 20 13:57:27 1994
Received: from SSD.intel.com 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA25452; Mon, 20 Jun 94 13:57:18 EDT
Received: from t.ssd.intel.com by SSD.intel.com (4.1/SMI-4.1)
	id AA09168; Mon, 20 Jun 94 11:00:56 PDT
Message-Id: <9406201800.AA09168@SSD.intel.com>
To: Charles Lasner <cjl@maestro.com>
Cc: prp@SSD.intel.com, pdp8-lovers@ai.mit.edu
Subject: Re: Permission to photocopy DEC documentation 
In-Reply-To: Your message of "Sun, 19 Jun 94 12:26:25 EDT."
             <Pine.3.07.9406191223.A4952-c100000@maestro.com> 
Date: Mon, 20 Jun 94 11:00:52 -0700
From: prp@SSD.intel.com
Status: RO
X-Status: 


> From: Charles Lasner <cjl@maestro.com>
> Subject: Re: Permission to photocopy DEC documentation 
> To: prp@SSD.intel.com

> On a slightly different issue:
> 
> The original -8 schematics are based on a set of symbols that sometimes
> takes a bit to get used to.  The later stuff is all TTL with standard
> logic symbols.  What about the possibility of scanning the stuff into a
> CAD program to effectively produce originals that can be run off with
> high-quality plotters, and also gives us machine-readable files of the
> data while we're at it?
> 
> cjl


I have already scanned in the whole PDP-5 maintenance manual, which is
currently in .PCX compressed into .ZIP files. Its not too bad, considering how
big disks are these days. I would like eventually to do the same with the
PDP-8 maintenance manual and one or more of the little handbooks. In
particular, I have extra copies of the 1968 Small Computer Handbook (with the
"new" PDP-8/I) and the OS/8 handbook that can be taken apart and scanned.

Someone recently made the PDP-1 manual available in Postscript, that was nice.

The tricky part cjl gets at is the fact that the drawings are larger than
8.5x11 so its hard to scan them and then produce a single full-size copy. For
the PDP-5 MM, I scanned them in pieces and (for the smaller ones) stitched
them back together with some special software. I found that most of the 2-page
drawings were perfectly legible when reduced some, so I made them fit on a
single page by reducing and rotating. For the large drawings, I made copies on
the big machine at Kinko's. I have the scans but haven't done anything about
stitching them together.

Many large paper plotters these days are raster scan devices (even though they
take pen-plotter input data) and it seems like it should be possible to print
scanned documents on them, maybe from Postscript. Does anyone know?

I have PC software that automates much of the work, although its still buggy
and not well documented. Its my hope that eventually I will make a more
finished version that makes it fairly easy to produce an electronic "book"
version from raw scans. There may be commercial software to do this, the big
question would be how it handles large pages.

Converting scans to CAD compatible schematics would be a much bigger effort. I
don't know if its a reasonable thing to ask for, but it would be fun -
especially for accurate working reproductions of old machines in new logic
technologies.

Paul


From jones@pyrite.cs.uiowa.edu  Ukn Jun 20 15:05:54 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA26956; Mon, 20 Jun 94 15:05:32 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA07484; Mon, 20 Jun 1994 15:07:07 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA13409
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Mon, 20 Jun 1994 15:06:59 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA16002
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Mon, 20 Jun 1994 15:06:53 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA23712; Mon, 20 Jun 94 14:47:49 EDT
Return-Path: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA23705; Mon, 20 Jun 94 14:47:45 EDT
Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322)
	  on Mon, 20 Jun 1994 13:47:39 -0500 id NAA01052 with SMTP 
Received: by pyrite.cs.uiowa.edu (5.59/890218) 
	  on Mon, 20 Jun 94 13:47:15 CDT id AA10980
Date: Mon, 20 Jun 94 13:47:15 CDT
From: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Message-Id: <9406201847.AA10980@pyrite.cs.uiowa.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Classic-8 Pocket Reference Card
Status: RO
X-Status: 

C. D Lowenstein of UCSD has just sent me a vintage
PDP-8 Pocket Reference Card.

The original was 5 1/2 inches tall by 3 1/2 inches wide
on stiff white cardstock printed in light green ink.  I
have taken liberties in my attempt to approximate the
typography of the original.  Most of it is set in a
small sans-serif font (Helvetica?) with bold titles for
each instruction group in the same font, and bigger
fonts used only for the title on the front page and the
corporate logo on the back page.  The PDP-8 "Trademark"
used here had PDP written in an extended bold typewriter
like font over a very extended large numeral 8; this
same form was used in a corner of every page of every
software listing published by DEC in 1965, but it wasn't
used on any of the original hardware manuals that I've
got.

The card is appended to this message (after a formfeed);
I proofred what I transcribed, and I was careful to
include all typos DEC included in the original.  The
worst are in the COMBINED OPERATE MICROINSTRUCTIONS
section for SMA SZA, SPA SZL and SPA CLA; in all these,
it skips if AC=0, but the comments don't say so!

He also sent the 4/67 edition of the card.  This fixes
the typos, includes the new higher performance figures
for the upgraded EAE, and includes the PC02, PC03, and
TU55/TC01 instead of the Type 750C, 75E and 555/552
listed in the earlier documentation.  In addition, it
includes another 2-sided page showing the bit assignments
for the different instruction formats.

Under the conditions of DEC's letter of permission to
reproduce documentation, I should say that this is
reproduced with permission in 1994 and that DEC holds
whatever copyright applies to this material.

                                Doug Jones
                                jones@cs.uiowa.edu




                                                   F-86
                                                   5/65




      P D P
      88888
     8     8
      88888    I N S T R U C T I O N   L I S T
     8     8
      88888







Mnemonic Code          Operation                 Cycles

                   BASIC INSTRUCTIONS

AND      0000  logical AND                           2
TAD      1000  2's complement add                    2
ISZ      2000  increment and skip if zero            2
DCA      3000  deposic and clear AC                  2
JMS      4000  jump to subroutine                    2
JMP      5000  jump                                  1
IOT      6000  in-out transfer                   2 1/2
OPR      7000  operate                               1


      GROUP 1 OPERATE MICROINSTRUCTIONS (1 CYCLE)

                                             Event Time
NOP      7000  no operation                          1
CLA      7200  clear AC                              1
CLL      7100  clear link                            1
CMA      7040  complement AC                         1
CML      7020  complement link                       1
RAR      7010  rotate AC and link right one          2
RAL      7004  rotate AC and link left one           2
RTR      7012  rotate AC and link right two          2
RTL      7006  rotate AC and link left two           2
IAC      7001  increment AC                          2


      GROUP 2 OPERATE MICROINSTRUCTIONS (1 CYCLE)

                                             Event Time
SMA      7500  skip on minus AC                      1
SZA      7440  skip on zero AC                       1
SPA      7510  skip on plus AC                       1
SNA      7450  skip on non zero AC                   1
SNL      7420  skip on non-zero link                 1
SZL      7430  skip on zero link                     1
SKP      7410  skip unconditionally                  1
OSR      7404  inclusive OR, switch register with AC 2
HLT      7402  halts the program                     1
CLA      7600  clear AC                              1



Mnemonic Code          Operation                 Cycles

           COMBINED OPERATE MICROINSTRUCTIONS

CIA      7041  complement and increment AC           1
LAS      7604  load AC with switch register          1
STL      7120  set link (to 1)                       1
GLK      7204  get link (and put int AC bit 11)      1
CLA CLL  7300  clear AC and link                     1
CLA IAC  7201  set AC = 1                            1
CLA CMA  7240  set AC = -1                           1
CLL RAR  7110  shift positive number one right       1
CLL RAL  7104  shift positive number one left        1
CLL RTL  7106  clear link, rotate 2 left             1
CLL RTR  7112  clear link, rotate 2 right            1
SZA CLA  7640  skip if AC = 0, then clear AC         1
SZA SNL  7460  skip if AC = 0, or link is 1, or both 1
SNA CLA  7650  skip if AC /= 0, then clear AC        1
SMA CLA  7700  skip if AC < 0, then clear AC         1
SMA SZA  7540  skip if AC <= 0                       1
SMA SNL  7520  skip if AC < 0 or line is 1 or both   1
SPA SNA  7550  skip if AC > 0                        1
SPA SZL  7530  skip if AC > 0 and if the link is 0   1
SPA CLA  7710  skip of AC > 0, then clear AC         1
SNA SZL  7470  skip if AC /= 0 and link = 0          1


Mnemonic Code          Operation          Time ( usec.)

             EAE MICROINSTRUCTION TYPE 182
DVI      7407  divide                         <36.7
NMI      7411  normalize                      3.0+0.5n
SHL      7413  shift left                     3.0+0.5n
ASR      7415  arithmetic shift right         3.0+0.5n
LSR      7417  logical shift right            3.0+0.5n
MQL      7421  load AC into MQ, clear AC      1.5
MUY      7405  multiply                       15.0-21.2
MQA      7501  inclusive OR, MA with AC       1.5
CAM      7621  clear AC and MQ                1.5
SCA      7441  read SC into AC                1.5
MQA      7501  read MQ into AC                1.5


Mnemonic Code          Operation                 Cycles

                 IOT MICROINSTRUCTIONS

                   PROGRAM INTERRUPT
ION      6001  turn interrupt on                     1
IOF      6002  turn interrupt off                    1

          ANALOG TO DIGITAL CONVERTER TYPE 189
ADC      6004  convert A to D

                TELETYPE KEYBOARD/READER
KSF      6031  skip if keyboard/reader flag=1     2 1/2
KCC      6032  clear AC and keyboard/reader       2 1/2
               flag
KRS      6034  read keyboard/reader buffer,       2 1/2
               static
KRB      6036  clear AC, read keyboard buffer     2 1/2
               clear keyboard flag



Mnemonic Code          Operation                 Cycles

               TELETYPE TELEPRINTER/PUNCH
TSF      6041  skip if teleprinter/punch          2 1/2
               flag = 1
TCF      6042  clear teleprinter/punch flag       2 1/2
TPC      6044  load teleprinter/punch             2 1/2
               buffer, select and print
TLS      6046  load teleprinter/punch buffer,     2 1/2
               select and print, and clear
               teleprinter/punch flag

      HIGH SPEED PERFORATED TAPE READER TYPE 750C
RSF      6011  skip if reader flag = 1            2 1/2
RRB      6012  read reader buffer,                2 1/2
               and clear flag
RFC      6014  clear flag and buffer and          2 1/2
               fetch character

       HIGH SPEED PERFORATED TAPE PUNCH TYPE 75E
PSF      6021  skip if punch flag = 1             2 1/2
PCF      6022  clear flag and buffer              2 1/2
PPC      6024  load buffer and punch              2 1/2
               character
PLS      6026  clear flag and buffer;             2 1/2
               load and punch

             OSCILLOSCOPE DISPLAY TYPE 34B
DXL      6053  clear and load x buffer            2 1/2
DYL      6063  clear and load y buffer            2 1/2
DXS      6057  combined dxl and dix               2 1/2
DYS      6067  combined dyl and diy               2 1/2
DIY      6064  intensify point                    2 1/2
DIX      6054  intensify point                    2 1/2
DCY      6061  clear y buffer                     2 1/2
DCX      6051  clear x buffer                     2 1/2

            DECTAPE AND CONTROL TYPE 555/552
MMLS     6751  load unit select register          2 1/2
               and clear DECtape flag
MMLM     6752  load motion register and           2 1/2
               clear DECtape flag
MMLF     6754  load function register             2 1/2
MMMF     6756  load motion and function           2 1/2
               registers and clear DECtape flag
MMMM     6757  load unit select motion and        2 1/2
               function registers and clear
               DECtape flag
MMSF     6761  skip if DECtape flag = 1           2 1/2
MMML     6766  clear and load memory              2 1/2
               address register
MMSC     6771  skip if error flag = 1             2 1/2
MMCF     6772  clear error flag and               2 1/2
               DECtape flag
MMRS     6774  read status bits into AC bits 0-7  2 1/2

                EXTENDED MEMORY TYPE 183
CDF      62n1  change to data field n                1
CIF      62n2  change to instruction field n         1
RDF      6214  read data field into AC 6-8           1
RIF      6224  read instruction field into AC 6-8    1
RMF      6244  restore memory field                  1
RIB      6234  read interrupt buffer                 1





                       ASCII CODE

    Character      Code        Character     Code
    ---------      ----        ---------     ---
        A          301             !         241
        B          302             "         242
        C          303             #         243
        D          304             $         244
        E          305             %         245
        F          306             &         246
        G          307             '         247
        H          310             (         250
        I          311             )         251
        J          312             *         252
        K          313             +         253
        L          314             ,         254
        M          315             -         255
        N          316             .         256
        O          317             /         257
        P          320             :         272
        Q          321             ;         273
        R          322             <         274
        S          323             =         275
        T          324             >         276
        U          325             ?         277
        V          326             @         300
        W          327             [         333
        X          330             \         334
        Y          331             ]         335
        Z          332             ^         336
        0          260             <-        337
        1          261             EOT       204
        2          262             W RU      205
        3          263             RU        206
        4          264             BELL      207
        5          265             Line Feed 212
        6          266             Return    215
        7          267             Space     240
        8          270             ALT MODE  375
        9          271             Rub Out   377



               ___ ___ ___ ___ ___ ___ ___
              |   |   |   |   |   |   |   |
              |   |   |   |   |   |   |   |
              | d | i | g | i | t | a | l |
              |   |   |   |   |   |   |   |
              |___|___|___|___|___|___|___|

                E  Q  U  I  P  M  E  N  T

                  C O R P O R A T I O N

                 MAYNARD,  MASSACHUSETTS




5732               PRINTED IN U.S.A.            25-5/65


From aad@lovecraft.amd.com  Ukn Jun 20 15:27:09 1994
Received: from amdext.amd.com 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA27561; Mon, 20 Jun 94 15:27:05 EDT
Received: from amdint.amd.com by amdext.amd.com with SMTP id AA00687
  (5.67a/IDA-1.5+AMD for <cjl@maestro.com>); Mon, 20 Jun 1994 12:30:45 -0700
Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA24465
  (5.67a/IDA-1.5+AMD); Mon, 20 Jun 1994 12:30:43 -0700
Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18)
	id AA00937; Mon, 20 Jun 94 14:24:41 CDT
Received: by lovecraft.amd.com (4.1/AMDC-1.20)
	id AA02989; Mon, 20 Jun 94 14:30:40 CDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41
          via MS.5.6.lovecraft.amd.com.sun4_41;
          Mon, 20 Jun 1994 14:30:39 -0500 (CDT)
Message-Id: <Ei1StTmXhG4B46_VIf@lovecraft.amd.com>
Date: Mon, 20 Jun 1994 14:30:39 -0500 (CDT)
From: Anthony D'atri <aad@lovecraft.amd.com>
To: Charles Lasner <cjl@maestro.com>
Subject: Re: Permission to photocopy DEC documentation
Cc: prp@ssd.intel.com, pdp8-lovers@ai.mit.edu
In-Reply-To: <9406201800.AA09168@SSD.intel.com>
References: <9406201800.AA09168@SSD.intel.com>
Status: RO
X-Status: 

>Many large paper plotters these days are raster scan devices (even though they
>take pen-plotter input data) and it seems like it should be possible to print
>scanned documents on them, maybe from Postscript. Does anyone know?

I've done PostScript to monochrome Versatec plotters.  Their format is
pretty simple -- I just used Ghostscript to render into a PBM file, with
the dpi appropriately fudged to make it fill the width, then hand-edited
the header.  Worked like a charm.  Their color plotters are far more
weird, though.


From amon@elegabalus.cs.qub.ac.uk  Ukn Jun 21 18:38:26 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA24278; Tue, 21 Jun 94 18:37:46 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA24931; Tue, 21 Jun 1994 18:35:35 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA06263
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 21 Jun 1994 18:35:18 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA19788
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 21 Jun 1994 18:35:13 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA03897; Tue, 21 Jun 94 18:15:14 EDT
Return-Path: <amon@elegabalus.cs.qub.ac.uk>
Received: from  elegabalus.cs.qub.ac.uk  (elegabalus.CS.QUB.AC.UK) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA03876; Tue, 21 Jun 94 18:15:03 EDT
Received: from  trajan.nextlab.cs.qub.ac.uk (trajan) by  elegabalus.cs.qub.ac.uk  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA18651; Tue, 21 Jun 94 23:15:09 BST
Message-Id: <9406212215.AA18651@ elegabalus.cs.qub.ac.uk >
Received: by  trajan.nextlab.cs.qub.ac.uk  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0a)
	id AA08068; Tue, 21 Jun 94 23:15:07 BST
Date: Tue, 21 Jun 94 23:15:07 BST
From: amon@elegabalus.cs.qub.ac.uk
Received: by NeXT Mailer (1.63)
To: pdp8-lovers@ai.mit.edu
Subject: Other related lists or news groups
Status: RO
X-Status: 

Thanks much. Several people responded, which was quite a surprise
considering that I've been trying for 10 years to find someone who
could read these things.

I'll be back in touch as soon as I can afford to ship them to  
someone.

--
=======================================================================
      Individual Liberty	     Dale M. Amon, The only libertarian
   Individual Responsibility	 	   in Northern Ireland
  R.Means, 1988 LP Convention    	    amon@cs.qub.ac.uk
=======================================================================
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.2

mQCNAi4AlAwAAAEEAMS4YAiCfY3GD/op1hyVo63ynxOiroJZd5BUvUlqHCpL5+aB
d6CbVXSqQ1JTF08K5PPDsjrZWmszgXTkEtdXdWIIoz5nHNcRQY8r16XlAfu2n7Hb
zniygtysB5BIUFDC0zoD6whSTH12Nj0BejLR59lxYnl/WGmhyFyUA+sV8cYvAAUR
tBhEYWxlIEFtb24gPGFtb25AZ3BsLmNvbT4=
=pXBo
-----END PGP PUBLIC KEY BLOCK-----
=======================================================================


From bson@moomin.ai.mit.edu  Ukn Jun 23 00:24:41 1994
Received: from relay2.UU.NET 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA23836; Thu, 23 Jun 94 00:24:38 EDT
Received: from SunSITE.Unc.EDU by relay2.UU.NET with SMTP 
	(rama) id QQwvmf00702; Thu, 23 Jun 1994 00:28:04 -0400
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA04422; Thu, 23 Jun 1994 00:26:35 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA28433
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 23 Jun 1994 00:25:40 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA18613
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 23 Jun 1994 00:25:39 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA19505; Thu, 23 Jun 94 00:11:01 EDT
Received: from moomin.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA19495; Thu, 23 Jun 94 00:10:58 EDT
Received: by moomin.ai.mit.edu (3.1.28.1) id <m0qGgB3-000DJRC>; Thu, 23 Jun 94 00:14 EDT
Message-Id: <m0qGgB3-000DJRC@moomin.ai.mit.edu>
Date: Thu, 23 Jun 94 00:14 EDT
From: Jan Brittenson <bson@moomin.ai.mit.edu>
To: pdp8-lovers@moomin.ai.mit.edu
Subject: IGNORE ME: pdp8-lovers bounce test
Reply-To: bson@ai.mit.edu
Organization: nope
Status: RO
X-Status: 

This is just a silly test message, to collect expired and invalid
addresses at the end of the semester, and also to see if the rsalz
newsgate at U of Louisville has now stopped bouncing messages with
marginally bad headers.

						-- Jan Brittenson
						   bson@ai.mit.edu


From John_Wilson@mts.rpi.edu  Ukn Jun 23 13:54:45 1994
Received: from SunSITE.Unc.EDU 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA05497; Thu, 23 Jun 94 13:54:38 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA25645; Thu, 23 Jun 1994 13:57:48 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02317
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 23 Jun 1994 13:57:45 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA27058
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 23 Jun 1994 13:57:42 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA15915; Thu, 23 Jun 94 13:41:22 EDT
Return-Path: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA15908; Thu, 23 Jun 94 13:41:18 EDT
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41);
	id AA24154; Thu, 23 Jun 94 13:41:12 EDT for PDP8-LOVERS@AI.MIT.EDU 
Date: Thu, 23 Jun 94 13:41:00 EDT
From: John_Wilson@mts.rpi.edu
To: PDP8-LOVERS@ai.mit.edu
Message-Id: <4389163@MTS.RPI.EDU>
Subject: DQ619
Status: RO
X-Status: 

>?- Q-bus Floppy disk controller
 
That would account for the WD2793...
 
>There's no mention of whether or not it supports double-sided drives.  The 
>SA450
>was single-sided.  I believe the SA451 was the double-sided version.
 
Are you sure?  I thought the SA400 was SS 35-track, the SA400L was SS 40-track,
and the SA450 was DS 40-track.
 
Anyway, I'm curious how they fit the RX02 geometry on a 300RPM 5.25" disk?
 
John


From MCHUGH@utkvx.utcc.utk.edu  Ukn Jun 26 21:39:53 1994
Received: from SunSITE.Unc.EDU 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA11808; Sun, 26 Jun 94 21:39:49 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA12065; Sun, 26 Jun 1994 21:43:48 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA22529
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 26 Jun 1994 21:43:41 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA18352
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 26 Jun 1994 21:43:39 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA19526; Sun, 26 Jun 94 21:32:45 EDT
Return-Path: <MCHUGH@utkvx.utcc.utk.edu>
Received: from UTKVX1.UTK.EDU by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA19522; Sun, 26 Jun 94 21:32:43 EDT
Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.3-7 #6815)
 id <01HE0GQPRCES90NCQX@utkvx.utk.edu>; Sun, 26 Jun 1994 21:32:40 EDT
Date: Sun, 26 Jun 1994 21:32:40 -0400 (EDT)
From: Pat McHugh <MCHUGH@utkvx.utcc.utk.edu>
Subject: OS/8
To: pdp8-lovers@ai.mit.edu
Message-Id: <01HE0GQPRCEU90NCQX@utkvx.utk.edu>
X-Vms-To: IN%"pdp8-lovers@ai.mit.edu"
X-Vms-Cc: MCHUGH
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


Is it possible to get a copy of OS/8 for a PDP-8A/500? (really a
DECdatasystem 310, an old word processing station)

Mny tnx.
-Pat (mchugh@utkvx.utk.edu)


From bqt@minsk.docs.uu.se  Ukn Jun 27 11:49:01 1994
Received: from SunSITE.Unc.EDU 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA24025; Mon, 27 Jun 94 11:48:55 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA08675; Mon, 27 Jun 1994 11:52:52 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA19158
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Mon, 27 Jun 1994 11:04:20 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA04489
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Mon, 27 Jun 1994 11:03:57 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA12657; Mon, 27 Jun 94 10:37:41 EDT
Return-Path: <bqt@minsk.docs.uu.se>
Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA12649; Mon, 27 Jun 94 10:37:37 EDT
Received: from Minsk.DoCS.UU.SE by sunic.sunet.se (8.6.8/2.03)
	id QAA19863; Mon, 27 Jun 1994 16:37:26 +0200
Received: by Minsk.DoCS.UU.SE (Sun-4/630, SunOS 4.1.2)
 with sendmail 5.61-bind 1.5+ida/ICU/DoCS id AA22233; Mon, 27 Jun 94 16:37:26 +0200
From: Johnny Billquist  <bqt@minsk.docs.uu.se>
Date: Mon, 27 Jun 94 16:37:25 MET DST
Reply-To: bqt@minsk.docs.uu.se
To: Pat McHugh <MCHUGH@utkvx.utcc.utk.edu>
Cc: pdp8-lovers@ai.mit.edu
Subject: Re: OS/8
In-Reply-To: Your message of Sun, 26 Jun 1994 21:32:40 -0400 (EDT)
Message-Id: <CMM.0.90.0.772727845.bqt@Minsk.DoCS.UU.SE>
Status: RO
X-Status: 

>
>Is it possible to get a copy of OS/8 for a PDP-8A/500? (really a
>DECdatasystem 310, an old word processing station)
>
>Mny tnx.
>-Pat (mchugh@utkvx.utk.edu)

I don't think DEC would mind that much, but how do you propose
we get it to you?

	Johnny


From cjl@maestro.com  Ukn Jun 28 11:39:58 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA19115; Tue, 28 Jun 94 11:39:37 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA21728; Tue, 28 Jun 1994 11:42:54 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA29755
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 28 Jun 1994 11:42:44 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA21312
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 28 Jun 1994 11:42:41 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA19856; Tue, 28 Jun 94 11:13:47 EDT
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA19840; Tue, 28 Jun 94 11:13:40 EDT
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	(relay) id QQwwgi23314; Tue, 28 Jun 1994 11:13:23 -0400
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA18337; Tue, 28 Jun 94 11:09:16 EDT
Date: Tue, 28 Jun 1994 11:07:08 -0400 (EDT)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: OS/8
To: Pat McHugh <MCHUGH@utkvx.utcc.utk.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <01HE0GQPRCEU90NCQX@utkvx.utk.edu>
Message-Id: <Pine.3.07.9406281106.A17810-a100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 



On Sun, 26 Jun 1994, Pat McHugh wrote:

> 
> Is it possible to get a copy of OS/8 for a PDP-8A/500? (really a
> DECdatasystem 310, an old word processing station)
> 
> Mny tnx.
> -Pat (mchugh@utkvx.utk.edu)

Actually, that's backwards.  It's really an 8/a-500 that is marketroided
into the datasystem name.  As far as this group is concerned, that's a new
system.  Old systems are PDP-5 from 1963, not the late '70's and early '80's.

In any case, there's nothing special about that system in terms of OS/8,
etc. usage.  Just give the configuration of peripherals, etc.

cjl


From Thumper@wpi.edu  Ukn Jun 28 15:21:07 1994
Received: from SunSITE.Unc.EDU (calypso-2.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA24094; Tue, 28 Jun 94 15:20:33 EDT
Received: from watsun.cc.columbia.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA25776; Tue, 28 Jun 1994 15:24:16 -0400
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14684
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 28 Jun 1994 15:23:58 -0400
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA15957
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 28 Jun 1994 15:23:53 -0400
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA03831; Tue, 28 Jun 94 14:57:49 EDT
Return-Path: <@bigboote.wpi.edu:Thumper@wpi.edu>
Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA03826; Tue, 28 Jun 94 14:57:44 EDT
Received: from bigboote.WPI.EDU by mc.lcs.mit.edu id aa02001;
          28 Jun 94 14:57 EDT
Received: from wpi.WPI.EDU (thumper@wpi.WPI.EDU [130.215.24.1]) by bigboote.WPI.EDU (8.6.9/8.6) with ESMTP id OAA27492 for <pdp8-lovers@mc.lcs.mit.edu>; Tue, 28 Jun 1994 14:57:09 -0400
From: Bradley Alan Michaelis <Thumper@wpi.edu>
Received: (thumper@localhost) by wpi.WPI.EDU (8.6.9/8.6) id OAA15437; Tue, 28 Jun 1994 14:57:08 -0400
Message-Id: <199406281857.OAA15437@wpi.WPI.EDU>
Subject: DEC LNO3 Laser Printer
To: pdp8-lovers@mc.lcs.mit.edu
Date: Tue, 28 Jun 1994 14:57:08 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 366       
Status: RO
X-Status: 

If anybody is interested in a vintage laser printer, I've got one. 

A DEC LN03 with 256K extra memory. It's in great condition and I'll let it go 

for $100.00 or best offer. Included are: New toner package, PC serial adapter,

Modular cord and Microsoft Windows printer drivers. 

If you're interested, let me know at:


				thumper@wpi.edu


						Brad Michaelis


