Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 1 Jan 92 20:07:27 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Wed, 1 Jan 1992 20:07:25 -0500 Received: from soggy-fibers (soggy-fibers.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA16254; Wed, 1 Jan 92 19:47:20 EST From: rs@ai.mit.edu (Robert E. Seastrom) Received: by soggy-fibers (4.1/AI-4.10) id AA23250; Wed, 1 Jan 92 19:47:19 EST Date: Wed, 1 Jan 92 19:47:19 EST Message-Id: <9201020047.AA23250@soggy-fibers> To: pdp8-lovers@ai.mit.edu Subject: [delingma@thunder.lakeheadu.ca: Subscription.] From: rs@ai.mit.edu (Robert E. Seastrom) Date: Wed, 1 Jan 92 19:47:19 EST To: pdp8-lovers@ai.mit.edu Subject: [delingma@thunder.lakeheadu.ca: Subscription.] Return-Path: Date: Mon, 30 Dec 91 12:53:31 -0500 From: Dan Lingman To: pdp8-lovers-request@mc.lcs.mit.edu ... I have for sale a PDP11/10 with 2 teletypes, Volker-Craig Terminal (25-27 inch monitor(not sure about size, 2 8 inch drives, a faceplate and main board (wirewrapped) off a PDP 8/3 and a couple of shopping bags full of cards for the PDP 8/3 (I am not sure which cards are in the 11/10 - I can check. I am asking for best offer plus shipping. If you are interested, Please get back to me as soon as possible, as I will be holding an auction soon, and if these have not been spoken for, they get added in to that. Please keep in mind that shipping will be from Thunder bay, Ontario Canada. Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 2 Jan 92 02:15:00 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Thu, 2 Jan 1992 02:14:56 -0500 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19844; Thu, 2 Jan 92 01:50:26 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA23265; Thu, 2 Jan 92 01:50:18 EST Date: Thu, 2 Jan 92 1:50:18 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Message-Id: Date: Thu, 2 Jan 92 1:50:18 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu To: PDP8-Lovers@ai.mit.edu From: Charles Lasner (lasner@watsun.cc.columbia.edu) Subj: New Year's Resolutions, etc. To ring in the new year, let's resolve to help our architecture by giving it a "shot in the arm" in certain ways. I have been doing some things of late toward this end. A recent project has been to do the tedious task of total disassembly of the DECmate II and III ROMs. It is necessary to "bite the bullet" this way to finally totally understand just what a DECmate *really* is/is not relative to a *real* PDP-8. The ultimate goal is to produce operating systems for the entire line of PDP-8's, not just a family of slightly dissimilar systems that are separately bound to different models for no good reason other than the way they "hatched." (This means all DECmates and PDP-8, -12 models except for the -5 and -8/s which are too "brain-dead" as originally implemented.) My personal resolution is to produce P?S/8 V 9.x and to spearhead OS/8 V5. The current status of P?S/8 a/o V 8Z is that the RX01/02 single-density version will run on any -8 suitably configured (RX8E plugged into a DW8E or actual Omnibus as necessary with an RX01 or RX02, or DSD-210 with Omnibus interface and 1-4 drives with the same bus considerations). VT78 or VT278 with 1-2 pairs of RX01 or RX02 is also supported. The DECmate II with the RX78 option is also supported for 1-2 RX01/02 pairs, except that there is no direct way to boot such a system; the hardware only boots RX50 and/or RD51 hard disk. A "re-boot" program can be used that boots an RX01/02 system from either of the two "real" boot devices. Unlike all previous machines, the RX78 option requires an extra operation: RX8E's ignore the 6750 IOT, but VT78 and VT278 use the instruction as SEL - LOAD DRIVE PAIR SELECT per AC[11]. Power-on defaults to pair zero for compatibility with the RX8E. The DECmate II goes further, and requires AC[0] also be set. IF AC[0] is clear, the RX50 is selected. Thus up to four pairs of drives are possible on a DECmate II. (If the RD51 is present, only 1-2 pairs of RX50 can be connected.) The P?S/8 RX01/02 diskette uses handlers that obey the DECmate II convention completely, thus this system can be "re-booted" by using an appropriate loading program. (The basic RX01/02 program is used with an appropriate SEL instruction and AC bit combination.) BTW, it is recommended that all OS/8, etc. RX01/02 handlers be upgraded to support the SEL operation so that operation is possible on the DECmate II as well as earlier machines. There is no current support in P?S/8 for RX50 or RD51 volumes, but I am narrowing the gap with current efforts. (Mostly a matter of what to do, not how to do it :-).) There are still some problems when run on DECmates: P?S/8 supports a HLT instruction in the keyboard monitor via a HALT command. On PDP-8's with front panels, pressing continue is the appropriate action. Clearly, if you don't have a hardware method of continuing, you should avoid the command :-). Similarly, system I/O error disposition optionally consists of HLTing the CPU with the AC containing a device-dependent error. This option should be avoided if the requisite hardware is not present. VT78 and DECmate I initiate a register dump when the CPU halts; continuing is impossible on these systems, so the same reasoning applies on these systems. The DECmate II (likely III and III+ also) uses a CPU HALT screen panel with the ability to either reboot, enter setup, or continue at the user's option. This would seem to satisfy the P?S/8 HLT requirement, but there is a problem with the current slushware: When the CPU halts, the last console output character is lost. P?S/8 waits for TSF to skip and outputs a character, then waits for the TSF to skip again and outputs a character, and then halts. (The user typed HALT and expects HALT to be echoed.) The net effect is that the next line's prompt overlays the previous line because the is "swallowed" as a result of the slushware's swap-in of the transient HALT-handling routine. The best method to repair this situation is to improve the slushware to be more PDP-8 compatible; it is likely that there is some context-switch error in the existing code. The P?S/8 code is totally "legal" -8 code and should be maintained. (It is possible to evade the problem by waiting for the and then either doing nothing or output a "sacrificial" character before the HLT.) There are no other problems with running RX01/02-based P?S/8 on any family member machine because the instruction set is restriced to the classic PDP-8 (and LINC-8) only in *all* system programs. The device 03/04 problem mentioned in earlier discussions has already been solved using the software "^C-detect bit" method. (If there is sufficient interest, I will repeat the particulars of this method, especially as it relates to OS/8 V5.) This is why there are no restrictions within P?S/8 induced by the DECmate. All prior PDP-8 functionality is still present. (Contrast this with the truly sorry state of OS/78 V4 and OS/278 V2 which are "wimpy" subsets of their OS/8 predecessors :-(.) OS/8 V5 considerations leave much to do. I don't intend to do it all myself, but I will rework quite a lot of the stuff. OS/8 needs the 03/04 upgrade already worked out in P?S/8. This will allow a specification for all programs to upgrade to. The rest of the problems are more "internal" to major OS/8 components such as the keyboard monitor, ABSLDR, ODT, BATCH, PIP, etc., as well as all handlers for DECmate-connected disks and ports, etc. I intend to concentrate my efforts in this major hunk of the system. I hope my efforts will be answered by others contributing consistent efforts on some of the other programs that run "under" this much of OS/8 (such as Fortran, Basic, Pascal, etc.). The problems of upgrading both P?S/8 and OS/8 for DECmate-cognizant use are so significent that it is necessary to literally start from the beginning. Accordingly, I am working on the loading ROMs and slushware of the DECmate II and up. As of this writing, I have completely dis-assembled the DECmate II and III ROMs I have had contact with. (The DECmate II ROMs are known as 19H and 19N, and also an earlier version apparently known as 31Z which can't support a hard disk or recent slushware versions. DECmate III uses a ROM apparently known as 32H.) The sources are profusely documented using all "available" information. There are a few "sore spots" in that the code is clearly documented as to what it's doing, but there is no information currently available as to "why" the code is there :-). The sources produce accurate binary versions of the ROMs themselves as independently verified using a ROM blaster to read out the ROM contents. (Many utilities had to be written just to be able to read the various ROMs as PDP-8 code; there are four different formats of ROMs involved - a set of three for the DECmate II and a different format for the DECmate III. Part of the work was done on another machine and the ROM information was transferred using another set of PDP-8 utilities written primarily for the purpose as well as KERMIT-12.) One major set of facts learned from all this effort is the precise format of the "slushware" which is loaded in prior to any OS boot operation. The format of the slushware is variable. Only recent loading ROMs are compatible with recent releases of the slushware on the various bootable diskettes (and hard disks). Older slushware should be loadable on machines with newer loading ROMs; certain features will be missing in these earlier versions. Presumably the operating systems on these earlier media doesn't require the newer fetures available in later slushware versions. I have successfully accessed the slushware code uses in recent systems which is version 422. This is found in such places as the System Test Diskette V 4.5 (BL-HV86A-MV) and various WPS releases. It is necessary to upgrade existent OS/278 diskettes to this level of slushware in order to use them on the DECmate III. (There may be certain specific problems using OS/278 features on the DECmate III, such as using the supplied OS/278 COMM port handler which is slightly "ignorant" of DECmate III differences from the DECmate II. This can eventually be fixed. The released DM-101 OS/278 diskettes have slushware too old for DECmate III usage at all.) I have developed the source code for the slushware to the point of zero assembly errors, but it is still too soon to call it PDP-8 "code" even though it is correct in the absolute binary sense. (Still a lot of "blind" disassembler quirks and no comments :-(.) Enough has been observed to realize that there will be some form of "feedback" between the slushware and the loading ROMs. This will likely lead to some revision of the loading ROM sources to more accurately portray the system interaction. (Some code is unreferenced in the ROM directly, but is referenced by slushware calls just discovered, etc.) Clearly the full "exposure" of all DECmate internals will reveal the path to follow to allow common systems as proposed. When the slushware and ROM sources are finalized, they will be released on the net in accessible ways, such as on the newly-created PDP-8 archive available through anonymous FTP, etc. I would appreciate anyone's input regarding this major effort being undertaken virtually without any help from DEC whatsoever, a truly classic case of "reverse engineering" in its truest sense. If anyone has any slushware version newer than 422, or any DECmate II, III, III+ ROM versions differing from the four I mentioned, please contact me. I intend to produce a variant slushware version to incorporate additional features, etc., so I want to start from the "best" copy available. (I also welcome any gripes against this version which would tend to recommend using an older release as a base :-).) So, let's all welcome 1992 as the year of P?S/8 V9 and OS/8 V5, as we go into the FOURTH DECADE of PDP-8-type machines. (LINC and PDP-5 are 1962 designs :-) :-) :-).) cjl Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 6 Jan 92 15:20:29 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Mon, 6 Jan 1992 15:20:15 -0500 Received: from ama.caltech.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00572; Mon, 6 Jan 92 14:45:07 EST Received: by ama.caltech.edu (0.9/SMI-4.1) id AA27653; Mon, 6 Jan 92 11:07:42 PST Date: Mon, 6 Jan 92 11:07:42 PST From: ph@ama.caltech.edu (Paul Hardy) Message-Id: <9201061907.AA27653@ama.caltech.edu> To: lasner@watsun.cc.columbia.edu, pdp8-lovers@ai.mit.edu Subject: diassembling ROMs Date: Mon, 6 Jan 92 11:07:42 PST From: ph@ama.caltech.edu (Paul Hardy) To: lasner@watsun.cc.columbia.edu, pdp8-lovers@ai.mit.edu Subject: diassembling ROMs This will certainly be a learning experience. Listings might be available somehow from DEC on some of this stuff though. I once disassembled the M9312 boot PROM, then found out that I could have gotten a commented listing from DEC. However, I certainly learned some things in the process by figuring out everything for myself -- such as the method for printing out an octal digit -- rotating a bit of the number into the carry bit, then shifting this into the ASCII digit being constructed. I was also puzzled by the last section of the code, which it seemed there was no way to get to, until I decoded a device PROM and discovered that they jumped to absolute memory locations in that last section of the boot PROM. Good luck! --Paul Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 9 Jan 92 18:27:11 EST Received: from life.ai.mit.edu ([128.52.32.80]) by eli.CS.YALE.EDU via SMTP; Thu, 9 Jan 1992 18:26:57 -0500 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20453; Thu, 9 Jan 92 18:03:29 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA08088; Thu, 9 Jan 92 18:03:25 EST Date: Thu, 9 Jan 92 18:03:24 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Message-Id: Date: Thu, 9 Jan 92 18:03:24 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu From: Charles Lasner (lasner@watsun.cc.columbia.edu) To: PDP8-Lovers@ai.mit.edu mailing list, Comp.sys.dec.micro Subj: What about a DECmate is NOT a PDP-8? (quite long :-)) This article's purpose is to reveal the issues involved in "admitting" the DECmate into the PDP-8 "family" as it usually is defined. Due to certain shortcomings stemming from past blunders, etc., open issues remain (a/o this writing) that prevent totally unconditional acceptance. Hopefully, a "path" can be defined to alleviate the problem. Reader commentary is encouraged; please post to the newsgroup, or reply to the author (or mailing list) as necessary, etc. Current efforts will benefit from your responses. 1. So, just what IS a PDP-8? For the purposes of this article, a PDP-8 is a "complete" 12-bit system which meets ALL of the following requirements: a) A CPU with 4K/8K or more memory which is totally software compatible with the classic 1965 PDP-8 instruction set or better. This requirement covers all DEC 12-bit products (except the PDP-5 and PDP-8/s) sometimes referred to as the "Family of 8" from the PDP-8 through the PDP-8/a, VT-78, and all DECmates. Also included are various 8-clones from companies such as Fabritek, DCC, Intersil, CESI, and various Eastern Bloc countries (the Hungarian TPA, etc.). b) One or more block-replaceable storage devices such as a disk or DECtape. There are in turn several requirements placed on the hardware interface to the disk: i. It must be possible for the device to define blocks of data in multiples of 128 12-bit words that can be read/written as a block. For OS/8 purposes, logical records consisting of 256 12-bit words must be definable; P?S/8 merely requires the 128 word block grouping. OS/8 additionally demands the ability to read the first 128 words without destroying any memory beyond the 128 word buffer. Further, when writing OS/8 may supply only 128 words of meaningful information, and will allow the second 128 words of the logical record to become undefined contents as a result, but the entire 256 word record must still be readable without error at a later time despite the "short" write function. ii. For OS/8 purposes, a disk device handler must be viable to control all read/write operations to the device according to OS/8 calling and loading conventions. The overall size of the handler is preferably one page long, but two pages is the absolute maximum allowed. (On many devices, handlers this size are a tradeoff of viability versus good error handling, if any! Further, device performance may be compromised as well to allow the disk handler to "fit" into only two pages.) If a disk is not required to be a boot device, a two-page non-system handler is allowed which has effectively more code space due to lack of reserved locations used by the rest of the operating system. For P?S/8 purposes, a disk device handler must be viable to control all read/write operations to the device according to P?S/8 calling and loading conventions. The overall size is preferably one page long, but nine pages is the absolute maximum allowed. This significently larger number than OS/8 allows certain operating environment advantages such as better device performance and/or error handling, etc. Further, P?S/8 handlers can have optional features used to assist binary loader utilites accomplish read-only loading of programs. (P?S/8 systems that support this optional feature can load binary files while maintaining device write-protect; OS/8 cannot support this feature ever.) c) There must be an interface to a system console using device 03/04 that is TOTALLY COMPATIBLE with the classic console interface first introduced on the PDP-5 in 1962. There may be other optional equipment present such as parallel or serial printer ports, communications ports, additional disk drive units, additional/separate disk systems/units, additional terminals, additional memory, etc., but these are beyond the primary requirement. Support for these may vary or be application-specific, etc. OS/8 requires 8K of main memory (12K for two-page handler boot devices); P?S/8 requires 4K of main memory (8K for nine-page handler boot devices). P?S/8 also requires an additional 3K for alternate console support routines which is non-overlapping in the case of a nine-page boot device system. P?S/8 and OS/8 tend to handle certain devices in a like manner. For example, both systems handle DECtape as a one-page boot device; RX01 is a multiple-page boot device for either system. In both cases P?S/8 requires exactly 4K less memory for a mimimal system based on the same device. 2. So what's wrong with a DECmate? Clearly, item a) above is satisfied in all DECmate models. The 6120 instruction set is a proper superset of the classic PDP-8 and the PDP-8/e or a, and all models are equipped with 32K, dual stack pointers, CP memory, etc. (EAE is not supported, but other machines share this restriction, e.g., the PDP-8/l.) Item b) above is (theoretically, see below) also not a problem. The DECmate I comes equipped with 1-2 pairs of RX01/02, and optionally supports 1-4 RL02s. DECmate II comes with 1 pair of RX50, and optionally an additional RX50 pair and/or 1-2 pairs of RX01/RX02 or a 5 Meg or larger hard disk. (The hard disk and RX01/02 options are mutually exclusive. Hard disk size extends up to 64 Megs or more; my own system is 64 Megs.) DECmate III comes with 1 pair of RX50. DECmate III+ comes with a single RX50-compatible drive and a hard disk (usually 20 Megs.). Unfortunately, all DECmates (other than the DECmate I) have a problem as currently implemented: As distributed, the bootable volumes on a hard disk, or the contents of a bootable RX50 diskette must contain a "signature ID" at the beginning of the disk. Failure to maintain this information causes the disk to become corrupted and non-bootable. This field is located on the disk area logically referred to as block 0000, and CANNOT be maintained by existing OS/278 handlers (see below). Thus certain system operations must be avoided to prevent system crashes which are totally "legal" and proper (and necessary) features of OS/8. (The DECmate I lacks this problem.) Hopefully, this problem is fixable by modification of system conventions or handler rewrites or both. Some of this work is currently in progress. (see below). Item c) above is the main "problem child." The DECmate has a "simulated" interface to the device 03/04 console, which is NOT totally compatible, and the differences "matter." While various application-only systems such as WPS and COS have been written for the DECmate, there is only OS/278 available for the DECmate II, which is a problematic "step-child" of OS/8. OS/278 V2 was released to DECUS as DM-101, and eventually as DM-111, the alledged sources of DM-101. (DM-111 comes with a disclaimer that the DM-101 running binary doesn't quite match the DM-111 sources! I have confirmed that this is at least partially true: the RD51 handler sources are NOT identical to the running system. Further, various source comments are not totally accurate in describing the actual hardware :-(.) OS/278 V2 comes with a long list of incompatibilities relative to OS/8 and various in-between releases such as OS/78 V3 and V4. Some are documented in OS/278 files on the release diskettes; others were handed out on notes distributed at the Spring, 1983 DECUS Symposium in New Orleans during the OS/8 sessions. Users such as myself can add known introduced bugs to the list. Some of these hinder Kermit-12 configuration, and are documented in K12MIT.BWR accordingly. Others, such as ODT's system crash when certain keys are pressed, etc., are well known. Most of the incompatibilities stem from expedient changes made to OS/8-OS/78 by a small group of "volunteers" within DEC. Some are ill-advised personal-preference changes (such as changing the prompt character a few times!) while others are "band-aids" on certain hardware-specific problems. The release notes reveal that certain OS/8 commands are actually "hazardous to your health" and must be avoided in OS/278 even though they are present! The console problem actually first surfaced in OS/78 V4, which was written in an attempt to minimize the impact on OS/8 on the DECmate I. When this "bastardized" system is used on either an -8 or DECmate I, it behaves as a "wimpy" subset of OS/8 because certain features have been totally dropped. What has happened is that the keyboard handling is limited to only what can be done in simple-minded console routines known to only require the compatible subset of both the -8 and the DECmates. Former features are excised out or are sometimes attempted as "fake" simulations of the former feature. OS/278 V2 takes this "lameness" to a higher level of implementation, but some bugs have surfaced in a few utilities due to lack of consistency, etc. Other problems with OS/278 are totally reversible, such as the penchant for changing the prompt character (an unreleased version used > as a prompt, not the OS/8 . or OS/278 }.), and certain RX handler conventions arbitrarily incompatible with existing design, etc. Most of these "lesser" problems can be overcome merely by obtaining (through disassembly if necessary) the sources of certain components of OS/278 to allow certain changes to be made. (Quite a few system components' sources were NOT included in DM-111 :-(.) There are a few other slushware-related problems, such as interaction between the simulated console and system HLT instructions, etc., but these may also be fixable (see below). 3. How to right the DECmate wrongs. To correct all of the DECmate problems will require a lot of effort, but in theory all is doable. I have been recently doing work on overcoming the signature problem, and a solution is in sight. There are alternate signature values that can bypass the corruption problem of the standard formula, assuming these alternates are "acceptable" for all applications. (It has not been proven that all software accepts the alternate values, although boot utilities accept the alternate values for a bootable volume's id, and the ROM/slushware RX50 routines accept similar values for RX50.) An alternate method consists of implementing "smarter" handlers for the various operating systems that depend on an upgraded slushware version. Slushware support can "repair" the signature area as necessary, etc., with minimal impact on the handler implementation. The tradeoffs of these two methods will be the subject of a separate discussion. It is sufficient at this time merely to indicate that both are theoretically viable; the better method will be chosen later. Whichever method is implemented, the associated "hazards" will be eliminated, and the attendant coding can be restored for full OS/8 compatibility. P?S/8 supports a sufficiently large handler space that the handler doesn't share OS/8's problem in this area. P?S/8 will undoubtedly use one of the two methods, but implemented in a more straight-forward way within the handler itself. I have nearly completed a large project of disassembling the DECmate II, III ROMs and slushware. When this is completed, it will be possible to define the slushware "repair" function mentioned above if deemed necessary. The alternate signature value was derived by observing the code that validates the signature field itself. The completed source code for the ROMs and slushware will allow slushware upgrade. A bug associated with losing context of the simulated console output during response to a HLT instruction will be on the list of slushware problems to fix at that time. Other improvements may be definable as well, such as easily re-mapped key translations. (Someone suggested making COMPOSE CHARACTER into an alternate ESC key to bring TECO command completion back to the left hand, etc. COMPOSE CHARACTER (re-mapped to ESC) and the CTRL key could optionally be swapped, etc. These translations would be possible using a simple PRQ trapped function call to upgraded slushware.) The main problem with the console is NOT completely solvable; the interface is simply not compatible, and cannot be changed. What can change is the system's demands on the interface to allow the DECmate subset compatibility to be sufficient. P?S/8 has already been adapted to depend on merely this form of subset compatibility. The main issue is to define a software abort (^C) bit so that the hardware need not "remember" this status as is currently demanded by OS/8. All generic P?S/8 programs detect ^C using the subset instructions only, and then set the soft bit if required. The keyboard monitor is also able to sense the hardware re-read of a ^C character if P?S/8 is running on a (pre-DECmate) compatible machine, so programs which by nature are NEVER run on DECmates (such as the TC08 DECtape Formatter) need not be upgraded to this specification. All generic system programs, such as PAL, must completely conform to the specification however. OS/8 can also be modified to incorporate an analogous scheme that implements a "soft" abort bit; a tentative model has been defined. When this is implemented, the DECmate keyboard interface will be acceptable (just barely). The DECmate console output interface emulation is only slightly incompatible with the PDP-8. By careful design it is possible to use completely compatible output routines on all PDP-8s and DECmates. Only one minor quirk of the interface is not supported on the DECmate having to do with testing and clearing the flag which is avoidable. By demanding rigorous control of the output flag in all programs, this problem is easily solved. Most programs already conform to this minor restriction; there seems to be no reason for any inherent problem other than enforcing the rules. 4. What else should be done? As long as this much effort is being applied, there are a few other areas to clean up: Certain components of OS/8 have become "obscure" in more recent system releases such as RESORC, etc. Part of this is a "political" problem such as the abandonment of programs such as BUILD, etc., as well as various older handlers (the "Pre-Omnibus" edict). This situation is totally reversible since sources of all of these OS/8 components are available. It is necessary to scan all programs for inadvertant use of superset instructions requiring more than the classic PDP-8 instruction set. These instructions have "crept" into the code over the years. Most of these problems are oversights introduced by programmers unaware of the requirement (to avoid BSW, IAC RAR, CAF, etc.). Some OS/278 code is inexplicably flawed; certain basic system functions such as the SAVE command just don't work! Comparing the code to an older version should reveal the problem. (If it isn't broke, don't fix it. But they fixed it anyway, so now it's broke. So now you have to fix it.) Interrupt-driven routines should make a special-case check for DECmate operation because the interrupt operations will likely be too inefficient for DECmate use. They should be abandoned in favor of simple-minded non-buffered output routines on a DECmate. Some of this reasoning needs to be applied to OS/8 Fortran IV and BASIC. 5. So will a DECmate ever be accepted as a PDP-8? Some "purists" will never accept the DECmate as a PDP-8, because they want all of the onus placed on the DECmate to be totally PDP-8 compatible with no change. Clearly this will never happen. Since much of OS/78 V3 and following isn't PDP-8-compatible currently, this is clearly a time for a code cleanup; the DECmate merely brings this problem to a head. It is unacceptable that there isn't one single version for all models (P?S/8 never had this problem, never will! :-)). By applying a little more effort, OS/8's dependence on some of the more quirky aspects of the console interface will be eliminated. All important programs can be easily upgraded to OS/8 Version 5 compatibility. Space permitting, programs can even make the changes contingent on recognizing which system is in use, etc., to allow use on older releases as well, but the main goal is to unify the system, not to encourage continued fragmentation. With wide-spread acceptance of OS/8 Version 5 as the OS/8 version of choice (and the P?S/8 alternative being as flexible), the DECmates will finally become acceptable to the Family of 8. cjl Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 20 Jan 92 06:30:03 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Mon, 20 Jan 1992 06:29:57 -0500 Received: from mail.Germany.EU.net ([192.76.144.65]) by life.ai.mit.edu (4.1/AI-4.10) id AA16948; Mon, 20 Jan 92 05:17:50 EST Received: from mpifrrouter-x25a.WiN-IP.Uni-Dortmund.DE by mail.Germany.EU.net with SMTP (5.65+/UNIDO-2.1.0.b) via EUnet for ai.mit.edu id AA19286; Mon, 20 Jan 92 11:10:39 +0100 Received: from aibn53.mpifr-bonn.mpg.de by mpifrrouter (4.1/SMI-4.0) id AA21271; Mon, 20 Jan 92 11:15:31 +0100 Received: by aibn53.mpifr-bonn.mpg.de (5.57/Ultrix4.2) id AA03883; Mon, 20 Jan 92 11:09:11 +0100 Date: Mon, 20 Jan 92 11:09:11 +0100 From: souva@aibn53.mpifr-bonn.mpg.de (Ignatios Souvatzis) Message-Id: <9201201009.AA03883@aibn53.mpifr-bonn.mpg.de> To: pdp8-lovers@ai.mit.edu Subject: forwarded message from Richard Chapman Reply-To: chapman@cs.cornell.edu (Richard Chapman) X-Mailer: GNU Emacs 18.57.11 X-Face: %p,8?Wc#eJ?Mf`-U.`%:}Nqnx1,!1X8DT:^_!9^Xs8a8X-bPWbzPD}Q}[QDh1a Received: by bagpipe.cs.cornell.edu (5.57/N-0.12) id AA13527; Fri, 24 Jan 92 11:51:24 -0500 To: pdp8-lovers@ai.mit.edu Date: Fri, 24 Jan 92 11:51:27 -0500 From: chapman@cs.cornell.edu (Richard Chapman) To: pdp8-lovers@ai.mit.edu First, thanks to all those who responded to the message that was forwarded by a kind soul to this mailing list. Now I am on the list, and that problem is "fixed". The reason for the quotes is that I think I may have removed the symptom but not the disease. The M220's in the accumulator seems okay; permuting them didn't have any effect. The thing that did have an effect was removing an M516 module from the rear of the backplane, the front of a group of three magenta flip-chips off in a corner. Several things here; maybe the flip-chips are in the wrong places, maybe someone just shoved them in when the machine was junked. I don't know. I think the chart that needs to be consulted is called "Utilization of modules". Or, something else is wrong and somehow I disabled the bad boards somehow by pulling the M516, which is labelled "positive bus receiver". Help? Now, all the instructions except IOT seem to work. All the IOT instructions (I tried the instructions 600x (turn interrrupts on/off, etc, 604x (control the tty printer) and 603x (control the tty reader)) suffer from two problems: 1. They set the two's bit in the accumulator 2. They skip the next instruction (some instructions are supposed to do this, based on a flag value, but not all of them, right?) For example, if I run a 6046 (TLS) instruction at address 1000 with 0241 in the accumulator, I get ascii 0243 printed on the tty, 0243 in the accumulator, and the next instruction executed is the one at address 1002. My impression is that I should get 0241 in the accumulator and address 1001 next. Help? Here is a description of what modules are where, if you turn the machine upside down and take the cover off. As far as I know the only things that should be in there are the cpu, 4k core memory and support logic (the green and white), and the interface to a teletype (magenta in the back). Thanks for any help you can give, Richard Chapman FRONT A B C D M220------------M220 M113 M111 M220------------M220 M700 M700 M220------------M220 M216 M115 M220------------M220 M113 M310 M220------------M220 M216 M310 M220------------M220 M111 M310 M617 M617 M216 M310 M617 M617 M115 M160 M160 M160 M119 -- M115 M216 M117 -- M160 M111 M115 M113 M160 M113 M117 M111 M115 M119 M113 M310 -- -- M113 M310 -- -- -- M216 -- -- M360 M617 G020 G020 G221 G221 G020 G020 G221 G221 G020 G020 +------------------+ W025 W025 | core | W025 W025 +------------------+ G228 G228 G221 G221 -- G228 G221 G221 G624 G624 G228 G228 G624 G624 M002 -- G826------------G826 M623 M623 G785------------G785 M115 M623 -- -- M660 M906 -- -- M660 M906 M516 -- M707------------M707 M516 -- M706------------M706 M111 -- M452 W076D REAR