From rfs@kepler.unh.edu Mon Mar 2 03:17:40 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA21599; Mon, 2 Mar 92 03:17:36 EST Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA23226; Mon, 2 Mar 92 03:17:24 EST Received: from kepler.unh.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03299; Mon, 2 Mar 92 02:51:08 EST Received: by kepler.unh.edu id AA11067 (5.65c+/IDA-1.4.4 for PDP8-lovers@ai.mit.edu); Mon, 2 Mar 1992 02:51:06 -0500 Date: Mon, 2 Mar 1992 02:51:06 -0500 From: Robert F Spence Message-Id: <199203020751.AA11067@kepler.unh.edu> To: PDP8-lovers@ai.mit.edu Subject: subscribe subscribe Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 6 Mar 92 04:37:54 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Fri, 6 Mar 1992 04:37:47 -0500 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13504; Fri, 6 Mar 92 04:18:02 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA27262; Fri, 6 Mar 92 04:17:55 EST Date: Fri, 6 Mar 92 4:17:54 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Randomness Message-Id: Date: Fri, 6 Mar 92 4:17:54 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Randomness Just testing the list for someone not sure he's still on it. Also, there is some -8-related stuff going on intermittently on alt.folklore.computers of interest to this group. cjl (Occasionally wearing flame-retardant clothing) Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sat, 7 Mar 92 04:26:11 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sat, 7 Mar 1992 04:26:08 -0500 Received: from uccvma.ucop.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07326; Sat, 7 Mar 92 04:02:14 EST Message-Id: <9203070902.AA07326@life.ai.mit.edu> Received: from UCCVMA.BITNET by uccvma.ucop.edu (IBM VM SMTP V2R2) with BSMTP id 2974; Fri, 06 Mar 92 09:07:02 PST Date: Fri, 06 Mar 92 09:07:01 PST From: ISSBAL@uccvma.ucop.edu To: pdp8-lovers@ai.mit.edu Subject: Info, please... Date: Fri, 06 Mar 92 09:07:01 PST From: ISSBAL@uccvma.ucop.edu To: pdp8-lovers@ai.mit.edu Subject: Info, please... From: Bruce Lane ISSBAL @ UCCVMA (510) 987-0014 Subject: Info, please... Hi... I'm curious about the PDP8-LOVERS newsgroup, as I own a PDP-11/34A system. Could you tell me a little more about it, please? I may want to subscribe. Thanks! ==Bruce Mail: Telecommunications Services . Office of the President, University of California . 300 Lakeside Drive, Room 3010 . Oakland, CA 94612-3550 From setala@mdata.fi Wed Mar 11 07:01:28 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA02666; Wed, 11 Mar 92 07:01:19 EST Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA06735; Wed, 11 Mar 92 07:01:24 EST Received: from fuug.fi by life.ai.mit.edu (4.1/AI-4.10) id AA02673; Wed, 11 Mar 92 06:43:40 EST Received: from mdata.fi by fuug.fi with UUCP id AA01974 (5.65c/IDA-1.4.4 for PDP8-lovers@ai.mit.edu); Wed, 11 Mar 1992 13:42:12 +0200 Received: by mdata.fi (5.65c/1.10) id AA08481; Wed, 11 Mar 1992 02:34:07 +0200 Date: Wed, 11 Mar 1992 02:34:07 +0200 From: Saku Setala Message-Id: <199203110034.AA08481@mdata.fi> To: PDP8-lovers@ai.mit.edu Subject: subscribe setala@mits.mdata.fi subscribe setala@mits.mdata.fi --Saku Setala setala@mits.mdata.fi From rfs@kepler.unh.edu Wed Mar 11 08:19:19 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA19052; Wed, 11 Mar 92 08:19:11 EST Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA03954; Wed, 11 Mar 92 08:19:21 EST Received: from kepler.unh.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03394; Wed, 11 Mar 92 08:05:49 EST Received: by kepler.unh.edu id AA17535 (5.65c+/IDA-1.4.4 for PDP8-lovers@ai.mit.edu); Wed, 11 Mar 1992 08:05:47 -0500 Date: Wed, 11 Mar 1992 08:05:47 -0500 From: Robert F Spence Message-Id: <199203111305.AA17535@kepler.unh.edu> To: PDP8-lovers@ai.mit.edu Subject: unsubscribe rfs@kepler.unh.edu unsubscribe rfs@kepler.unh.edu From urbanek@pender.ee.upenn.edu Wed Mar 11 14:07:21 1992 Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA24189; Wed, 11 Mar 92 14:07:19 EST Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA08476; Wed, 11 Mar 92 14:07:30 EST Received: from linc.cis.upenn.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08629; Wed, 11 Mar 92 13:43:52 EST Received: from PENDER.EE.UPENN.EDU by linc.cis.upenn.edu id AA17859; Wed, 11 Mar 92 13:43:49 -0500 Return-Path: Received: by pender.ee.upenn.edu id AA05163; Wed, 11 Mar 92 13:41:54 EST Date: Wed, 11 Mar 92 13:41:54 EST From: urbanek@pender.ee.upenn.edu (Wolfram Urbanek) Posted-Date: Wed, 11 Mar 92 13:41:54 EST Message-Id: <9203111841.AA05163@pender.ee.upenn.edu> To: pdp8-lovers@ai.mit.edu unsubscribe urbanek@pender.ee.upenn.edu Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 13 Mar 92 10:58:16 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Fri, 13 Mar 1992 10:58:04 -0500 Received: from saqqara.cis.ohio-state.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22463; Fri, 13 Mar 92 10:02:04 EST Received: by saqqara.cis.ohio-state.edu (5.61-kk/5.911008) id AA17799; Fri, 13 Mar 92 09:49:08 -0500 Received: by n8emr.uucp (Ohio AMPR Gateway Smail3.1.16.1 #16.30) id ; Fri, 13 Mar 92 04:15 EST Received: by uncle.uucp (/\=-/\ Smail3.1.16.1 #16.29) id ; Fri, 13 Mar 92 04:19 EST Received: by jcnpc.uucp (/\=-/\ Smail3.1.16.1 #16.30) id ; Fri, 13 Mar 92 03:38 EST Received: by kumiss.UUCP (V1.15/Amiga) id AA002uq; Fri, 13 Mar 92 01:49:16 EDT Date: Fri, 13 Mar 92 01:49:16 EDT Message-Id: <9203130549.AA002uq@kumiss.UUCP> From: kumiss!erd@cis.ohio-state.edu (Ethan Dicks) To: pdp8-lovers@ai.mit.edu Subject: Short test Date: Fri, 13 Mar 92 01:49:16 EDT From: kumiss!erd@cis.ohio-state.edu (Ethan Dicks) To: pdp8-lovers@ai.mit.edu Subject: Short test This is a test to see if I can send stuff to the listserv. I was told that there was a problem with my address as listed. Ob PDP-8 question: Does anyone have any docs on the original 8? I have one complete (and one disassembled) unit, but the cards were re-arranged to make an ad photo look better. The damn photographer didn't like all the holes in the ALU section and bunched up the cards. To see the results of his efforts, look at the Software Results Ad on the back of "CPU Wars" by Chas. Andres. The machine in the ad is one of the machines I own. The other is mostly covered in offset ink :-P -ethan Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sat, 14 Mar 92 06:24:52 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sat, 14 Mar 1992 06:24:26 -0500 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20220; Sat, 14 Mar 92 06:07:51 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA29730; Sat, 14 Mar 92 06:07:38 EST Date: Sat, 14 Mar 92 6:07:37 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Message-Id: Date: Sat, 14 Mar 92 6:07:37 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu From: Charles Lasner (lasner@watsun.cc.columbia.edu) To: pdp8-lovers@ai.mit.edu Subj: Announcement of new Kermit-12 utilities Currently available at watsun.cc.columbia.edu via ftp in /pub/ftp/kermit/d/k12*.* are two new files: k12enc.pal and k12dec.pal. The new files have internal dates of 1-Mar-92. These are the newly updated ENCODE and DECODE programs for moving around OS/8 binary files. There is a new feature added to both, the ability to deal with "raw" image data. Consider the following usage: .R ENCODE *BIGGY.EN Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA11233; Sun, 15 Mar 92 22:12:38 EST Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA27184; Sun, 15 Mar 92 22:12:50 EST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA23746; Sun, 15 Mar 92 22:00:19 EST Received: by rice-chex (4.1/AI-4.10) id AA13433; Sun, 15 Mar 92 22:00:14 EST Date: Sun, 15 Mar T 22:00:13 EST Message-Id: <9203160300.AA13433@rice-chex> From: Jan Brittenson To: PDP8-lovers@ai.mit.edu, setala@mdata.fi Subject: Re: subscribe setala@mits.mdata.fi Done. From bson@ai.mit.edu Sun Mar 15 22:20:29 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA14469; Sun, 15 Mar 92 22:20:26 EST Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA30050; Sun, 15 Mar 92 22:20:37 EST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA23753; Sun, 15 Mar 92 22:00:29 EST Received: by rice-chex (4.1/AI-4.10) id AA13440; Sun, 15 Mar 92 22:00:23 EST Date: Sun, 15 Mar T 22:00:22 EST Message-Id: <9203160300.AA13440@rice-chex> From: Jan Brittenson To: PDP8-lovers@ai.mit.edu, rfs@kepler.unh.edu Subject: Re: unsubscribe rfs@kepler.unh.edu Done. Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sun, 15 Mar 92 22:46:50 EST Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sun, 15 Mar 1992 22:46:48 -0500 Received: from churchy.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24419; Sun, 15 Mar 92 22:27:49 EST Received: by churchy.gnu.ai.mit.edu (5.65/4.0) id ; Sun, 15 Mar 92 22:27:47 -0500 Date: Sun, 15 Mar 92 22:27:47 -0500 From: bson@gnu.ai.mit.edu (Jan Brittenson) Message-Id: <9203160327.AA17276@churchy.gnu.ai.mit.edu> To: pdp8-lovers@ai.mit.edu Subject: All these "request" replies Date: Sun, 15 Mar 92 22:27:47 -0500 From: bson@gnu.ai.mit.edu (Jan Brittenson) To: pdp8-lovers@ai.mit.edu Subject: All these "request" replies My aoplogies regarding all these replies. I didn't notice that requests also sent to pdp8-lovers got that address copied into the carbon copy list in my acks. (The Unix "new mail reader" syndrome. :-)) -- Jan Brittenson bson@gnu.ai.mit.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Sat, 28 Mar 1992 05:41:57 -0500 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sat, 28 Mar 1992 05:41:52 -0500 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10321; Sat, 28 Mar 92 05:07:06 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA01763; Sat, 28 Mar 92 02:14:29 EST Date: Sat, 28 Mar 92 2:14:28 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Message-Id: Date: Sat, 28 Mar 92 2:14:28 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu From: Charles Lasner (lasner@watsun.cc.columbia.edu) To: PDP8-Lovers@ai.mit.edu Subj: Status of the DECmate bootable volume problem (Note: very long; important to the concerned intended audience.) I have done some recent work on the problem of boot-volume destruction on DECmates using OS/278 Version 2. I would like to obtain some user "feedback" regarding the direction taken to solve one of the stickier problems of this system. The ultimate goal is a replacement system currently dubbed OS/8 Version 5. V5 will run on any -8 family member (no -5's or -8/s's) thus obsoleting all previous versions that have limited application due to "creeping" design problems. At the current time I am concentrating on DECmate-specific problems because most of the problems are present there. (It is a relatively simple matter to recover classic PDP-8 compatibility in most of the programs because that was the actual original design specification. Newer "maintainers" didn't know this however, nor did their managers :-). I have already screened OS/278's release of PAL8 and CREF and find no specific dependencies, which is why they are distributed with Kermit-12. The rest need the same attention; undoubtedly a few BSW's and CAF's and IAC-rotate combinations will turn up and can be eliminated.) Statement of the Problem: boot-block destruction. Several perfectly reasonable OS/8 commands exist that have one thing in common: Logical record 0000 on SYS: is zapped for some specific purpose. For example, the command SET SYS OS/8 reads in SYS:'s record 0000, and then modifies relative word 4, then writes the record back. The only change involves word 4, which can be HLT or CLA HLT or OSR HLT or CLA OSR HLT. The four combinations were defined for various less-than perfect implementations of defining the system as OS/8, OS/78, OS/278, and VT/278. (The last exists only in OS/78 V4 primarily for the DECmate I.) Surprisingly enough, this command even exists in OS/278 Version 2. The use of BUILD to create a new OS/8 system is another familiar operation that writes out the desired information on record 0000 to form the system bootstrap block. Alternatively, the system can be created from a .SY file using the PIP /Y option. Users who wish to change the default year-group for their system need to update record 0000 using FUTIL or other utility so that the last word of the record which is loaded in location 07777 contains the proper value. For example, distributed versions of OS/278 now claim a year more than 8 years ago for any directory operation such as the DIR command. By using the proper value in the year-group bits, the system date can be more accurate by default. (Typing in a DATE command to set the date fixes this of course, but the default is wrong until you do this.) On all systems prior to OS/278, all of these operations work fine and are of no consequence. Use of them on OS/278 causes the system to become NON-bootable! To make matters worse, the system is NOT delivered set to OS/8, so many programs cannot be used with the R, RUN, or GET commands. (This is traceable to OS/78 V1 which is also coincidentally OS/8 V3D. The entire "feature" is one of those "less is more" things invented by a long-departed manager. All subsequent versions support this, but OS/278 is "stuck" with it.) Attempts to use SET SYS OS8 not only don't work, an additional "feature" is a warning message that the system isn't set to SET SYS OS278. However, restoring OS/278 mode doesn't repair the boot volume problem! (There is a kludged workaround for floppies only, but no possible repair for hard disk.) So what's wrong here? The underlying cause of the problem is the writing on logical record 0000 of the boot device, either RX50 or RD51D. I have analyzed the exact cause: The DECmates are started in an onboard ROM of which I have disassembled most, if not all of the known variations. (Anyone who believes I missed their machine is encouraged to get in contact with me. I can give a short program to find out which version is in the machine.) In order to be a bootable volume, the ROM checks a small section of data using a designated "validity check" routine. The method consists of reading in the affected area (track 1, sector 1 of the RX50 in drive zero, or record 0000 of the startup volume) and checking a few bytes for a specific pattern. If the test passes, the volume is bootable, else we see the all-too-familiar giant blinking floppy on the screen. The key to the problem is that the ROM checks a few BYTES, NOT WORDS. OS/8 handlers operate in 12-bit word mode, not 8-bit byte mode. This is a rather curious quirk of the design, since the bootstrap is always accomplished in 12-bit mode! (I guess someone felt it unreasonable to write on the disk the way you intend to read it :-).) The problem is that when you write on the disk in 12-bit mode (even using the "same" data that was there beforehand), you selectively destroy data relative to subsequent 8-bit mode usage. This is not a new phenomena, as many -8 peripherals work this way, such as RX01 and RX02. The RX50 and RD51D aren't any different, except in the particular way the 8-bit-only data is destroyed: RX01/02's written in 12-bit mode destroy the last 1/4 of the sector only. Whether accessed in 8-bit or 12-bit mode, the first 3/4 of the sector is unmodified when written back. (If the RX50 worked this way, the problem wouldn't exist :-).) The RX50 and RD51D work identically to each other, but differently from the RX01/02. In these devices, each 12-bit word occupies two 8-bit bytes, thus destroying 1/4 of the bits in each byte pair. The validity test consists of the following algorithm: Reading the sector in, using 8-bit mode, we can number the bytes as Byte[0] through Byte[511]. The first test performed is: Byte[0]-Byte[1] = 000 Failing this test the volume is non-bootable. On OS/278 volumes, these bytes are always 000 before and after 12-bit writing and aren't problematic. The second test is: Byte[3] = 000 Failing this test the volume is non-bootable. In OS/278 volumes this byte is also 000 before and after 12-bit writing and isn't problematic either. The third test is more complicated: Index := Byte[2]*2+2 Index will be calculated as 06 as a result of the fact that Byte[2]'s contents is 002 both before and after 12-bit writing. This isn't problematic YET: Byte[Index] AND Byte[Index+1] AND 8 = 8 Assuming these bytes are read into 12-bit memory right-justified, what's being demanded is that these two bytes are 0010 under a mask of 0010. In the OS/278 boot record, they are both 0010 before and after 12-bit writing, so there isn't a problem YET: Byte[Index]+Byte[Index+1]+Byte[Index+2]+Byte[Index+3] = 255 Again assuming right-justified 12-bit data, what's being demanded is that the sum of the four bytes is 0377 under a mask of 0377. This is CHANGED by 12-bit writing. The "before" byte values (in octal) are: 0010 0010 0011 0346 The "after" byte values are: 0010 0010 0011 0006 One of them was destroyed thus making the volume non-bootable. There is a minor complication of test 3: if any part of it fails, calculate: Index := Index-2 Then repeat all of test 3. If it fails the second time, the device is non-bootable. For RX50's, the four affected bytes are located at offset 004-007 while the RD51D bytes are at offset 006-011. The test is designed to pass either case normally. The 12-bit mode writing destroys the same relative byte in the same manner regardless of device. Other non-tested bytes are apparently "reserved" and contain mostly all zeroes, except for one byte containing 0010. All of them are unchanged by 12-bit writing. The underlying format for 12-bit write is as follows: The first of two bytes is unaffected and represents the low-order 8 bits of the 12-bit word. The second byte consists of 4 zero bits followed by the original high-order 4 bits of the 12-bit word stored in the low-order 4 bits of the 8-bit byte. Thus the 0346 byte is reduced to 0006 by the 12-bit write that destroys the boot block. This code is in every DECmate II and DECmate III ROM version I have disassembled (5 total as of this writing). So how do we fix it? This is the stickier part of the problem. I need some user information to confirm the magnitude of the problem "outside" of the DECmate. One of my goals is to prevent loss of any avenue of transmission of DECmate media, especially if avoidable. The apparent problem stems from DEC's attempt to "standardize" on just what boot-volume headers look like. The 12 bytes "reserved" in the DECmate boot-block header apparently "conform" to a DEC-wide specification, presumably with arbitrary assignment according to some "master list" somewhere. For example, it is my understanding that a Micro-11 equipped with RX50 can copy DECmate-specific RX50's completely (under RT-11 at least) because the RT-11 RX driver recognizes the DECmate's "signature" as requiring the copying of track 0. (RX01 and RX02 avoid referencing track 0, while DECmates require it to be copied for boot purposes. The "slushware" partially resides on track 0.) The "short" fix involves changing the signature bytes to a form immune to 12-bit mode writing. There are several possible variations that will work on the DECmate, but I need some good information about just what "foreign" systems require for DECmate recognition of RX50. It is likely that this method is acceptable for hard-disk bootable volumes, which aren't likely to "travel" too far from the DECmate physical box :-). It is also possible to write an "export" utility in 8-bit mode that resets the bytes to their original state for use on the foreign systems, but this requires conscious effort on the part of the user. (Note also that the export utility would recover "damaged" RX50's and/or RD51D volumes if applied to the current deficient OS/278 system.) The "long" fix involves a roundabout process: There is no hope to modify the system handler directly to cause it to write record 0000 in 8-bit mode from 12-bit data, as this requires among other things a buffer to place the data in, or at least a lot of quirky code. OS/8 handlers are tight enough as it is. However, since this is a DECmate-specific problem, there may be a DECmate-specific solution: The DECmate supports executive "panel requests" to perform a variety of functions. I am currently disassembling a copy of version 422 of the "official" release of the slushware. (I believe this is the stable final version; anyone got a newer one? Please contact me if so. I will eventually post all older ones I have as well.) Version 422 supports certain "new" features over prior versions, but apparently all versions have a few bugs, especially in the VT-220 emulator code. A newer still release is warranted, and I am committed to (eventually) accomplishing this for these sundry purposes. In the process of modifying the slushware, it may not be possible to easily incorporate an additional panel request feature, but it's probably accomplishable. This would be a panel request to "fix" record zero of the current boot volume by applying the standard signature to it in 8-bit mode. While there is really quite a lot of free memory in the panel area, there is a limited amount of LOADABLE memory from the boot device. I believe that the current code is almost at the upper limit of load size. There may be two ways to get more load space back: 1) There may be a spare sector on the slushware data area. It could be used to load more code. If I can make the slushware "smart" enough to load the extra sector, this would provide ample working space to implement the proposed changes. (This is not confirmed information; until I finish disassembling the slushware, I can't vouch for this with any certainty.) 2) There exists a semi-obsolescent routine within the slushware that is large enough to provide the needed code space for the proposed change. This is what the current routine (which may be expendable) is provided for: Early versions of the DECmate II do not support a hard disk. Some of this may involve hardware ECO's, but every machine I have ever seen either works just fine, or requires a ROM upgrade only. (Contact me for information on how to tell what version you have. If you already have a hard disk, you know this doesn't apply to you :-).) (However, without a lot of rewiring, the GRAPHICS OPTION can't function in these early machines!) These early ROMs have several other problems besides inability to support a hard disk. Apparently, there was a design change to the written format of the slushware code space. One sector is always written in 12-bit mode; the other sectors are all written in 12-bit mode only in some early slushware revisions; most versions have the other sectors written in 8-bit mode. The use of 8-bit mode makes the rest of the slushware code capable of being 1/3 longer than the 12-bit version. (Most recent versions are definitely over the 12-bit load limit, and thus are written out in 8-bit mode.) These early ROMs are unaware of the format change, and proceed to load in all of the sectors in 12-bit mode! The referenced routine checks to see if the load was accomplished in 8-bit mode or 12-bit mode. (The routine itself resides in the first sector that is ALWAYS read in 12-bit mode. There is a mode flag that newer ROM versions set to indicate their awareness of the variant load formats and the proper use of 8-bit mode loading.) If the referenced routine finds that the rest of the load is uselessly accomplished in 12-bit mode, it proceeds to RELOAD all of the other sectors in 8-bit mode, using coding "lifted" from the newer ROM revisions. (These RX50-based systems take a REAL long time for all of this to happen, about twice as long as any newer version :-).) After all of this "fixup" is accomplished, the code space lies dormant, i.e., is once-only. Replacing the routines with the designated boot-volume fixing code would render a newer slushware release incompatible with these early ROM machines. (Note: these machines were SUPPOSED to be factory-recalled and upgraded for free. I have already encountered two of them with the old ROMs still in them, as well as the lack of the graphics-required hardware changes. I can provide replacement ROMs to interested parties who contact me through the mail, etc.) Additionally, these older ROM versions don't completely function: There are supposed to be executive calls to simulate HALT, call SETUP, boot an RX50, etc. In addition, should the machine actually halt, the HALT panel is required to handle it properly. Any attempt to use any of these functions on machines controlled by the old ROMs causes the same unexpected result: you are put into the SETUP screen. (For one of the actions, this is actually correct, namely the CALL SETUP function request, but a surprising alternative for all others :-).) Further, recent slushware versions allow enabling the COMPOSE CHARACTER key, but only if an internal table is present. This early ROM version lacks the table as well :-(. So, there is a clear mandate to upgrade the ROMs on these older machines, but if this overall method is chosen to solve the original boot-volume problem, then the unmodified machines are "locked out" from the improvments. It is still too early to determine if this admittedly drastic action is the only method available to accomplish the "long" form of the fix. Hopefully, the spare sector method will be available. However, changes affecting the terminal emulator could require additional space as well. It would be helpful to have the slushware be self-contained for all functions, especially since the terminal emulator is used for all software systems on the DECmate, NOT just OS/278. (I do expect to "bum" some words out of the existing code as well :-).) If the "short" form of the fix is acceptable, I can publish it. The current one I use involves making a one-word change with FUTIL to either RX50 or RD51D. (Different changes, but still one word each.) Perhaps some -11/VAX experts can give ideas for a suitable change "palatable" to all systems. If an export utility is written, its use obviates this problem (as long as it's used :-).) Please help me get a consensus view on this problem. The sooner I solve it, the faster I can get back to other more "conventional" problems like device 03/04 console incompatibilites, etc. as well as the derivative results of this work such as OS/8 V5 or another release of Kermit-12, etc. cjl (lasner@watsun.cc.columbia.edu) Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Mon, 30 Mar 1992 15:42:11 -0500 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Mon, 30 Mar 1992 15:42:08 -0500 Received: from cloyd.cs.cornell.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08426; Mon, 30 Mar 92 15:08:51 EST Received: from ELLI.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.65/I-1.98P) id AA06058; Mon, 30 Mar 92 14:51:31 -0500 Date: Mon, 30 Mar 92 14:51:31 -0500 From: chapman@cs.cornell.edu (Richard Chapman) Message-Id: <9203301951.AA23522@elli.cs.cornell.edu> Received: by elli.cs.cornell.edu (5.65/N-0.12) id AA23522; Mon, 30 Mar 92 14:51:29 -0500 To: pdp8-lovers@ai.mit.edu Date: Mon, 30 Mar 92 14:51:31 -0500 From: chapman@cs.cornell.edu (Richard Chapman) To: pdp8-lovers@ai.mit.edu Thanks to the generous provision of drawings and maintenance manuals by Val Fucich, my pdp-8/L now seems to be running properly (I found two out-of-place flip chips). Future plans include rounding up some peripherals, extra memory, etc. For now, I have the base cpu with 4k core connected to a tty-33. I have no pdp-8 software except what I hand assemble. What I wonder is -- is there a way to get software over the net? Here is my plan: I have the RIM loader. Can someone send me a file with the BIN loader in RIM format (in any format you like -- I'll write code to punch a paper tape from your file by hooking up a tty with punch to an rs232 port). Then I can toggle in the RIM loader on the pdp8, load the BIN loader, then load any BIN-format files I can get my hands on, either by punching tape or letting the PC or workstation emulate a tty's tape reader. 1) What about a cross-assembler I can run on my unix workstation or PC? (any cross-compilers out there?). Again, I can convert output from the cross-assembler to BIN format, hook up the PC to the -8 and download if I can get the BIN loader. If a cross-assembler goesn't exist, I will consider writing one that compiles under gcc, say, maybe based on gas. Maybe even patch gcc itself to output pdp-8 code (this has been done for pdp-11 already). What does anyone think of this? The only pdp-8 software I am aware of that is available over the net that I know of is kermit, which I don't think is does me any good at the moment (later...). Of course, as always, I'll be happy to pay anyone for their trouble who is willing to mail me paper tape (a couple of kind souls did this when I was getting my first pdp-11 up and running :-)), or I'll come to pick things up within a few hours drive of Ithaca, NY or Boston. Thanks a bunch, Richard Chapman