From cjl@maestro.com Thu Nov 3 17:03:59 1994 Received: from relay1.UU.NET by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AB02178; Tue, 1 Nov 94 14:51:07 EST Received: from SunSITE.Unc.EDU by relay1.UU.NET with SMTP id QQxoat24830; Mon, 31 Oct 1994 15:56:44 -0500 Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11205; Mon, 31 Oct 1994 15:56:20 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04694 (5.65c+CU/IDA-1.4.4/HLK for ); Mon, 31 Oct 1994 15:55:56 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA06657 (5.65c+CU/IDA-1.4.4/HLK for ); Mon, 31 Oct 1994 15:55:46 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA10438; Mon, 31 Oct 94 15:35:28 EST 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 AA10431; Mon, 31 Oct 94 15:35:24 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Mon, 31 Oct 1994 14:35:18 -0600 id OAA27248 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Mon, 31 Oct 94 14:33:35 CST id AA02749 Date: Mon, 31 Oct 94 14:33:35 CST From: "Douglas W. Jones" Message-Id: <9410312033.AA02749@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: the RX01 saga, continued It appears that the RX01 disk image I got makes a lot of sense and is almost certainly bootable. I've looked at the postmortum contents of memory after I try to boot from the disk, and I find that the bootstrap did quite a bit before things died. Specifically, it loaded: 00002-00047 -- more bootstrap code, from sector 1 track 1 On finishing loading this much, the newly loaded code takes over control and uses what's left of the bootstrap to load: 17646-17677 -- the rest of sector 1 track 1 17700-17777 -- from other sectors 07600-07777 -- from other sectors After it loads this much, it does an indirect JMS through 00002 to 07577 (why didn't it just jump to 07600? The return address seems to serve no purpose here!) The code in 07577 does more disk I/O, until an SER instruction right after an LCD instruction fails to skip, causing it to do an error return to a halt instruction. The LCD that failed was using the command 7450 (actually, an SNA instruction!) Because of unused bits in the command register, the pattern 7440 is all ignored bits. The bit that gets used (0010) makes this an unused function on the RX01. (Set Density on the RX01). Now, I've got to figure out what my emulator does with this, probably the wrong thing! Doug Jones jones@cs.uiowa.edu From cjl@maestro.com Thu Nov 3 18:03:21 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA01581; Wed, 2 Nov 94 11:19:20 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA16698; Wed, 2 Nov 1994 11:19:44 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14027 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 2 Nov 1994 11:19:19 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA11301 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 2 Nov 1994 11:19:05 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AB28810; Wed, 2 Nov 94 10:55:28 EST 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 AA28805; Wed, 2 Nov 94 10:55:25 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Wed, 2 Nov 1994 09:55:23 -0600 id JAA02864 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Wed, 2 Nov 94 09:55:23 CST id AA04365 Date: Wed, 2 Nov 94 09:55:23 CST From: "Douglas W. Jones" Message-Id: <9411021555.AA04365@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: RX01 documentation errors In the process of debugging my emulator, I've found two small errors in the RX8/RX11 Floppy Disk System Maintenance Manual, EK-RX01-MM-002 (Dec 1976) In section 4.4 (page 4-7) and 4.4.5 (page 4-9). The function code 100 is indeed used and it has a well defined function. That function is a somewhat complex Noop; specifically, function 100 is very similar to function 101 (read status): RXES is moved to the interface register and the Done flag is set. The difference is that RXES does more, checking to see if the selected drive is up to speed. In section 5.2.5, figure 5-14 (flowchart on foldout page 5-26). The label CLRID [NOOP] should be inserted to the right of beside the RDSTAT label. This label is branched to when the poorly documented function 100 is decoded. The arrow from CLRID should go almost 3/4 of the way down the side of the figure and join the flow of RDSTAT right after the call to the CHKRDY subroutine. I found this because the disk driver for the RX01 that is pulled in by the bootstrap uses function 100 on the RX01. I had to read the microcode for the RX01 controller in order to figure out what was supposed to happen. Doug Jones jones@cs.uiowa.edu From cjl@maestro.com Thu Nov 3 18:04:36 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA01581; Wed, 2 Nov 94 11:19:20 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA16698; Wed, 2 Nov 1994 11:19:44 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14027 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 2 Nov 1994 11:19:19 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA11301 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 2 Nov 1994 11:19:05 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AB28810; Wed, 2 Nov 94 10:55:28 EST 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 AA28805; Wed, 2 Nov 94 10:55:25 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Wed, 2 Nov 1994 09:55:23 -0600 id JAA02864 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Wed, 2 Nov 94 09:55:23 CST id AA04365 Date: Wed, 2 Nov 94 09:55:23 CST From: "Douglas W. Jones" Message-Id: <9411021555.AA04365@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: RX01 documentation errors In the process of debugging my emulator, I've found two small errors in the RX8/RX11 Floppy Disk System Maintenance Manual, EK-RX01-MM-002 (Dec 1976) In section 4.4 (page 4-7) and 4.4.5 (page 4-9). The function code 100 is indeed used and it has a well defined function. That function is a somewhat complex Noop; specifically, function 100 is very similar to function 101 (read status): RXES is moved to the interface register and the Done flag is set. The difference is that RXES does more, checking to see if the selected drive is up to speed. In section 5.2.5, figure 5-14 (flowchart on foldout page 5-26). The label CLRID [NOOP] should be inserted to the right of beside the RDSTAT label. This label is branched to when the poorly documented function 100 is decoded. The arrow from CLRID should go almost 3/4 of the way down the side of the figure and join the flow of RDSTAT right after the call to the CHKRDY subroutine. I found this because the disk driver for the RX01 that is pulled in by the bootstrap uses function 100 on the RX01. I had to read the microcode for the RX01 controller in order to figure out what was supposed to happen. Doug Jones jones@cs.uiowa.edu From cjl@maestro.com Thu Nov 3 18:36:53 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA07720; Wed, 2 Nov 94 15:28:00 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01812; Wed, 2 Nov 1994 15:28:22 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05070 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 2 Nov 1994 15:28:04 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA02555 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 2 Nov 1994 15:27:57 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA15494; Wed, 2 Nov 94 15:11:24 EST 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 AB15488; Wed, 2 Nov 94 15:11:16 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Wed, 2 Nov 1994 14:11:10 -0600 id OAA11718 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Wed, 2 Nov 94 14:11:10 CST id AA04552 Date: Wed, 2 Nov 94 14:11:10 CST From: "Douglas W. Jones" Message-Id: <9411022011.AA04552@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: another RX01 documentation error There's another error in the RX8/RX11 Floppy Disk System Maintenance Manual that I forgot to mention in my previous post on such errors: On page 4-5, Figure 4-5, documenting the RXSA Format (RX8E version) As shown 00 01 02 03 04 05 06 07 08 09 10 11 | | | | |0 |0 |0 | | | | | | |__|__|__|__|__|__|__|__|__|__|__|__| \___________/ \______________/ not used 1-32(8) Reality 00 01 02 03 04 05 06 07 08 09 10 11 | | | | | |0 |0 | | | | | | |__|__|__|__|__|__|__|__|__|__|__|__| \______________/ \______________/ not used 1-32(8) This is clearly documented in the flowcharts of the microcode (and in the controller microcode itself). 8 bits are transferred from the interface buffer to the RX01 controller, but then the microcode deliberately masks out the high bit. See figure 5-16 on page 5-20, the second box down from continuation A in the flowchart. and in the microcode, the block of code following PUTSEC (locations 0145-0157 in the 9-FEB-76 version of the microcode). I found this because the puzzling PDP-8 RX01 code I got from a diskette image that I still can't boot actually sets bit 4, and this caused one of the errors I've been working my way around. This error also shows up in Figure 3-3 on page 3-3, documenting the RXSA Format as seen by a PDP-11 (just add 4 more unused bits on the left side of both of the above illustrations, then renumber the bits from right to left. Checking in the RX01/RX02 Pocket Service Guide, EK RX012-PS-002, Sept 1981, this error is still present! See Figure 1-5, page 15, where the sector address register is shown, in PDP-8 format, and Figure 1-7, page 17, where it's given in PDP-11 format. This will matter for those developing RX01 emulators. It shouldn't matter to those writing RX01 applications code (except that keeping bit 4 equal to zero does limit the selection of "wild constants" you can use in packing your code). I suspect that the extra microcode needed to ignore this bit was inserted specifically to allowed someone to squeeze one word out of an RX01 device driver by using an otherwise unusable instruction as a constant. Doug Jones jones@cs.uiowa.edu From cjl@maestro.com Thu Nov 3 18:39:50 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA14187; Thu, 3 Nov 94 18:18:20 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05489; Thu, 3 Nov 1994 18:16:18 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA01255 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 3 Nov 1994 18:15:09 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA29912 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 3 Nov 1994 18:14:47 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA05754; Thu, 3 Nov 94 17:47:19 EST 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 AA05706; Thu, 3 Nov 94 17:46:22 EST Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP id QQxomd17920; Thu, 3 Nov 1994 17:46:12 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA13464; Thu, 3 Nov 94 17:45:34 EST Date: Thu, 3 Nov 1994 17:45:33 -0500 (EST) From: Charles Lasner Subject: Re: the RX01 saga, continued To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9410312033.AA02749@pyrite.cs.uiowa.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 31 Oct 1994, Douglas W. Jones wrote: > It appears that the RX01 disk image I got makes a lot of sense and is > almost certainly bootable. I've looked at the postmortum contents of > memory after I try to boot from the disk, and I find that the bootstrap > did quite a bit before things died. Specifically, it loaded: > > 00002-00047 -- more bootstrap code, from sector 1 track 1 Absolutely the correct thing. > > On finishing loading this much, the newly loaded code takes over control > and uses what's left of the bootstrap to load: > > 17646-17677 -- the rest of sector 1 track 1 Yes, that much is what's left in track 1, sector 1, and should land in that relative position within 17600-17777. > > 17700-17777 -- from other sectors Correct, but from which sector? > > 07600-07777 -- from other sectors This is the image of the system handler. In OS/8, the system handler is often too lame to help get itself up. The RX01 case is no exception! The system handler always resides in the second half of logical record 0000. 0000 is in turn track 1, sector 1,3,5,7 on an RX01, thus this better be sector 5 and 7. Note: The system handler could be a two-page type in which case, the translation is relative to record 0066! In any case, the boot code from track 1, sector 1 has to know what to do either way! Versions of the RX01 handler have appeared that do it either way, etc. The older ones have problems, but run in 8K. All of the newer ones assume a 12K minimum machine, etc. > > After it loads this much, it does an indirect JMS through 00002 to 07577 > (why didn't it just jump to 07600? The return address seems to serve no > purpose here!) The code in 07577 does more disk I/O, until an SER > instruction right after an LCD instruction fails to skip, causing it > to do an error return to a halt instruction. The code is tight, and there was a handy 7600-1 constant there! Thus, JMS I [7577] is as good as JMP I [7600] since we really don't care about the contents of 7577. However, either of these cases is piss-poor for another reason: All devices when booting are in a "cross-your-fingers" mode until the handler seems safely completely up, etc. It's good practice to write-protect the media until this is completely true. As a custom CSS-implemented feature, RX01 supports write-protected media. Additionally, the DSD-210 not only supports true media formatting, it also supports write-protected media *and* also write-protect switches on the front panel of each drive. To use this specific boot implementation means that an error is a certainty unless the media is allowed to be written on erroneously during the boot process, etc. The user must determine if the HLT from that error is the appropriate situation, then press continue to resume the rest of the boot-up process, *then* write-enable the drives, etc. Had the process been defined to instead be initiated by a JMP I [7605] the drives could remain write-protected, etc. Other DEC devices (and user-supported handlers) have done this aspect correctly to avoid this, but the RX01 is such a lame interface that many shortcuts have to be taken, etc. > > The LCD that failed was using the command 7450 (actually, an SNA > instruction!) Because of unused bits in the command register, the > pattern 7440 is all ignored bits. The bit that gets used (0010) > makes this an unused function on the RX01. (Set Density on the RX01). Note that tight code leads to tight results! That code will flunk on a DSD-210 that supports more than two drives because it accidentally sets the extended unit bit! In doing so, an error is possible unless the drive happens to be ready. I think you have misunderstood the use of function 4 of the RX01 and RX02 (and RX03!): On an actual RX01, the function is a true NOP in the sense that it cannot get an error assuming the drive is ready and selected. It meerly sets the done flag and doesn't get an error, and does it fairly quickly. The handler convention is to enter assuming to perform SDN which better skip, else the handler hangs. This is required because the drive could be in the midst of a self-test which takes up to 3 seconds to complete, *then* the done flag is set. Usually the done flag is already set, so the handler proceeds quickly to process the latest call, etc. When any call is completed, the function 4 is performed (xx10 in the AC) and the done flag is *not* tested, thus it is definite that it will raise. Even in the DSD-210 case, the consequence of the raising of the error flag is that an additional error-recovery cycle will occur extraneously, but otherwise harmlessly (too long a boot time, etc.). The main point is that the code sets the done flag regardless so the handler will work correctly, etc. On the RX02, this is unacceptable. Function 4 means to SET MEDIA DENSITY and is used in conjunction with setting the double-density bit where appropriate, etc. (setting bit[3]). Additionally, when the transfer flag raises (which never happens on an RX01 in this situation!) you are obliged to perform XDR with the AC = 111 (ASCII for "I") else you get an error. This sequence prevents RX01 code from working on purpose! Additionally, the RX02 supports an "RX01 compatibility" mode where function 4 again becomes a NOP, allowing most RX01 code to work there, etc. However, all RX02 systems set bit[8] of the status register which is a meaningless and misleading piece of misinformation. In spite of what the RX02 manual says, the following is the *ACCURATE* meaning of this bit: If bit[8] is set in a read-status situation on an actual RX01, then it means that the drive does support the write-lock status that could lead to a write-protect error when writing is attempted on write-locked media. This is documented in the RX01/RX02 pocket service guide. However, the bit sets whenever a write-protect-supporting drive is not ready also! The user's code is responsible for determining if the error is a not-ready versus a write-protect but ready situation if applicable. Merely reading that the bit is set is not an error in itself! On an RX02, the bit is permanently set! Additionally, setting the emulation mode where function 4 becomes a NOP instead of set-media-density doesn't change the bit[8] setting! Thus, despite the pretty language in the RX02 manual, code should *NEVER* be written that depends on this bit being set. The bit is basically meaningless information since its interpretation depends on the certain knowledge of the hardware. IF you are emulating an RX01, you can opt to never set the bit, but if you want to support write-protect, you should support it! However, certain known defective programs will not work correctly under some conditions. A notable example is certain versions of RTFLOP, which will misinterpret an RX01 with a write-lock implementation and a write-protected condition *OR* a not-ready condition erroneously as an RX02 internally, and enable code that will always hang on the flag that never raises! Manual restart is the only way to clear the condition, etc. In some newer handlers, the use of function 4 has been replaced with the read-error-register function. This function always raises the done flag quickly regardless of hardware type, and additionally cannot get an error on a ready drive. The error code returned after a successful previous function is always 000, and additionally need not be read to complete the operation, thus with impunity, the handler can raise the done flag merely by performing a drive 0 single density {either 8-bit or 12-bit} read-error-register function and exiting without testing. The done flag will quickly raise which will then allow the smooth operation of the next caller, etc. In OS/278 V2, the implementors chose to buck all prevailing convention! All user-written handlers are incompatible with the standard OS/278 handlers, since the convention is now to ensure the done flag is clear when exiting! Finding the done flag set is considered an error thus causing an error-recovery cycle! Additionally, this means that after a power-on or CAF or power-clear reset, there is always an extraneous error-recovery cycle! P?S/8 solves the entire problem by supporting a more tolerant handler scheme: The handler assumes that the flag *might* be coming up. Initial code is executed to ensure that the flag will come up using the following trick: 1) Execute SDN;NOP. This will clear the done flag if currently up. 2) Execute a read-error-register function as described above. If the drive was idle, then the function is executed leading to the done flag coming up soon. If the drive was in the midst of a previous function, the worst-case being a 3 second self-test cycle, then this latest LCD command load for the read-error-register is ignored! Either way, the done flag will come up, albeit in as much as three seconds. The rest proceeds as in the classic OS/8 case, namely to then wait for SDN;JMP .-1 to skip which will definitely eventually occur. After the central code of the handler does its business, the handler exits with the read-error-register function setting the done flag without testing for it, etc. This accomodates all of the user-written handler philosophies, etc. > > Now, I've got to figure out what my emulator does with this, probably > the wrong thing! Unless it sets done and not error and does so quickly, it's the wrong thing! > Doug Jones > jones@cs.uiowa.edu > cjl From cjl@maestro.com Fri Nov 4 22:16:53 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA15409; Thu, 3 Nov 94 19:07:13 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA07737; Thu, 3 Nov 1994 19:00:23 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04407 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 3 Nov 1994 19:00:13 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA08944 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 3 Nov 1994 19:00:02 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA08792; Thu, 3 Nov 94 18:38:35 EST Return-Path: Received: from relay4.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 AA08753; Thu, 3 Nov 94 18:37:27 EST Received: from maestro.Maestro.COM by relay4.UU.NET with SMTP id QQxomg22441; Thu, 3 Nov 1994 18:37:26 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA14495; Thu, 3 Nov 94 18:36:49 EST Date: Thu, 3 Nov 1994 18:36:49 -0500 (EST) From: Charles Lasner Subject: Re: another RX01 documentation error To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9411022011.AA04552@pyrite.cs.uiowa.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Regarding the RXSA format: I believe it's documented somewhere that the sector value is a seven-bit value, thus allowing an 8th hi-bit to be ignorable. And yes, some 8-programmers did use code with the bit set. Note also, that on the DSD-210, you set the sector to 152 to initiate a format track operation, and on newer DSD drives (never on the -8, only the -11) you use 154 and 155 to get sd or dd, etc. cjl From cjl@maestro.com Sat Nov 5 10:03:49 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA02809; Sat, 5 Nov 94 02:41:13 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA09533; Sat, 5 Nov 1994 02:41:48 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA12150 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 5 Nov 1994 02:41:44 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA04180 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 5 Nov 1994 02:41:40 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA10585; Wed, 26 Oct 94 13:04:55 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 AA10560; Wed, 26 Oct 94 13:04:45 EDT Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41); id AA20418; Wed, 26 Oct 94 13:04:27 EDT for PDP8-LOVERS@AI.MIT.EDU Date: Wed, 26 Oct 94 13:04:24 EDT From: John_Wilson@mts.rpi.edu To: PDP8-LOVERS@ai.mit.edu Message-Id: <4599006@MTS.RPI.EDU> Subject: Re: RX01 boot fun cjl wrote (my mailer doesn't do attributions): >Track 1, sector 1 is the only one that they will agree on. The rest are >hopelessly wrong. [...] >The -11's use a mapped format not used on the -8. You have to remap the >data before writing it. Normally so (with the 252928-byte file that's easy to make the obvious way), but not in this case since the 256256-byte file was read sector-by-sector with .SPFUN and honestly IS a straight binary image of the disk. The usual PDP-11 DX/DY handlers skip track 0 when accessing the floppy in block mode (the usual PDP-8 handlers do too right?) so the image file is a different size, an easy tipoff to tell the emulator whether there's interleave to be undone. E11 handles either. >BTW, I have a question: What is the RT-11 interleave and stagger scheme >for RX02 and RX50? (I guess that's two questions!) RX02 -- same as RX01, just a different sector size. RX50 -- 2:1 interleave, no skew, so sector order is 1,3,5,7,9.,2,4,6,8.,10. regardless of track number. The disk starts on track 1 just like DX/DY, my understanding is that it wraps around after track 79 and track 0 is the last logical track on the disk. John Wilson From cjl@maestro.com Sat Nov 5 11:09:06 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA09462; Sat, 5 Nov 94 10:21:30 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA22628; Sat, 5 Nov 1994 10:22:05 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA25882 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 5 Nov 1994 10:22:02 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA07153 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 5 Nov 1994 10:21:59 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA00249; Sat, 5 Nov 94 10:04:39 EST Return-Path: Received: from relay3.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 AA00245; Sat, 5 Nov 94 10:04:27 EST Received: from maestro.Maestro.COM by relay3.UU.NET with SMTP id QQxosi20424; Sat, 5 Nov 1994 10:04:23 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA09032; Sat, 5 Nov 94 10:03:43 EST Date: Sat, 5 Nov 1994 10:03:42 -0500 (EST) From: Charles Lasner Subject: Re: RX01 boot fun To: John_Wilson@mts.rpi.edu Cc: PDP8-LOVERS@ai.mit.edu In-Reply-To: <4599006@MTS.RPI.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Oct 1994 John_Wilson@mts.rpi.edu wrote: > cjl wrote (my mailer doesn't do attributions): > >Track 1, sector 1 is the only one that they will agree on. The rest are > >hopelessly wrong. > [...] > >The -11's use a mapped format not used on the -8. You have to remap the > >data before writing it. > > Normally so (with the 252928-byte file that's easy to make the obvious way), > but not in this case since the 256256-byte file was read sector-by-sector > with .SPFUN and honestly IS a straight binary image of the disk. The usual > PDP-11 DX/DY handlers skip track 0 when accessing the floppy in block mode > (the usual PDP-8 handlers do too right?) so the image file is a different > size, an easy tipoff to tell the emulator whether there's interleave to be > undone. E11 handles either. OK. Clearly not the -11 norm, but the only way everyone agrees! The -11 norm is to ignore track 0, start at track 1. Start at sector 1, do all odd sectors, then start at sector 2 and do all even sectors. Then add a stagger factor of 6 so on track 2 the next sector is 7, do all odds wrapping from 25 back to 1,3, etc. then start at 8 wrapping from 26 back to 2,4, etc. The idea here is that as you seek up the device, you have to allow next-track transfers time for the head to move. By asking for a sector 6 up the track, you won't have to pay the go-all-the-way-around penalty of strictly asking for sector 1 again, etc. However, the RX01 -8 format didn't do it that way, so each track costs you a latency overhead. I have used an experimental handler for the -8 that does it -11 style to do an image copy, and it's quite noticeable an improvement in transfer speed! However, it costs you more code, a situation that causes other tradeoffs in terms of OS/8 handlers, which are already pushed beyond their limits in the maximum allowed two-page space. P?S/8 was designed to obviate this problem since the system handler is allowed to be 9 pages long, although some other functions are supported that would somewhat take away from this space. Non-system handlers can be an entire field if required! Regardless of this, the P?S/8 non-system handler is 3 pages long without compromise. It has all of the following characteristics: 1) Is page and FIELD relocatable. OS/8 handlers must be loaded into field 0. 2) The media is addressed to the nearest PDP-8-page-sized block, not OS/8's logical record which is twice that size. This size was originally chosen for the benefit of DECtapes, where (neglecting the pesky 129th word) the logical and physical sizes are the same, etc. 3) Runs with complete error recovery. Most RX code on all machines uses lame error recovery, in part because RX01 code is often at a loss as to how to proceed, and it's all to easy to just do the error reset operation which initiates a self-test among other things. Such attempts at error recovery take too long, and often are the incorrect action to take, leading to *increased* errors. (Case in point: dirt spot on the media causes a read parity error. The proper action is to leave the head down and reread the sector until eventually the dirt is dislodged by the head and an error-free read occurs. "Clearing the world" causes a recalibrate on the drives, thus the dirt spot is never honed over, just a lot of wasted head motion and time. I have used P?S/8 BLKCPY to transfer an RX01 that OS/8 literally couldn't recover due to this aspect of design, etc.) Note that complete error recovery also depends on understanding the differences between all of the relevant drive configurations. All of the following are properly supported: 1) Simple RX8E connected to a pair of RX01 or RX02 (or RX03!). RX03 double-sided SD diskettes are supported as in the OS/78 V3 RXNS handler. 2) DSD-210 unit extensions for up to 4 drive units. 3) VT78/VT278 (DM I) drive extensions for up to 4 drive units. 4) RX78 (DM II) interface for up to 4 drive units. In all DEC cases, the drives can be RX01 or RX02 (or RX03!) including mixed pairs. Note that error recovery has to sort out the differences between: 1) True RX01 stock. 2) True RX01 with CSS write-protect implementation. 3) DSD-210 which supports the same write-protect including at the individual drives with override switches. 4) RX02 (and RX03, possibly double-sided!) in normal mode. 5) RX02 in RX01 emulation mode. (And RX03 in RX01 emulation mode!) RX01 and DSD-210 support interface parity error detection. On the RX02, the same status bit is reserved for the RX03 implementation of the fact that the present media is double-sided, not an error! (There is no other way to detect an RX03 over an RX02, and literally no way to realize that it's an RX03 if single-sided media is present. Note that RX03 is in theory a field upgrade of RX02, which was never sold, but was supported on both OS/8 and RT-11, etc.) RX02 and up systems support density-related errors that must be properly interpreted as well, etc. Additionally, high-speed seek algorithms are used to allow the handler to access the disk faster. In OS/8 handlers, simple iterative subtraction to simulate division is used. On higher sectors, this causes a throughput loss, especially on the slow VT78. The P?S/8 method is to use a non-restoring shifting divide similar to the way EAE is implemented. After a small number of iterations there is always a quotient and remainder available (both in the AC at once!). For additional speed, the division method is only used at the beginning of a multi-sector transfer. Additional sector/track calculations are done on a predictor/corrector basis with a startling fast algorithm (about 9 instructions total!). In all PDP-8 RX01 handlers, the basic method is to deal with the 26 sectors in an all odd, then all even way. To implement this two-way interleave, you divide the logical sector not by 26 (the number of sectors on a track) but by 13. The final result is then shifted once to the right to allow the original low-order bit to create the two-way interleave, etc. Calculations are made relative to origin 1 since track 0 is never referenced and sectors are numbered 1-26, not 0-25. Note that on RX78/DM II, drives must be specially selected to be differentiated from RX50. RX50 drives select the same way as RX01/02 are in VT78/VT278 (DM I), namely using AC bit[11] during the SEL (6750) instruction. Uniquely in the DM II situation, AC bit[00] additionally must be set to address the RX78. Note that all RX01/02 code run on the DECmates II and up where the RX78 is *NOT* present will falsely address the RX50. I am open to suggestions as to how to prevent this! The applications where this is needed are: 1) An upgraded version of the P?S/8 RX01 handlers. 2) RTFLOP 3) WPFLOP There is no code space in the OS/8 handlers for any contemplated fix. The other programs have adequate space if what is to be done can be defined. Some useful raw facts towards this endeavor are: 1) If the CPU is an -8/e or better, the SKON instruction can be used to remember whether interrupts were on before the call is made, and then restore the interrupt state later. (P?S/8 handlers can be called with interrupts for other devices enabled, since the only possible interaction is loss of throughput. RX interrupts are disabled.) (OS/8 programs could have the interrupt on if symbiont tasks are running such as the OS/78 SPOOLR program, etc.) This allows a program to check with impunity for the relevant clock or other peripherals that sort out which model it is. The usual method for determination of -8/e or better is to use the BSW instruction. Essentially if CLA IAC BSW can set the AC to 0100, the CPU is -8/e or better and SKON is allowed. Once interrupts are disabled properly, tests for the DECmate I clock can be performed to rule that possibility out. (Of course the handlers just work on DECmate I!) If the CPU is an -8/e, but not a 6120, then the RX01 code need not care about drive selection, since at most, the CPU is a 6100 and there are at most one or two drive pairs of RX01/02, never RX50. (Thus, if the CPU is a 6100, then SEL is operational. On -8/e,a systems SEL is ignored.) If the CPU is 6120 then if the clock is DM I style, the drives must be RX01/02(/03!) and RX50 is impossible. If the CPU is 6120 and the clock is DM II,III,III+ style, then if 6707 doesn't clear the AC, the RD51D is not present. If so, then OSR reads back a collection of status bits indicating which plug-in options are present. One bit is shared by either the RX78 or RD51D. If the bit is set and 6707 does clear the AC, the RX78 isn't present. If the bit is set and 6707 doesn't affect the AC, then the RX78 must be present. Since the clock indicates DM II or newer, a panel request can be performed to get back the ROM type. DM III or III+ support a bit not found in the DM II. (It's used by the slushware to do model-dependent video initialization, although I have never found out exactly why they do them differently! It would appear the video hardware is the same, yet there is a DM III and III+ specific variation on some specific points, etc. Anyone know anything about this?) Thus, these machines can be ruled out for RX01/02(/03) support. (Note: DM III+ supports the RD51D, thus 6707 would clear the AC! This guarantees that the RX78 isn't present. Unless you check for the ROM type, DECmate III appears the same as DECmate II. Panel requests are only legal on DECmates, but the ability to retrieve ROM addresses, etc. is only valid on DECmates past DM I. DM I will hang if the call is attempted!) I think the above is a sufficient set of tests to uniquely determine if the RX50 and RX01/02(/03) are both present where both are possible, etc. In all other circumstances, the RX50 is absent allowing conventional means to check for the drives responding as RX type, etc. > > >BTW, I have a question: What is the RT-11 interleave and stagger scheme > >for RX02 and RX50? (I guess that's two questions!) > > RX02 -- same as RX01, just a different sector size. I would have thought so. Yet, in OS/8, a 3:1 interleave is used for RX02. Anyone know why? > RX50 -- 2:1 interleave, no skew, so sector order is 1,3,5,7,9.,2,4,6,8.,10. > regardless of track number. The disk starts on track 1 just like DX/DY, > my understanding is that it wraps around after track 79 and track 0 is the > last logical track on the disk. It would appear that all systems use the RX50 with 2:1 interleave. This means that stock format media causes an intertrack latency! This is fixable using custom sector order on formatting programs such as PC FDFORMAT/TELEDISK. I would have assumed that RT11 handled it better to be consistent with the RX01/02 support! > > John Wilson > cjl From cjl@maestro.com Fri Nov 11 20:19:06 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA19633; Tue, 8 Nov 94 11:47:21 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03689; Tue, 8 Nov 1994 11:47:54 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA18563 (5.65c+CU/IDA-1.4.4/HLK for ); Tue, 8 Nov 1994 11:47:49 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA19274 (5.65c+CU/IDA-1.4.4/HLK for ); Tue, 8 Nov 1994 11:47:44 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA11544; Tue, 8 Nov 94 11:02:26 EST 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 AA11540; Tue, 8 Nov 94 11:02:23 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Tue, 8 Nov 1994 10:02:20 -0600 id KAA25940 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Tue, 8 Nov 94 10:02:19 CST id AA09539 Date: Tue, 8 Nov 94 10:02:19 CST From: "Douglas W. Jones" Message-Id: <9411081602.AA09539@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: Continuing saga, boot from RX01 I've verified with CJL that the RX01 boot code I have loads a good (albeit antique version of the) OS/8 system handler for the RX01. This handler includes startup code to write 8 consecutive pages from core location 00000 to disk record 33 (octal) and then read 8 pages starting at disk record 7 to the same core location. Then, the final step is to jump to 00400 (start of second page). This is promising, but I've done a bit of disassembly of the stuff it pulled in, and it looks wierd: 00400: 5705 JMP I 0505 00505: 1005 In what follows, the code decides whether to do something depending on uninitialized memory in field 1. 01005: 6211 CDF 10 2477 ISZ I 0077 This increments an uninit'd location 5212 JMP L if uninit'd loc was 7777, go to L 01010: 1117 TAD 1117 (it gets the value 7420) 3022 DCA 0022 put it somewhere in page 0 01012: 6201 L, CDF 00 Now go do move What follows is a loop that tries to move 4K words of field 0, including itself. 01013: 1413 BL, TAD I 0013 Location 13 is initially 1076 3414 DCA I 0014 Location 14 is initially 7771 2021 ISZ 0021 Location 21 is initially zero. 5213 JMP BL End up moving a full 4K! Why bother? So how does this terminate? Well, note that it tries to overwrite its loop control variables! M[1077 .. 1104] goes to M[7772 .. 7777] M[1105 .. 1120 goes to M[0000 .. 0013] changes the src addr to 5330 M[5331] goes to M[0014] changes dst addr to an uninitialized value! So, this code goes wild, overwriting random chunks of memory with strange stuff. I think I've got my hands on a random chunk of code that's way out of context. Two possibilities remain. Either my disk image is bad (it was once a bootable disk, but the code pulled in by the boot sequence has been clobbered), or something very obscure is wrong, allowing the boot sequence to bring in the system handler but not allowing the system handler to bring in good stuff. Doug Jones jones@cs.uiowa.edu From cjl@maestro.com Fri Nov 11 20:19:15 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA24056; Tue, 8 Nov 94 14:19:51 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13495; Tue, 8 Nov 1994 14:20:29 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27604 (5.65c+CU/IDA-1.4.4/HLK for ); Tue, 8 Nov 1994 14:20:25 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA17757 (5.65c+CU/IDA-1.4.4/HLK for ); Tue, 8 Nov 1994 14:20:15 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA19798; Tue, 8 Nov 94 13:36:38 EST Return-Path: Received: from frodo.marshall.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 AA19787; Tue, 8 Nov 94 13:36:36 EST Received: from MARSHALL.EDU by MARSHALL.EDU (PMDF V4.3-10 #6427) id <01HJ8LHC8HC08WW28R@MARSHALL.EDU>; Tue, 08 Nov 1994 13:35:06 -0400 (EDT) Date: Tue, 08 Nov 1994 13:35:05 -0400 (EDT) From: Ronald Copley Subject: SUBSCRIBE To: pdp8-lovers@ai.mit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subscription request? -- Informatiks | Ronald Copley, owner | Buying and selling small to medium 1010 Township RD 78W | quantities of used Pyramid, Sun, Scottown OH 45678-9051 | DEC (PDPs) and Data General computer +1.614.643.1340 | equipment. (evenings, please) | -- From cjl@maestro.com Fri Nov 11 20:29:57 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA03186; Thu, 10 Nov 94 12:25:28 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13230; Thu, 10 Nov 1994 12:26:00 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA16599 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 10 Nov 1994 12:25:12 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA29761 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 10 Nov 1994 12:25:07 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA14113; Thu, 10 Nov 94 12:04:42 EST Return-Path: Received: from frodo.marshall.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 AA14107; Thu, 10 Nov 94 12:04:39 EST Received: from MARSHALL.EDU by MARSHALL.EDU (PMDF V4.3-10 #6427) id <01HJBAUWND7W8WW5K8@MARSHALL.EDU>; Thu, 10 Nov 1994 12:03:03 -0400 (EDT) Date: Thu, 10 Nov 1994 12:03:03 -0400 (EDT) From: Ronald Copley Subject: Re: retry -- my RX01 now works In-Reply-To: <9411091750.AA11377@pyrite.cs.uiowa.edu> To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT On Wed, 9 Nov 1994, Douglas W. Jones wrote: > Anyone who wants a copy of my emulator is welcome to take one from > ftp.cs.uiowa.edu:/pub/jones/pdp8/ (get README first to see what's there). > And it works fine. Linux definately needs a -DTERMIOS, a link to the bsd library and a change to #include in ttyaccess.c I need some c source for Mr. Lasner's ENCODE programme, so that I can undo some binaries to run underneath the PDP-8 emulator. Help? -- Informatiks | Ronald Copley, owner | Buying and selling small to medium 1010 Township RD 78W | quantities of used Pyramid, Sun, Scottown OH 45678-9051 | DEC (PDPs) and Data General computer +1.614.643.1340 | equipment. (evenings, please) | -- From cjl@maestro.com Fri Nov 11 21:20:49 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA15954; Thu, 10 Nov 94 19:06:20 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA07128; Thu, 10 Nov 1994 19:06:51 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA13565 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 10 Nov 1994 19:06:40 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA23027 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 10 Nov 1994 19:06:38 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA13017; Tue, 8 Nov 94 11:38:59 EST 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 AA13009; Tue, 8 Nov 94 11:38:54 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Tue, 8 Nov 1994 10:38:52 -0600 id KAA27314 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Tue, 8 Nov 94 10:38:52 CST id AA09584 Date: Tue, 8 Nov 94 10:38:52 CST From: "Douglas W. Jones" Message-Id: <9411081638.AA09584@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: RX01 Boot problems licked! IT WORKS. John Wilson, your disk image is good! CJL, thanks alot for your help! The light dawned just as I pressed the control-D to send out the last bit of E-mail. Here's a transcript of my very first ever OS/8 session: - begin transcript - .R PIP */E USE DIRECT */F USE DIRECT *TTY: 1 HELP .SV 8 36 FILES IN 437 BLOCKS - 1 FREE BLOCKS *^C . .R BOOT / - end transcript - And, I've verified that, with BOOT running, it's safe to power down the emulator, then restart things at 0033 and OS/8 comes up again just fine, still running BOOT, ready for you to hit control C. Now, I guess I've got to put together a proper distribution of my emulator and put it out for public consumption. Doug Jones jones@cs.uiowa.edu From cjl@maestro.com Fri Nov 11 23:08:22 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA01178; Fri, 11 Nov 94 21:37:55 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24687; Fri, 11 Nov 1994 21:38:34 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02752 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 11 Nov 1994 21:38:22 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA29748 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 11 Nov 1994 21:38:15 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA20206; Fri, 11 Nov 94 21:21:31 EST 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 AA20168; Fri, 11 Nov 94 21:21:20 EST Received: from maestro.Maestro.COM by relay1.UU.NET with SMTP id QQxpqf11678; Fri, 11 Nov 1994 21:21:10 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA00695; Fri, 11 Nov 94 21:20:24 EST Date: Fri, 11 Nov 1994 21:20:23 -0500 (EST) From: Charles Lasner Subject: Re: retry -- my RX01 now works To: Ronald Copley Cc: "Douglas W. Jones" , pdp8-lovers@ai.mit.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Nov 1994, Ronald Copley wrote: > I need some c source for Mr. Lasner's ENCODE programme, so that I can > undo some binaries to run underneath the PDP-8 emulator. Help? It's only been done in PDP-8 assembler. Sources are available in the Kermit-12 collection. However, there is also a .doc file available on the file format in the same collection, available at finer PDP-8 archives everywhere, as well as everywhere Kermit isn't sold, but rather given away for free! Please note also, that there is another format supported in the same collection, known as .IPL format. This is actually a variant on binary paper-tape, but with a different agenda: Basically, the format is printable characters with all white space, CR, LF, etc. ignored. The printable characters form loadable PDP-8 half-words (six-bit bytes) with an implied loading address of 0000 ending with a trailer. Leader can contain lower-case letters for commenting on the contents of the file. Any essentially lower-case character also ends the file, thus the trailer is practically any free-form input you want, etc. The purpose is to allow a minimal loader almost as primitive as the original .RIM loader to be used for moving paper-tape binaries around, but allowing the file to be stored as a text file in most file systems, etc. You must supply the loading field, as well as the designated program to accomplish the loading. Kermit-12 includes two example files, one runs in field 1 to load field 0, the other runs in field 0 to load field 1. This allows each to load an unrestricted amount of binary up to an entire field. Note that a shorter load could allow the loader to reside in the same field as the loaded data, or alternatively, the loaded program could be designed to interact with the loader itself! There are versions of BASIC that assume they are being loaded by the standard .BIN loader, and they overlay the loader itself to make the attempt at loading become a self-starting operation. Something similar could be contrived for the .IPL loading operation, etc. In the specific case of Kermit-12, the image of Kermit-12 Version 10g is split into two .IPL files, one being the image of field 0, the other field 1. The two .IPL loaders are used to load the files into memory directly, then exit back to the OS/8 monitor allowing .SAVE commands to be executed to save the memory image, etc. Later, PIP commands can be used to combine the "halves" of the program to form a provisional copy of Kermit-12, which can then be used for a more "trustworthy" download of files, etc. Note that .IPL loading assumes an error-free connection to another serial device, but doesn't require a start/stop protocol such as ^S/^Q because loading is direct to memory only, etc. This allows connections such as connecting a DECmate printer port to a PC com1: port. Using an MS-DOS COPY filename COM1: or similar command allows for an error-free load of a program segment, thus quickly allowing Kermit-12 to become available where no other comm program yet exists, etc. (This method has been successfully used in several sites to acquire Kermit-12, etc.) The only known problem with .IPL loading as the ability to load inadvertently into the wrong field. Kermit-12's parts are field-specific, but files such as FOCAL, 1969 can be loaded into any field, as long as the DF and IF are both started as the loading field, etc. .IPL utilities and ENCODE/DECODE utilities should be made available for as many machines as possible, etc. In the meantime, OS/8 ENBOO and DEBOO handle the Kermit-popular .BOO format that is often used to distribute MS-DOS-type binaries, etc. Using .BOO format, TECO macroes can be exchanged between OS/8 and MS-DOS! Thus, using .BOO format as an intermediary, it is possible to move any arbitrary file format, as long as the transmission path is good enough to not mangle .BOO format, which is not known for being particularly robust, etc. (Basically as lame as uuencode, only with compression, but no checksum.) The best format is ENCODE with its extra-long checksums, white-space ignoring, compression, embedded comment capability including OS/8 and file creation date information, 5-bit character encoding for maximum robustness even through EBCDIC systems, etc. ENCODE will even survive being sent as a WPS document with DX! Thus, we welcome any implementations of these formats on other systems, etc. cjl From cjl@maestro.com Fri Nov 11 23:08:37 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA01297; Fri, 11 Nov 94 21:40:40 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24712; Fri, 11 Nov 1994 21:41:24 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02849 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 11 Nov 1994 21:41:16 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA00179 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 11 Nov 1994 21:41:14 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA20334; Fri, 11 Nov 94 21:29:24 EST 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 AA20329; Fri, 11 Nov 94 21:29:10 EST Received: from maestro.Maestro.COM by relay1.UU.NET with SMTP id QQxpqf12379; Fri, 11 Nov 1994 21:29:08 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA00873; Fri, 11 Nov 94 21:28:22 EST Date: Fri, 11 Nov 1994 21:28:21 -0500 (EST) From: Charles Lasner Subject: Re: RX01 Boot problems licked! To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9411081638.AA09584@pyrite.cs.uiowa.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 8 Nov 1994, Douglas W. Jones wrote: > IT WORKS. John Wilson, your disk image is good! CJL, thanks alot for > your help! The light dawned just as I pressed the control-D to send out > the last bit of E-mail. Here's a transcript of my very first ever OS/8 > session: Not sure what you fixed, but it does make sense! > > - begin transcript - > > .R PIP > */E > USE DIRECT > */F > USE DIRECT > *TTY: USE DIRECT > *^C Yes, the dreaded PIP version where the /E, /F, /L switches were deleted! > > .R DIRECT > *TTY: > > > SYS VOLUME-- 1 > SYS:=RX8E > OS/8 SYSTEM VERSION 3Q > > BUILD .SV 33 PAL8 .SV 19 BCOMP .SV 17 > ABSLDR.SV 5 PIP .SV 11 BLOAD .SV 8 > BITMAP.SV 5 PT8E .BN 1 BRTS .SV 15 > BOOT .SV 5 RESORC.SV 10 EABRTS.BN 24 > CCL .SV 18 RXCOPY.SV 6 RESEQ .BA 6 > CREF .SV 13 SABR .SV 24 ECHO .SV 2 > DIRECT.SV 7 TECO .SV 22 RKLFMT.SV 9 > EDIT .SV 10 BASIC .AF 4 SET .SV 14 > EPIC .SV 14 BASIC .FF 4 BATCH .SV 10 > FBOOT .SV 2 BASIC .SF 4 FUTIL .SV 26 > FOTP .SV 8 BASIC .SV 9 IDS .SV 5 > HELP .HL 55 BASIC .UF 4 1 > HELP .SV 8 > > 36 FILES IN 437 BLOCKS - 1 FREE BLOCKS > *^C You should set the date using something like this: .R CCL {in case it ain't already running!} .DATE 12-NOV-94 .DATE {Printout confirms that date worked! It could be off by multiples of 8 years exactly!} Then you can use: .DIR /E/B=2 and the dates and logical records should be in the listing, etc. > > . > .R BOOT > > / This can be .BOOT/RX. That places a bootstrap in memory, but allows for shutdown and restart at 00200 generically regardless of which boot device was chosen. Your values are fine for RX only, etc. > - end transcript - > > And, I've verified that, with BOOT running, it's safe to power down the > emulator, then restart things at 0033 and OS/8 comes up again just fine, > still running BOOT, ready for you to hit control C. See above. Remember, you may eventually emulate other devices! Also, BOOT is a good place to stop for other reasons: You could wind up with a bootable COS-310 or P?S/8 or WPS-8, and they all share the same boot convention, etc. > > Now, I guess I've got to put together a proper distribution of my > emulator and put it out for public consumption. A good start! It would feel better if the RX diagnostics passed though! Remember, there are existing RX programs that delve a whole lot deeper than this puppy of an RX handler! > > Doug Jones > jones@cs.uiowa.edu > cjl From cjl@maestro.com Sat Nov 12 12:59:50 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA21862; Sat, 12 Nov 94 11:14:02 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05868; Sat, 12 Nov 1994 11:14:47 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA28143 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 12 Nov 1994 11:14:41 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA04398 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 12 Nov 1994 11:14:36 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA18029; Fri, 11 Nov 94 20:20:13 EST 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 AA17996; Fri, 11 Nov 94 20:19:55 EST Received: from maestro.Maestro.COM by relay1.UU.NET with SMTP id QQxpqb05231; Fri, 11 Nov 1994 20:19:49 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA28911; Fri, 11 Nov 94 20:19:03 EST Date: Fri, 11 Nov 1994 20:19:02 -0500 (EST) From: Charles Lasner Subject: Re: Continuing saga, boot from RX01 To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9411081602.AA09539@pyrite.cs.uiowa.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 8 Nov 1994, Douglas W. Jones wrote: > I've verified with CJL that the RX01 boot code I have loads a good > (albeit antique version of the) OS/8 system handler for the RX01. > This handler includes startup code to write 8 consecutive pages from > core location 00000 to disk record 33 (octal) and then read 8 pages > starting at disk record 7 to the same core location. Then, the > final step is to jump to 00400 (start of second page). That's the standard OS/8 opening when you start at 07600. Note that starting at 07605 avoids the writing out of 00000-01777 and just reads in the keyboard monitor code over 00000-01777 that resides on records 7 and following, etc. BTW, the handler itself deserves a little historical notes: The first generation of the 8K RX01 handler has the dubious distinction of being the first and only DEC-supported *non*-handler, i.e., it didn't work! In point of fact, the handler couldn't be trusted to write! The reason is this: When the handler retried errors, it lacks the sophistication to even know what context it's in, so it blindly does the INIT operation (67x7) which among other things does a self-test. The problem is that when writing, the buffer must already contain the user's buffer data about to be written out. But the self-test instead substitutes track 1, sector 1, drive 0's contents (in 12-bit mode)!! Thus, if a write operation ever retried, then succeeded, the write causes the wrong data to be written out, and returns with no indicated error!!! Of course, if the data were verified (virtually never done in OS/8 programs!) it would reveal the problem. During the heyday of this handler, I personally got zapped by the problem. A file obtained at a DECUS symposium contained a sector whose contents were part of the OS/8 handler, a likely contents of track 1, sector 1 :-(. Reads deserve retries, else the soft error rate becomes the hard error rate. On floppies, this is lame, since it's the nature of the beast for the soft and hard error rates to be quite different, etc. Yet, the handler had a retry count of 3 for reads that was fine, but fatal for writes; they become untrustworthy! Apparently, this early handler was dumped in favor of the one Doug is attempting. This handler doesn't retry, thus soft error rate= hard error rate for reads, but writes have to succeed reliably, since the handler will always take an error return on any problem. Perhaps quite lame, but at least it's a handler by definition! (The call's result never lies; the only problem is the increased likelihood of reporting an error return on an error that had it been retried, perhaps would have abated, etc.) Later versions of RX handlers all require 12K systems. In return for this, various features are added, such as proper retry that is reliable, since the buffer gets reloaded before a write is retried. (But there isn't enough room for selective error handling, thus all OS/8 handlers are lame in this department! Only P?S/8 bothers to sort out the correct notion of error recovery consistent with the actual problem, and thus avoids the repeat-cycle parity error that won't clear syndrome, etc.) > > This is promising, but I've done a bit of disassembly of the stuff > it pulled in, and it looks wierd: > > 00400: 5705 JMP I 0505 > > 00505: 1005 > > In what follows, the code decides whether to do something depending > on uninitialized memory in field 1. > > 01005: 6211 CDF 10 > 2477 ISZ I 0077 This increments an uninit'd location > 5212 JMP L if uninit'd loc was 7777, go to L > 01010: 1117 TAD 1117 (it gets the value 7420) > 3022 DCA 0022 put it somewhere in page 0 > 01012: 6201 L, CDF 00 Now go do move > > What follows is a loop that tries to move 4K words of field 0, including > itself. > > 01013: 1413 BL, TAD I 0013 Location 13 is initially 1076 > 3414 DCA I 0014 Location 14 is initially 7771 > 2021 ISZ 0021 Location 21 is initially zero. > 5213 JMP BL End up moving a full 4K! Why bother? > > So how does this terminate? Well, note that it tries to overwrite its > loop control variables! > > M[1077 .. 1104] goes to M[7772 .. 7777] > M[1105 .. 1120 goes to M[0000 .. 0013] changes the src addr to 5330 > M[5331] goes to M[0014] changes dst addr to an > uninitialized value! > > So, this code goes wild, overwriting random chunks of memory with strange > stuff. I think I've got my hands on a random chunk of code that's way > out of context. > > Two possibilities remain. Either my disk image is bad (it was once a > bootable disk, but the code pulled in by the boot sequence has been > clobbered), or something very obscure is wrong, allowing the boot > sequence to bring in the system handler but not allowing the system > handler to bring in good stuff. > > Doug Jones > jones@cs.uiowa.edu > I would suggest that since the handler is viable at that point, you can toggle in some test calls to 07607 to attempt to read in some stuff we can verify, etc. For example, call the handler to read in logical records 0001-0006 to see if it resembles a directory. cjl From cjl@maestro.com Sun Nov 13 03:33:27 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA25199; Sat, 12 Nov 94 13:02:10 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA10879; Sat, 12 Nov 1994 13:02:56 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02586 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 12 Nov 1994 13:02:50 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA14443 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 12 Nov 1994 13:02:48 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA16362; Sat, 12 Nov 94 12:56:09 EST 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 AA16358; Sat, 12 Nov 94 12:56:07 EST Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41); id AA27922; Sat, 12 Nov 94 12:55:59 EST for PDP8-LOVERS@AI.MIT.EDU Date: Sat, 12 Nov 94 12:55:28 EST From: John_Wilson@mts.rpi.edu To: PDP8-LOVERS@ai.mit.edu Message-Id: <4630443@MTS.RPI.EDU> Subject: OS/8 disk structure >records 0001-0006 to see if it resembles a directory. Can anyone tell me how to write an OS/8 directory? I already know how to read them, but I don't know how to pick such constants as the number of dir blocks to write (is it always 6, or does it vary with the medium size like in RT-11?). How do you make a medium bootable? I gather a boot disk keeps stuff in the space between the end of the dir and the beginning of the file area; how big an area should I reserve there? And what do I write there? In RT-11 you just pull the primary bootstrap out of the system driver file, and the secondary bootstrap out of the monitor file, make a couple of patches, and write them out as blocks 0 and 2-5. But RT-11's disk structure is only vaguely based on that of OS/8, so this may be totally different. What are the standard names for these files if it *is* similar? John Wilson From cjl@maestro.com Sun Nov 13 20:28:27 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA08044; Sun, 13 Nov 94 04:58:40 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01284; Sun, 13 Nov 1994 04:59:26 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10369 (5.65c+CU/IDA-1.4.4/HLK for ); Sun, 13 Nov 1994 04:59:19 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA10167 (5.65c+CU/IDA-1.4.4/HLK for ); Sun, 13 Nov 1994 04:59:17 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA16177; Sun, 13 Nov 94 04:48:59 EST Return-Path: Received: from relay3.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 AA16170; Sun, 13 Nov 94 04:48:38 EST Received: from maestro.Maestro.COM by relay3.UU.NET with SMTP id QQxpvb04901; Sun, 13 Nov 1994 04:48:27 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA07769; Sun, 13 Nov 94 04:47:28 EST Date: Sun, 13 Nov 1994 04:47:27 -0500 (EST) From: Charles Lasner Sender: Charles Lasner Reply-To: Charles Lasner Subject: Re: OS/8 disk structure To: John_Wilson@mts.rpi.edu Cc: PDP8-LOVERS@ai.mit.edu In-Reply-To: <4630443@MTS.RPI.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sat, 12 Nov 1994 John_Wilson@mts.rpi.edu wrote: > >records 0001-0006 to see if it resembles a directory. > > Can anyone tell me how to write an OS/8 directory? I already know how to > read them, but I don't know how to pick such constants as the number of > dir blocks to write (is it always 6, or does it vary with the medium size > like in RT-11?). OS/8 directories are essentially a sacred length of 6. There is overhead in the structure to allow it to vary, but it never can due to other considerations. In theory, variable size applies, but in practice, changing anything will definitely break certain programs! For the record, please do not use the term "block" when referring to OS/8 stuff. PDP-8 equipment owns the prior title of "block" to mean physical block, as in 128 words in a DECtape block (if you ignore the 129th word!) while OS/8 was the first system to refer to logical *records* of 256 words/record. Thus, in the DECtape case, 1 OS/8 record = 2 DECtape blocks. Note that in P?S/8 and several other systems, the terms are interchangeable because both sizes are 128 words, etc. > > How do you make a medium bootable? I gather a boot disk keeps stuff in the > space between the end of the dir and the beginning of the file area; how big > an area should I reserve there? And what do I write there? In RT-11 you > just pull the primary bootstrap out of the system driver file, and the > secondary bootstrap out of the monitor file, make a couple of patches, and > write them out as blocks 0 and 2-5. But RT-11's disk structure is only > vaguely based on that of OS/8, so this may be totally different. What are > the standard names for these files if it *is* similar? Bootable systems require that record 0 be specially written. Note that record 0 is wasted on a non-bootable device. System heads come in two varieties, one that can run in 8K because the handler fits in 07600-07777 completely, and another that requires 27600-27777 as well. (Note: a small few words are reserved, so in practice, these small sizes are slightly exaggerated over their even smaller true sizes!) When the system is bootable, the data starts in record 70, not in record 7. The directory indicates this either way. The directory placement itself is unchanged. All of the records 7-67 are reserved for a system. In particular, record 66 is reserved for the two-page 12K system handler itself. In the 8K case, the entire handler resides in record 0 second half, essentially being an image of what belongs in 07600-07777. In fact, it's a restriction of OS/8 build constraints that this indeed must be the case! (See below.) In said case, the first half is the code that is generally brought in by the primary boot code already in memory at the beginnning of the boot process, etc. Additionally, some of the code in the first half of record 0 is reserved as the image of certain code skeletons that must be placed into 17600-17777. Again, it's a restriction of the build program that merely loading the image of this first half of record 0 into 17600-17777 is sufficient to startup the system as a sort-of generic bootstrap. (What actually happens is that build swaps around the contents of memory using the handler images loaded appropriately to perform the write-out of the new system from the current running system. Build isn't interested in handler quirks/nuances, thus the requirement that mere image loading produces a functional handler for a short moment of system writing during the build copy process, etc.) In the 12K two-page case, the record 0 first half code does participate in the boot process, but the image of 17600-17777, but the handler is not located in the second half of the record. Instead, record 66 houses both halves of the extended handler, the first half being the image of 07600-07777 and the second half being the image of 27600-27777. (Note: build internal conventions are such that writing handlers imposes physical origin settings far removed from these actual loading considerations; those writing actual handlers must recognize this! In general, build insists on an origin of *0000 in front of a header of info words that aren't in the handler code. Said head ends with a pragmatic notion of the words that are to be written into the first half of record 0 "next" to the skeleton words that must be present. Then there is a *0200 for the next binary page and that is the code for the 07600-07777 part. Should there be an additional page, you follow that with an origin to *0400 followed by the code meant to execute in 27600-27777, etc. Again, note that indicating (in the header) that there are two pages to load causes both pages to be written instead of record 0 to record 66 both halves, etc. My design gripe about image loading stems from the following problem: Certain existing boot conventions do not necessarily cause the boot code to come into memory in the most convenient way, sometimes causing additional fixup code to make the handler viable. In some cases, it's difficult to get in enough boot code as it comes in for the purpose of secondary and/or tertiary loading of the rest of the handler, etc., especially in the case of multiple page handlers, etc. In one notable case, someone created a byte-mode RX01 handler that requires an incredibly complicated boot code segment to satisfy build's constraints that the image of the code be able to function as loaded. As a result, a long and incompatible boot sequence is required to get this system started, etc. However, an after-the-fact program that uses the standard boot in 12-bit mode can be run that patches the system head to obey the normal conventions again. But build cannot create this system directly! (It cannot be used to write out an image of itself using the current image of itself merely loaded bodily and without initialization directly into 07600-07777 and if necessary 27600-27777, etc.) A concept added to P?S/8 for the benefit of system build (still in a primitive but viable state!) is the notion that a handler needs once-only initialization of the image of the handler to make said image into a working handler strictly for the system generation time usage of the handler otherwise loaded into the normal 07600-0777 and whatever other locations required. This allows handlers to be freed from having to be lame images of what needs to eventually be there, and instead can merely be the image of what can later be brought up to the required operational level as a consequence of the boot process, even though the initial loading of what's there is not in and of itself necessarily yet a handler! Taking advantage of this, P?S/8 doesn't even bother to have a defined boot block per se, rather block 0000 directly is an (almost if necessary!) image of the handler itself cognizent of its (eventual) mission of getting up a viable handler within 07600-07777. As such, it's conceivable that this code is partially an image of the secondary boot code read in by the toggle-in primary boot code, later replaced by the intended contents of the corresponding relative region when the rest of the handler is located in 07600-07777, etc. In the case of the P?S/8 RX01 handler, there is a large "hole" in the code that is responsible for continuing the loading process started by the primary boot code, where the code is being loaded into 00002 and following (even though relatively speaking, the code would be more functional if loaded into 07600 and up at the time, etc.!). Once this loading code is in control, the rest of block 0 gets loaded into the proper places in 07600-07777, but the hole is still there (for the moment). The boot process continues in a way that is quite different from OS/8 at this point: P?S/8 reserves 8 additional blocks for handler code, and 2 additional blocks for handler initialization code. The "hole" code loads the two pages of once-only code into 05400-05600. (These values were chosen to slightly simplify what follows, but are totally arbitrary, etc.) The two pages of code then perform a dynamic memory test that runs on all models (avoiding known model-dependent quirks!) that establishes the highest memory field available. Field 0 obviously exists, but now field 1 must be discoved in order to proceed (up to field 7, the most preferable field if available, etc.) Then the contents of the 8 pages of extended handler code are loaded into x6000-x7777 where x is the highest field discoved in the range of 1-7. The final initialization code moves the code from 00002 to 07600 where it is (nearly) executable, etc. The final initialization is to call a routine (located within x6000-x7777) which "fills the hole" in the code in 07600-07777 to make it functional. For system-generation usage, there is an analogous call to fill the hole, etc. in an image of the handler moved to 07600-07777 and 16000-17777 that is then viable for writing out any and all system images, etc. Whenever the system handler is reloaded (such as optionally after binary file loading, etc.) the hole-fill init routine is always available to make the merely loaded code into a viable image of the intended handler, etc. What constitutes the OS/8 system head is the contents of the rest of the area in the range of record 0007-0067. This is constant across all systems, and is written from one to another when build is used. OS/8 PIP /Y option makes an image file of the entire system head so it can be easily restored to the intended device. Note that the PIP head file contains copies of all of the system and non-system handlers, thus it becomes device-specific. Additionally, it must be written to a media-compatible device by a handler of the current system being used to accomplish the PIP operation! Thus, for example, a TD8E non-system handler could be used to perform the operation of writing out the monitor head of a TC08-specific system onto a DECtape. Said tape could then be taken to a TC01/08-based machine and be booted directly, etc. Because of the possible anomalies, certain systems take some defensive safeguards: One of the later RX01 system boot code segments checks to see that the device really is capable of single density as written, i.e., it hasn't been accidentally written out onto a double-density media, since this would make the boot process fail, etc. Similarly, the double-density RX02 system boot code checks to make sure the media and drive are actually double-density lest it actually be written to a single-density RX01-type drive/media where it wouldn't boot properly, etc. > > John Wilson > cjl From cjl@maestro.com Sun Nov 13 20:28:49 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA14288; Sun, 13 Nov 94 11:57:59 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13699; Sun, 13 Nov 1994 11:58:45 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA20374 (5.65c+CU/IDA-1.4.4/HLK for ); Sun, 13 Nov 1994 11:58:43 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA16215 (5.65c+CU/IDA-1.4.4/HLK for ); Sun, 13 Nov 1994 11:58:42 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA27364; Sun, 13 Nov 94 11:47:21 EST 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 AA27360; Sun, 13 Nov 94 11:47:18 EST Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41); id AA03926; Sun, 13 Nov 94 11:47:11 EST for PDP8-LOVERS@AI.MIT.EDU Date: Sun, 13 Nov 94 11:46:38 EST From: John_Wilson@mts.rpi.edu To: pdp8-lovers-request@ai.mit.edu, PDP8-LOVERS@ai.mit.edu Message-Id: <4631033@MTS.RPI.EDU> Subject: Re: OS/8 disk structure >For the record, please do not use the term "block" when referring to OS/8 ^^^^^^ GROAN... :-) Well thanks for all the info! John Wilson From cjl@maestro.com Mon Nov 14 16:32:18 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA10018; Mon, 14 Nov 94 04:04:20 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05116; Mon, 14 Nov 1994 04:05:06 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA03999 (5.65c+CU/IDA-1.4.4/HLK for ); Mon, 14 Nov 1994 04:05:00 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA06960 (5.65c+CU/IDA-1.4.4/HLK for ); Mon, 14 Nov 1994 04:04:56 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA29534; Mon, 14 Nov 94 03:53:12 EST 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 AA29529; Mon, 14 Nov 94 03:52:47 EST Received: from mubo.augusta.de by mc.lcs.mit.edu id aa04836; 14 Nov 94 3:52 EST Received: by mubo.augusta.de (Smail3.1.28.1 #1) id m0r6x8u-0001IbC; Mon, 14 Nov 94 09:52 MEZ Message-Id: Date: Mon, 14 Nov 94 09:52 MEZ From: Juergen Almanstoetter To: pdp8-lovers@mc.lcs.mit.edu sub pdp8-lovers juergen almanstoetter From cjl@maestro.com Mon Nov 14 16:32:33 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA11138; Mon, 14 Nov 94 05:06:38 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA07275; Mon, 14 Nov 1994 05:07:21 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA06052 (5.65c+CU/IDA-1.4.4/HLK for ); Mon, 14 Nov 1994 05:07:18 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA10132 (5.65c+CU/IDA-1.4.4/HLK for ); Mon, 14 Nov 1994 05:07:17 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA02860; Mon, 14 Nov 94 04:58:09 EST Return-Path: <@mail02.mail.aol.com:SpleenWeen@aol.com> 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 AA02851; Mon, 14 Nov 94 04:58:05 EST Received: from mail02.mail.aol.com by mc.lcs.mit.edu id aa05032; 14 Nov 94 4:56 EST Received: by mail02.mail.aol.com (1.38.193.5/16.2) id AA28342; Mon, 14 Nov 1994 04:56:29 -0500 Date: Mon, 14 Nov 1994 04:56:29 -0500 From: SpleenWeen@aol.com Message-Id: <941114045629_7130975@aol.com> To: pdp8-lovers@mc.lcs.mit.edu Subject: pdp8-lovers I would like to join the mailing list for PDP8 Lovers. Thanks Nathan Hendler SpleenWeen@aol.com From cjl@maestro.com Wed Nov 16 23:55:04 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA06224; Wed, 16 Nov 94 08:10:01 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA17566; Wed, 16 Nov 1994 08:10:42 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA03496 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 16 Nov 1994 08:10:23 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA26266 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 16 Nov 1994 08:10:20 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA17400; Sun, 13 Nov 94 20:32:11 EST 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 AB17386; Sun, 13 Nov 94 20:31:48 EST Received: from maestro.Maestro.COM by relay1.UU.NET with SMTP id QQxpxm22462; Sun, 13 Nov 1994 20:31:45 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA00874; Sun, 13 Nov 94 20:30:56 EST Date: Sun, 13 Nov 1994 20:30:55 -0500 (EST) From: Charles Lasner Subject: Re: OS/8 disk structure To: John_Wilson@mts.rpi.edu Cc: pdp8-lovers-request@ai.mit.edu, PDP8-LOVERS@ai.mit.edu In-Reply-To: <4631033@MTS.RPI.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 13 Nov 1994 John_Wilson@mts.rpi.edu wrote: > >For the record, please do not use the term "block" when referring to OS/8 > ^^^^^^ > > GROAN... :-) Well thanks for all the info! You're Welcome! Don't knock your block off while absorbing it! :-) (You can be the first one on your block to use the term "record".) > > John Wilson > cjl (Didn't Monty Python once have a three-sided record?) From cjl@maestro.com Wed Nov 16 23:55:42 1994 Received: from frodo.marshall.edu by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA02866; Tue, 15 Nov 94 13:08:50 EST Received: from MARSHALL.EDU by MARSHALL.EDU (PMDF V4.3-10 #6427) id <01HJIC9OSOGW8WWGG3@MARSHALL.EDU>; Tue, 15 Nov 1994 12:58:46 -0400 (EDT) Date: Tue, 15 Nov 1994 12:58:45 -0400 (EDT) From: Ronald Copley Subject: Re: OS/8 disk structure In-Reply-To: To: Charles Lasner Cc: John_Wilson@mts.rpi.edu, pdp8-lovers-request@ai.mit.edu, PDP8-LOVERS@ai.mit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT On Sun, 13 Nov 1994, Charles Lasner wrote: > cjl (Didn't Monty Python once have a three-sided record?) With the risk of reinvoking a Never-Ending Thread (tm), yes, they did. The back side (I believe) was double-grooved. I forget the title, but it is amongst my collexion somewhere... -- Informatiks | Ronald Copley, owner | Buying and selling small to medium 1010 Township RD 78W | quantities of used Pyramid, Sun, Scottown OH 45678-9051 | DEC (PDPs) and Data General computer +1.614.643.1340 | equipment. (evenings, please) | -- From cjl@maestro.com Wed Nov 16 23:56:02 1994 Received: from apache.telebit.com ([143.191.3.1]) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA27182; Wed, 16 Nov 94 18:31:00 EST Received: from marble.sunnyvale.telebit.com by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA03229 to cjl@maestro.com; Wed, 16 Nov 94 15:31:33 PST Received: from localhost by marble.sunnyvale.telebit.com (8.6.5/1.37) id PAA16986; Wed, 16 Nov 1994 15:31:27 -0800 Date: Wed, 16 Nov 1994 15:31:27 -0800 From: eric@apache.Telebit.COM (Eric Smith) Message-Id: <199411162331.PAA16986@marble.sunnyvale.telebit.com> To: COPLEY1@marshall.edu, cjl@maestro.com In-Reply-To: (message from Ronald Copley on Tue, 15 Nov 1994 12:58:45 -0400 (EDT)) Subject: Re: OS/8 disk structure Monty Python's Matching Tie and Handkerchief. It's a three-sided record, but how many blocks does it have (and how many words per block)? Eric From cjl@maestro.com Fri Nov 18 18:29:14 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA29543; Fri, 18 Nov 94 12:23:14 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA18351; Fri, 18 Nov 1994 12:23:39 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA22198 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 18 Nov 1994 12:22:57 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA24490 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 18 Nov 1994 12:22:40 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA26451; Fri, 18 Nov 94 00:02:28 EST Return-Path: Received: from moomin.moomix.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 AA26416; Fri, 18 Nov 94 00:02:19 EST Received: by moomin.moomix.com (3.1.28.1) id ; Thu, 17 Nov 94 21:04 PST Message-Id: Date: Thu, 17 Nov 94 21:04 PST From: Jan Brittenson To: pdp8-lovers@ai.mit.edu Reply-To: pdp8-lovers-request@ai.mit.edu Subject: Ignore me: administrative ping Just cleaned out a whole bunch of broken addresses. This is a ping to see if there's anything left. -- Jan Brittenson bson@moomix.com From cjl@maestro.com Sat Nov 19 09:31:08 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA15445; Fri, 18 Nov 94 22:02:29 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA23770; Fri, 18 Nov 1994 22:03:00 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14596 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 18 Nov 1994 22:02:56 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA03174 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 18 Nov 1994 22:02:51 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA04902; Mon, 7 Nov 94 16:48:17 EST 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 AA04849; Mon, 7 Nov 94 16:48:10 EST Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41); id AA22059; Mon, 7 Nov 94 16:47:15 EST for PDP8-LOVERS@AI.MIT.EDU Date: Mon, 7 Nov 94 16:46:44 EST From: John_Wilson@mts.rpi.edu To: PDP8-LOVERS@ai.mit.edu Message-Id: <4620702@MTS.RPI.EDU> Subject: RX50 interleave Earlier CJL asked about PDP-11 RX50 formats, after further study I have a correction for my earlier incorrect reply: This is for P/OS, and I hear it applies to RSTS but I don't know if that version (for the Pro) was ever shipped: Given IBLOCK=0-1599: ISIDE=IBLOCK/(80*10) ITRK=MOD(IBLOCK/10,80) ISEC=MOD(IBLOCK,10)*2 IF(ISEC.GE.10) ISEC=ISEC-9 ISEC=MOD(ISEC+ITRK*2,10)+1 ITRK=MOD(ITRK+1,80) Yields ISIDE=0-1, ITRK=0-79, ISEC=1-10. Which is to say, block 0 is track 1 sector 1, things procede from there at interleave=2:1 and skew factor=2, wrap around at track 79 and end at the end of track 0. Supposedly the whole show starts over on side 1, track 1, sector 1, but I'm not aware that 2-sided RX50s were ever built. For people who don't already know, in PDP-8 format the high 4 bits of every other byte are junk. This differs from the RX0[123] formats where the PDP-8 data are packed (high bit first) in the first 3/4 of the sector, with junk in the remainder (or more data with a cute driver). John Wilson From cjl@maestro.com Sat Nov 19 11:29:34 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA05033; Sat, 19 Nov 94 10:51:58 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03633; Sat, 19 Nov 1994 10:52:44 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA09102 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 19 Nov 1994 10:52:37 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA03744 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 19 Nov 1994 10:52:34 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AB23233; Sat, 19 Nov 94 10:35:43 EST Return-Path: Received: from relay3.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 AA23179; Sat, 19 Nov 94 10:33:10 EST Received: from maestro.Maestro.COM by relay3.UU.NET with SMTP id QQxqsa02234; Sat, 19 Nov 1994 10:05:48 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA03789; Sat, 19 Nov 94 10:04:50 EST Date: Sat, 19 Nov 1994 10:04:49 -0500 (EST) From: Charles Lasner Subject: Re: RX50 interleave To: John_Wilson@mts.rpi.edu Cc: PDP8-LOVERS@ai.mit.edu In-Reply-To: <4620702@MTS.RPI.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 7 Nov 1994 John_Wilson@mts.rpi.edu wrote: > Earlier CJL asked about PDP-11 RX50 formats, after further study I have > a correction for my earlier incorrect reply: > > This is for P/OS, and I hear it applies to RSTS but I don't know if that > version (for the Pro) was ever shipped: My understanding is that all VAX and -11 usage of RX50 is consistently mapped, thus allowing any and all conversion programs to be performed at the block-logical level, not physical level. > > Given IBLOCK=0-1599: > > ISIDE=IBLOCK/(80*10) > ITRK=MOD(IBLOCK/10,80) > ISEC=MOD(IBLOCK,10)*2 > IF(ISEC.GE.10) ISEC=ISEC-9 > ISEC=MOD(ISEC+ITRK*2,10)+1 > ITRK=MOD(ITRK+1,80) > > Yields ISIDE=0-1, ITRK=0-79, ISEC=1-10. > > Which is to say, block 0 is track 1 sector 1, things procede from there > at interleave=2:1 and skew factor=2, wrap around at track 79 and end at > the end of track 0. Supposedly the whole show starts over on side 1, > track 1, sector 1, but I'm not aware that 2-sided RX50s were ever built. Thus, the order is: Track 1, sectors 1,3,5,7,9,2,4,6,8,10 then Track 2, sectors 3,5,7,9,1,4,6,8,10,2 etc. through track 79 adding 2 onto each track's next starting odd sector (and also even sector) as each group of five odd (or even) sectors are taken in order. Logical order past physical track 79 is Track 0. The sectors are skewed (aka slide or stagger) by 2 there as well, thus are 2 past the skew for track 79. Is the above correct? This is the intended format for the P?S/8 RX50 handler I am slowly writing. One of the problems is that 800 512 byte sectors is not a multiple of 128 12-bit words! The solution I have worked out is: 1) Honor all requests to transfer into the logical blocks just before the 800 sector limit. Since PDP-8 transfers could request as much as 32 pages of transfer at a time, this could cause some attempt at non-existent sectors contiguous with calls to the highest implemented physical sector (actually on track 0!) 2) Fake the transfer past that point, i.e., just return on writes, and either do nothing or perhaps dump zeroes into the buffer on reads, for the additional dummy sectors involved in the transfer request. 3) Take the error return for any attempt to transfer where the *starting* block would be too high to be fulfilled. This allows any form of calling program a reasonable opportunity to address the device completely. The worst possible case is where the requested page-size block (note: P?S/8 blocks are 1/2 the size of OS/8 records!) is the last one (partially) implemented physically followed by an attempt to transfer up to 31 additional page-sized records. All of the non-existent transfers will be honored without error. Note: P?S/8 and OS/8 programs often "over-read" a device expecting end-of-file within the last read! The programs are often ignorant of the fact that they are asking to read too many blocks. The reason is that they assume that a fixed-length buffer size always can be honored, for example, always reading in 10 blocks at a time helps a program run faster than reading less blocks, thus a good program would always read in 10 blocks. The problems is that near the end of the file, there are usually less than 10 blocks left to read. Yet, the program reads the 10 blocks anyway, thus including junk past the end of the file. Then the program processes the read data to the end of file data point, etc. The rest of what was physically read is ignored. In OS/278, the logical size of the device is 4 logical records shorter than the physical size of the RX50 to not only handle this problem, but to additionally prevent accidental writing on track 78 where the slushware resides! > > For people who don't already know, in PDP-8 format the high 4 bits of > every other byte are junk. This differs from the RX0[123] formats where > the PDP-8 data are packed (high bit first) in the first 3/4 of the sector, > with junk in the remainder (or more data with a cute driver). Yes, in 12-bit mode the DECmate loses the high-4 bits of every other byte on RX50, yet on RX01/02/03 there is no loss for the first 3/4 of the sector. Instead, all of the lossage is at the end, where the last 8 data bits sent from the -8 are replicated to flesh out the sector. In point of fact, the high-4 bits of every other byte on RX50 in 12-bit mode are written as zeroes. This is the underlying reason why I was able to come up with a one-word patch to the system head to prevent corruption when logical record 0000 is rewritten in 12-bit mode, etc. The predictability of the bits being written as 0000 allows the adjacent byte to be written with a value palatable to the boot ROM as a bootable disk, even though it violates DEC's boot-block volume ID standards, etc. (Note: had the RX01/02/03 scheme been used on the RX50 and RD51, the boot corruption problem never would have occurred!) > > John Wilson > cjl From cjl@maestro.com Sat Nov 19 12:26:01 1994 Received: from relay3.UU.NET by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA07200; Sat, 19 Nov 94 12:20:17 EST Received: from rpi.edu by relay3.UU.NET with SMTP id QQxqsj08957; Sat, 19 Nov 1994 12:21:12 -0500 From: John_Wilson@MTS.RPI.EDU Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41); id AA04301; Sat, 19 Nov 94 12:21:11 EST for @relay3.UU.NET:cjl@Maestro.COM Date: Sat, 19 Nov 94 12:17:32 EST To: cjl%Maestro.COM@relay3.UU.NET, PDP8-LOVERS@AI.MIT.EDU Message-Id: <4642702@MTS.RPI.EDU> Subject: Re: RX50 interleave [CJL] >Is the above correct? Looks equivalent to me. >My understanding is that all VAX and -11 usage of RX50 is consistently >mapped, thus allowing any and all conversion programs to be performed at >the block-logical level, not physical level. I would imagine so -- does anyone know if the RQDXn (or RUX50) controllers do this in firmware? I assume they'd have to for things to work out. John Wilson From cjl@maestro.com Sun Nov 20 08:00:10 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA07302; Sat, 19 Nov 94 12:24:38 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08023; Sat, 19 Nov 1994 12:25:30 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA11811 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 19 Nov 1994 11:48:57 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA08397 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 19 Nov 1994 11:48:56 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA25513; Sat, 19 Nov 94 11:32:55 EST Return-Path: Received: from relay3.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 AA25509; Sat, 19 Nov 94 11:32:54 EST Received: from maestro.Maestro.COM by relay3.UU.NET with SMTP id QQxqsg06330; Sat, 19 Nov 1994 11:32:54 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA06021; Sat, 19 Nov 94 11:31:56 EST Date: Sat, 19 Nov 1994 11:31:55 -0500 (EST) From: Charles Lasner Subject: Archive updates on Sunsite.unc.edu To: pdp8-lovers@ai.mit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have finally finished updating the pdp8-lovers mailing list and alt.sys.pdp8 postings archives on sunsite.unc.edu. The files are in the usual places through the end of October, 1994. I have been unable to keep up my "normal" pace recently due to the death of my mother after a 15-month long battle with cancer. Only recently have I begun to "come up to speed" with things on the net, etc. cjl From cjl@maestro.com Sun Nov 20 08:00:28 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA07589; Sat, 19 Nov 94 12:35:22 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08374; Sat, 19 Nov 1994 12:36:15 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA13489 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 19 Nov 1994 12:36:13 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA12916 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 19 Nov 1994 12:36:11 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA27080; Sat, 19 Nov 94 12:21:21 EST 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 AA27073; Sat, 19 Nov 94 12:21:16 EST Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41); id AA04300; Sat, 19 Nov 94 12:21:11 EST for PDP8-LOVERS@AI.MIT.EDU Date: Sat, 19 Nov 94 12:17:32 EST From: John_Wilson@mts.rpi.edu To: cjl@Maestro.COM, PDP8-LOVERS@ai.mit.edu Message-Id: <4642702@MTS.RPI.EDU> Subject: Re: RX50 interleave [CJL] >Is the above correct? Looks equivalent to me. >My understanding is that all VAX and -11 usage of RX50 is consistently >mapped, thus allowing any and all conversion programs to be performed at >the block-logical level, not physical level. I would imagine so -- does anyone know if the RQDXn (or RUX50) controllers do this in firmware? I assume they'd have to for things to work out. John Wilson From cjl@maestro.com Thu Nov 24 10:09:14 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA23552; Wed, 23 Nov 94 19:23:46 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA22993; Wed, 23 Nov 1994 19:13:33 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA01288 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 23 Nov 1994 19:13:18 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA00891 (5.65c+CU/IDA-1.4.4/HLK for ); Wed, 23 Nov 1994 19:13:07 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA08617; Thu, 3 Nov 94 18:32:30 EST Return-Path: Received: from relay4.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 AA08607; Thu, 3 Nov 94 18:31:59 EST Received: from maestro.Maestro.COM by relay4.UU.NET with SMTP id QQxomg22216; Thu, 3 Nov 1994 18:31:48 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA14380; Thu, 3 Nov 94 18:31:11 EST Date: Thu, 3 Nov 1994 18:31:10 -0500 (EST) From: Charles Lasner Subject: Re: Continuing saga of the emulated RX01 To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9411021818.AA04473@pyrite.cs.uiowa.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Nov 1994, Douglas W. Jones wrote: > > Well, the fix to make my emulator correctly handle the 100 function > code wasn't enough to get me something really nice, but it's clear > that quite a bit is working: > > The RX01 bootstrap pulls in a general purpose RX01 read/write routine > into 7600 through 7777; I'll call it RXIO. This begins at 7607, and is > prefixed by a tiny bit of bootstrap code: > > * 7600 > JMS RXIO > 5000 / argument 1 (write 8 blocks field 0) > 0000 / argument 2 (buffer) > 0033 / argument 3 (block) > CLA HLT / error return > CDI 0010 / normal return, setup for JMP > JMP MORE / go to next part of boot This is the standard OS/8 core-save opening. You circumvent it by starting at 07605. If you start at 07600, 8 *PAGES* of memory are saved in field 0 starting from address 0000. The data is written to logical record 0033. Please avoid the use of the nebulous term "block" since it means different things to different people! A DECtape block is (almost!) half of an OS/8 record. Two such blocks are an OS/8 record, etc. (Note: the almost is because DECtape blocks are actually 129 words, and most code goes out of its way to ignore the 129th word, thus a logical DECtape block is 128 words while a physical DECtape block is 129 words. In any case, a logical OS/8 record is two logical DECtape blocks!) > > The first sector that the boot pulled in from disk included this bit > of code that landed in field 1: > > FIELD 1 > * 7667 > CIF 0000 / setup for JMS > JMS RXIO > 1000 / argument 1 (read 8 blocks field 0) > 0000 / argument 2 (buffer) > 0007 / argument 3 (block) > CLA SMA SZA OSR HLT / error return (a kitchen sink constant?) > CDI 0000 / setup for jump! > JMP I .+1 / go to loaded code? > 0400 / points to start of loaded code? All of this code is a skeleton to be filled in as necessary when an executable program is started. This allows the last swap-in over the previously in-control code that did any other loading just before this last load. Generally, this will be a field-zero load of the contents of some of the swap records (oops!, I almost said swap blocks :-).) > > My best effort at hand disassembly and decyphering of the RXIO routine > indicates that the parameters are as follows: > > argument 1: d sssss fff ??? > d = direction of transfer (0=read, 1=write) > s = number of consecutive OS/8 disk blocks to transfer > f = field containing the buffer > ? = unknown use, if any Almost. The sssss are the number of pages involved in the transfer and can be odd, even 1 page long! 00000 means to transfer 0040 pages. Note that if you write an odd page count, you are forever giving up the second half of the last record's former contents. However, you are guaranteed that *something* can later be read there! (without error!) For example, if you are using the RK8E, write one page will zero the second half of the record. Read one page reads and DMA's the first page, but makes you wait while the second half is checked for CRC, etc. But the contents of memory is undisturbed past the first half. Later, the just-half-written record can be completely or half-wise read in without error. If read in, the second half will now contain all zeroes. In the case of the RX01 handler, the second half will actually be unaffected! This is because the logical record is 4 physical sectors. Thus, the handler only works on pairs of sectors, not quads. If the page count is odd, the transfer ends on a pair leaving another pair unscathed, etc. But this behaviour is a quirk, not a guarantee! Additionally, there are other RX handlers where this is (rightfully so!) not true, etc. The ??? bits are almost ignored. The lowest bit is set in a small handful of places throughout OS/8. All such cases have only one purpose: to "help" DECtape (and LINCtape!) based systems to start a tape search in the forward direction instead of the normal reverse search. Note that in all DEC-written handlers, this is quite lame, as it fails to find actual cases where dynamically it could be determined that the search direction *should* have been forward initially! (But cannot be determined statically as in these few implemented cases, etc.) I have written an actual DECtape handler for TC01/08 that does the guesswork itself and ignores the bit. In any case, there are no other functions for these bits in *FILE-STRUCTURED DEVICE* handlers. There are several non-file-structured handlers that actually use these bits for device extensions. All known ones are for devices akin to magtapes handled as non-file devices. The functions are called by the MCPIP program, etc. > > argument 2: > starting address of buffer in indicated field > > argument 3: > OS/8 disk block number of first block to transfer Call it logical record, but otherwise fine :-). > > Furthermore, this nice little routine is only good for reading or writing > unit zero and has no provisions for working with another unit. It's a system handler. You are slightly incorrect. In the RX case, the boot dynamics can determine that the boot drive is drive 1. In that case, it becomes a drive one only routine and cannot work with unit 0, etc. In any case, yes, it's a one-drive handler. P?S/8 handlers include a logical unit extension that supports (using the same relative bits as unused above!) drives 0-7. The boot drive could be any one of those 8 drives and is determined at boot time on the devices that support boot to logical drives other than 0, etc. But OS/8 needs one handler per drive! However, some handlers use a trick of a "co-resident" handler where there are multiple entry points, each handling a different drive. The longest handler ever written was done by myself and Ricky Schreiber. This handler supports 16 entry points! 8 of the entry points are for DTA0: through DTA7: on a TC01/08. Additionally, the same piece of code supports DECtape being used as a non-file-structured device on multiple reels of tape that get auto-unloaded when full. You mount an additional tape if the handler requires it, etc. Thus, a system can have both file-structured and non-file structured use of TC01/08 at the same time, etc. The file-structured entry points support auto-search-direction guessing and ignore the lame attempts by OS/8 proper to "suggest" a direction hardly ever (except in a handful of places). Thus, the handler performs a whole lot better than the standard DEC one, which handles the drives 0-7 file-structured only and only searches forward when told to in function[11], etc. (Note: non-file structured handles always search backwards because you are obliged to read/write the next sequential block next time, etc.) (Or sequential record if you want to talk OS/8 records, but this was a physical description, not a logical one! :-)) > > So, OS/8 experts out there, is this a reasonable thing to have gotten > from a bootable OS/8 diskette? Unfortunately, whatever the darned thing > reads into memory isn't very interesting -- it goes off the deep end, but > it takes a long time to do so. It's hard to imagine that my emulator is > at fault at this point in time. Too much sensible stuff seems to be > accomplished before it goes belly up. Unfortunately, it does go belly > up. So far, this is a proper system. > > So, I'm still in the market for a known good bootable RX01 diskette image. > CJL! You did promise me some of those in exchange for the PDP-8/A I > mailed you some years ago. Sounds like you still have stuff to fix! Getting yet another system probably won't help, etc. > > Doug Jones > jones@cs.uiowa.edu > cjl From cjl@maestro.com Fri Nov 25 10:29:32 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA16819; Thu, 24 Nov 94 20:43:09 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24421; Thu, 24 Nov 1994 20:43:38 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA18732 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 24 Nov 1994 20:43:35 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA24135 (5.65c+CU/IDA-1.4.4/HLK for ); Thu, 24 Nov 1994 20:43:33 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA05607; Wed, 9 Nov 94 12:50:44 EST 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 AA05593; Wed, 9 Nov 94 12:50:40 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Wed, 9 Nov 1994 11:50:39 -0600 id LAA08378 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Wed, 9 Nov 94 11:50:43 CST id AA11377 Date: Wed, 9 Nov 94 11:50:43 CST From: "Douglas W. Jones" Message-Id: <9411091750.AA11377@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: retry -- my RX01 now works I don't know if my last note got through (it never came back to me), but my PDP-8 emulator now boots OS/8 from the RX01 diskette images John Wilson sent me. Both were bootable OS/8 Version 3Q disks, and between them, they include quite a bit. I haven't tried it all, but I see BASIC, PAL8, SABR, TECO, EDIT, RALF, and F4, as well as the usual utilities such as BUILD, BOOT, PIP, ETC. It took me a moment to figure out that PIP had been split, so that the directory listing functions were moved to DIRECT, while the peripheral interchange functions were in PIP. Anyone who wants a copy of my emulator is welcome to take one from ftp.cs.uiowa.edu:/pub/jones/pdp8/ (get README first to see what's there). Doug Jones jones@cs.uiowa.edu From cjl@maestro.com Sat Nov 26 10:58:51 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA00855; Fri, 25 Nov 94 11:54:39 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA12338; Fri, 25 Nov 1994 11:55:25 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA16020 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 25 Nov 1994 11:55:22 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA18755 (5.65c+CU/IDA-1.4.4/HLK for ); Fri, 25 Nov 1994 11:55:15 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA07231; Fri, 25 Nov 94 11:42:05 EST Return-Path: Received: from relay3.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 AA07220; Fri, 25 Nov 94 11:41:44 EST Received: from maestro.Maestro.COM by relay3.UU.NET with SMTP id QQxrok16483; Fri, 25 Nov 1994 11:41:28 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA00443; Fri, 25 Nov 94 11:40:23 EST Date: Fri, 25 Nov 1994 11:40:22 -0500 (EST) From: Charles Lasner Subject: Re: retry -- my RX01 now works To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9411091750.AA11377@pyrite.cs.uiowa.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Nov 1994, Douglas W. Jones wrote: > I don't know if my last note got through (it never came back to me), > but my PDP-8 emulator now boots OS/8 from the RX01 diskette images > John Wilson sent me. Both were bootable OS/8 Version 3Q disks, and > between them, they include quite a bit. I haven't tried it all, but > I see BASIC, PAL8, SABR, TECO, EDIT, RALF, and F4, as well as the > usual utilities such as BUILD, BOOT, PIP, ETC. It took me a moment > to figure out that PIP had been split, so that the directory listing > functions were moved to DIRECT, while the peripheral interchange > functions were in PIP. Yes, when DIRECT was written, they removed (hastily!) the /E, /F, /L code and replaced it with a stub that just prints out "USE DIRECT" instead :-(. Additionally, PIP can't handle any wildcard filenames, thus FOTP was additionally created. Additionally unfortunately, this created a debacle: The original PIP supported the /E (Extended), /F (Fast), and /L (directory Listing normal) options up until the date extensions (which btw run out as currently defined in 2001!) were added which required additional code to support the 8-year group bits, etc. Management felt that the additional work was too much, etc. and the DIRECT program was created to deal with an acceptable variation of the directory listing option. However, many users felt cheated due to the overhead in switching programs, since you often want a quick directory listing to help formulate a PIP command to accomplish some utility file transfer, etc. At the same time as this, DEC's released copy of PIP not only deleted the support of /E, /F, /L, but there was also an inadvertant serious bug regarding the /Y switch to copy images of system heads, etc. A user (can anyone name this person?) created a set of fixes for the *entire* situation: 1) Fixed the /Y bug. 2) Restored the /E, /F, /L switches with complete support for the date year group bits through 1999. (Note: there are a whole lot of OS/8 bugs waiting to happen whereby the routines cannot handle past 1999 even though the date format itself runs out at the end of 2001, etc.) 3) Added a new /N switch that changes the behavior of the /E, /F, /L switches so that the output conforms to the so-called "New" date format. (The old format was such as 11/25/94 while the new format is 25-NOV-94.) It would have been very nice if this version of the fix to PIP were distributed. However, instead of this, the user contacted DEC's PDP-8 programming manager and received the following misinformation: The manager informed the user that DEC had "other ideas" about how to fix the /Y bug, and that they were "reserving" the space taken up by the (now former) /E, /F, /L code. Thus, what DEC wanted to happen was that this code only be distributed unofficially. This might have been fine, but an additional problem occurred. DEC supplied the user with alternate code claiming to fix the /Y bug. In point of fact, the user's code had fixed the bug while the new DEC-supplied code was buggy itself! Still circulating around the PDP-8 world is a file usually known as PIPEFL which is named after the PIP /E, /F, /L switches that it restores (as it also addes /N). This file contains DEC's incorrect fix to the /Y problem. Thus, there are three options: 1) Use the old PIP with the /Y bug. 2) Use the old PIP patched with PIPEFL and you get the date enhancements complete with the /N switch and you still have the /Y bug. 3) Use the new PIP where /E, /F, /L are non-functional thus requiring using DIRECT where needed. The /Y code is functional in all versions since the removal of /E, /F, /L (in all official release versions). The /Y bug is rather serious: Attempts to involve handlers other than SYS: in the use of the /Y switch will certainly fail. Depending on whether the code is the original PIP or the DEC-patched version (as in PIPEFL) changes the severity of the "penalty" for using the flawed code (which could including destruction of part of the system!). So, as a result of all of this, there is no single program that can be used as PIP ought to be :-(. As an aside (and a suggestion towards improvement), please note that there is a program on TOPS10 called PIP1K. It essentially is a vital subset of the PDP-10 PIP program that runs in a minimal space to accomplish most of the common options of PIP on that system. When an option is invoked that cannot be handled, the full PIP is chained to for the execution of that function alone, and then PIP1K is restarted for further input, etc. Using the TOPS-10 notion, a core PIP program can be created that runs in 8K to handle as many options as can be reasonably handled. For additional functions, PIP could have an overlay section. Refinements could include detection of 12K or 16K leading to loading in the full program initially to avoid swapping, etc. More recently, PIP has undergone additional degradation in OS/278. It now requires 12K to load in all of the kludges that unnecessarily were added to accomplish a half-baked "solution" to parts of the DECmate "problem". In point of fact, all of this code could be eliminated. If any of it wants to be preserved, it could be called in as a (possibly DECmate-specific) overlay, etc. DIRECT was created because the person assigned to add in the directory listing options of PIP to do a good enough job wasn't interested in plowing through the code. (Note: PIP isn't really well-written! There is a whole lot of room for improvement!) FOTP is an additional program created as an additional kludge (I know the author of these two personally!) because there wasn't enough room in DIRECT to handle both jobs in the same 8K image.) By applying some proper rewrite effort, one program can obsolete all three of these less-than-perfect programs (as it should have been accomplished originally!) and CCL pointers to the programs redirected to PIP, etc. Another quirk of PIP is that some versions support a quirky conversion in ASCII text mode: When a file is copied in ASCII mode, one would conclude that the contents are merely copied. However, in some versions, horizontal tab handling causes the strange circumstance of including a rubout character after the tab! This was done due to interference from an ignorant manager. At the time, model 35 teletypes were the typical console device on PDP-8's within DEC's development areas. Model 35 teletypes do require special tab handling, but *not* the inclusion of a rubout character! The *correct* way to handle tabs on a model 35 teletype (as is done in TOPS-10) is as follows: 1) We assume the physical stops have been setup every 8 positions. 2) Calculate the difference between the current carriage position and the final position after the tab. Divide by 4 yielding a result of 0, 1, 2. This is the count of how many non-printing characters need be outputted after the horizontal tab before attempting a printing character. Thus print this count of nulls or rubouts etc. Note that while blindly outputting one rubout does sometimes help, at other times it represents a waste of time, and in still other cases it's not enough time! Clearly inserting the character into the file itself is not the correct thing to do! Additionally, it causes file handling to take longer and wastes disk space, etc. PIP has long been a "sore point" of OS/8. It's about time we cleaned a lot of its problems up. cjl From cjl@maestro.com Sat Nov 26 11:01:26 1994 Received: from SunSITE.Unc.EDU (president.oit.unc.edu) by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA17852; Sat, 26 Nov 94 04:57:31 EST Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA09107; Sat, 26 Nov 1994 04:58:27 -0500 Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA20995 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 26 Nov 1994 04:58:24 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA16954 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 26 Nov 1994 04:58:18 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA01009; Thu, 10 Nov 94 16:28:26 EST 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 AA01005; Thu, 10 Nov 94 16:28:21 EST Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322) on Thu, 10 Nov 1994 15:28:12 -0600 id PAA18829 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Thu, 10 Nov 94 15:28:13 CST id AA12658 Date: Thu, 10 Nov 94 15:28:13 CST From: "Douglas W. Jones" Message-Id: <9411102128.AA12658@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: Emulator supplies The RX01 support on my emulator is quite realistic in one annoying way: It can't format an emulated RX01 diskette. Fortunately, you only need one diskette, since you can just copy the blank diskette file as many times as you need. Here's a uuencoded blank diskette for my emulator: begin 600 blankdisk M); Sat, 26 Nov 1994 12:43:08 -0500 Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA15963 (5.65c+CU/IDA-1.4.4/HLK for ); Sat, 26 Nov 1994 12:43:06 -0500 Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA02574; Sat, 26 Nov 94 12:29:40 EST Return-Path: Received: from relay3.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 AA02446; Sat, 26 Nov 94 12:29:28 EST Received: from maestro.Maestro.COM by relay3.UU.NET with SMTP id QQxrsf22746; Sat, 26 Nov 1994 12:29:27 -0500 Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA24819; Sat, 26 Nov 94 12:28:19 EST Date: Sat, 26 Nov 1994 12:28:18 -0500 (EST) From: Charles Lasner Sender: Charles Lasner Reply-To: Charles Lasner Subject: Re: Emulator supplies To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9411102128.AA12658@pyrite.cs.uiowa.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII The emulator could be made to really format as well! The relevant stuff to use is as follows: Issue a seemingly normal write sector command. However, ask for the magic sector 154 octal. This signifies a write operation of sector numbers (formatting) as opposed to writing out the silo buffer. Wait for the transfer flag to set and in response send in the AC the desired sector number. Repeat this for a total of 26 times. The sector headers will be formatted with the data as delivered to the interface in the order specified, first physical sector after index first, etc. After the 26 sectors are sent, wait (quite a while!) for the done flag, which will raise after the track is formatted. Individual tracks can be formatted, and a complete disk format involves doing all 77 tracks 0-76. Along the way, the error flag can raise due to one of two special reasons (beyond any "normal" ones such as drive not ready, etc.): 1) Write-lock error (same as in a normal write situation). 2) Format-enable error. (The DSD-210 supports a format-protect switch; attempting to format while thrown gives you this specific protection code.) Reading the error register in the normal manner at the completion of the command (perform read-error register function after an error flag raise) reveals the relevant error code. I can look up the format-enable error code, but it's the same as one of the ones DEC later added to the RX02 for the set-media-density stuff, etc. cjl