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 Subject: Some more PAL considerations, etc. To: pdp8-lovers@ai.mit.edu Cc: Charles Lasner Message-Id: 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 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 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) In this case the current page literal gets created as a byproduct while its address is returned as the subexpression value. IFZERO A=3 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 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 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 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 IFNZRO PQS 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 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 IFNZRO PAL8 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 /COMMENT What we instead see is: IFNZRO TEST 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 ); 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 ); 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: 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 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 ); 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 ); 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: 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 ); 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 ); 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: 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: 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 ); 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 ); 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: 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 Subject: Re: more data To: Robert Smith Cc: pdp8 lovers In-Reply-To: Message-Id: 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 ); 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 ); 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: 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 Subject: Re: recent acquistions To: Robert Smith Cc: pdp8 lovers In-Reply-To: <9406090024.AA02405@opus> Message-Id: 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 ); 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 ); 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: 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" 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 ); 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 ); 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: 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 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 ); 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 ); 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: 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 ); 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" 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 ); 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 ); 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: 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 ); 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 ); 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: 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 ); 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 ); 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: 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 ); 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" 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 ); 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 ); 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: 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 ); 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" 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 . 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 ); 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 ); 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: 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" 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 ); 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 ); 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: 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 Sender: Charles Lasner Reply-To: Charles Lasner Subject: Re: PDP-8 docs To: Seth the Lesser Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <199406120748.AA26465@mailhub.cc.columbia.edu> Message-Id: 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 ); 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 ); 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: 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" 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 ); 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 ); 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: 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 ); 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 ); 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: Date: Tue, 14 Jun 1994 14:02:10 -0500 (CDT) From: Anthony D'atri 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 ); 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 ); 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: 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: 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 ); 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 ); 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: 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: 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 ); 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 ); 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: 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 Subject: Re: Convincing DEC that they made the PDP-5 To: emcguire@bucky.i2.com Cc: "Anthony D'atri" , pdp8-lovers@ai.mit.edu In-Reply-To: <9406141942.AA10206@bucky.intellection.com> Message-Id: 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 ); 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 ); 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: 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 ); 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 's message of "Sun, 12 Jun 1994 22:06:17 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jun 1994 01:20:53 -0400 From: Seth "the Lesser" Status: RO X-Status: Charles Lasner 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 > 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 ); 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 ); 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: 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 Subject: Re: gigi followup To: Robert Smith Cc: pdp8 lovers In-Reply-To: Message-Id: 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 ); 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 ); 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: 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 Subject: Re: PDP-8 docs To: Seth the Lesser Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <199406150520.AA08365@mailhub.cc.columbia.edu> Message-Id: 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 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 > > 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 ); 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 ); 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: 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" 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 ); 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 ); 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: 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 Subject: Re: Permission to photocopy DEC documentation To: prp@ssd.intel.com Cc: "Douglas W. Jones" , pdp8-lovers@ai.mit.edu, prp@ssd.intel.com In-Reply-To: <9406131821.AA21288@SSD.intel.com> Message-Id: 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 ); 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 ); 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: 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 ); 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 ); 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: 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 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: 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 ); 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 ); 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: 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" 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 ); 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 ); 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: 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 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: 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 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." Date: Mon, 20 Jun 94 11:00:52 -0700 From: prp@SSD.intel.com Status: RO X-Status: > From: Charles Lasner > 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 ); 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 ); 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: 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" 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 ); 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: Date: Mon, 20 Jun 1994 14:30:39 -0500 (CDT) From: Anthony D'atri To: Charles Lasner 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 ); 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 ); 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: 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 ); 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 ); 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 ; Thu, 23 Jun 94 00:14 EDT Message-Id: Date: Thu, 23 Jun 94 00:14 EDT From: Jan Brittenson 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 ); 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 ); 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: 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 ); 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 ); 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: 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 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 ); 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 ); 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: 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 Date: Mon, 27 Jun 94 16:37:25 MET DST Reply-To: bqt@minsk.docs.uu.se To: Pat McHugh 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: 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 ); 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 ); 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: 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 Subject: Re: OS/8 To: Pat McHugh Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <01HE0GQPRCEU90NCQX@utkvx.utk.edu> Message-Id: 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 ); 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 ); 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 ; Tue, 28 Jun 1994 14:57:09 -0400 From: Bradley Alan Michaelis 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