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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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" <jones@pyrite.cs.uiowa.edu>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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" <jones@pyrite.cs.uiowa.edu>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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" <jones@pyrite.cs.uiowa.edu>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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" <jones@pyrite.cs.uiowa.edu>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <cjl@maestro.com>
Subject: Re: the RX01 saga, continued
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9410312033.AA02749@pyrite.cs.uiowa.edu>
Message-Id: <Pine.3.89.9411031708.A11994-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
Subject: Re: another RX01 documentation error
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9411022011.AA04552@pyrite.cs.uiowa.edu>
Message-Id: <Pine.3.89.9411031855.H11994-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
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: <Pine.3.89.9411050814.A7542-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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" <jones@pyrite.cs.uiowa.edu>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <COPLEY1@marshall.edu>
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 <COPLEY1@marshall.edu>
Subject: SUBSCRIBE
To: pdp8-lovers@ai.mit.edu
Message-Id: <Pine.3.89.9411081342.A538973019-0100000@MARSHALL.EDU>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <COPLEY1@marshall.edu>
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 <COPLEY1@marshall.edu>
Subject: Re: retry -- my RX01 now works
In-Reply-To: <9411091750.AA11377@pyrite.cs.uiowa.edu>
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
Message-Id: <Pine.3.89.9411101219.C538977320-0100000@MARSHALL.EDU>
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 <bsd/sgtty.h> 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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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" <jones@pyrite.cs.uiowa.edu>
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:</E
USE DIRECT
*^C

.R DIRECT
*TTY:</E



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           <EMPTY>     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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
Received: from relay1.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <cjl@maestro.com>
Subject: Re: retry -- my RX01 now works
To: Ronald Copley <COPLEY1@marshall.edu>
Cc: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>, pdp8-lovers@ai.mit.edu
In-Reply-To: <Pine.3.89.9411101219.C538977320-0100000@MARSHALL.EDU>
Message-Id: <Pine.3.89.9411112017.H28081-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
Received: from relay1.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <cjl@maestro.com>
Subject: Re: RX01 Boot problems licked!
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9411081638.AA09584@pyrite.cs.uiowa.edu>
Message-Id: <Pine.3.89.9411112158.I28081-0100000@maestro.com>
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:</E
> USE DIRECT
> *^C

Yes, the dreaded PIP version where the /E, /F, /L switches were deleted!

> 
> .R DIRECT
> *TTY:</E
> 
> 
> 
> 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           <EMPTY>     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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
Received: from relay1.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <cjl@maestro.com>
Subject: Re: Continuing saga, boot from RX01
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9411081602.AA09539@pyrite.cs.uiowa.edu>
Message-Id: <Pine.3.89.9411112021.D28081-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
Sender: Charles Lasner <cjl@maestro.com>
Reply-To: Charles Lasner <cjl@maestro.com>
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: <Pine.3.89.9411130331.A7296-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jalman@mubo.augusta.de>
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: <m0r6x8u-0001IbC@mubo.augusta.de>
Date: Mon, 14 Nov 94 09:52 MEZ
From: Juergen Almanstoetter <jalman@mubo.augusta.de>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
Received: from relay1.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <cjl@maestro.com>
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: <Pine.3.89.9411132055.B713-0100000@maestro.com>
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 <COPLEY1@MARSHALL.EDU>
Subject: Re: OS/8 disk structure
In-Reply-To: <Pine.3.89.9411132055.B713-0100000@maestro.com>
To: Charles Lasner <cjl@maestro.com>
Cc: John_Wilson@mts.rpi.edu, pdp8-lovers-request@ai.mit.edu,
        PDP8-LOVERS@ai.mit.edu
Message-Id: <Pine.3.89.9411151250.A538991427-0100000@MARSHALL.EDU>
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: <Pine.3.89.9411151250.A538991427-0100000@MARSHALL.EDU> (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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <bson@moomix.com>
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 <m0r8LUO-000DIOC>; Thu, 17 Nov 94 21:04 PST
Message-Id: <m0r8LUO-000DIOC@moomix.com>
Date: Thu, 17 Nov 94 21:04 PST
From: Jan Brittenson <bson@moomix.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
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: <Pine.3.89.9411190915.A3024-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
Subject: Archive updates on Sunsite.unc.edu
To: pdp8-lovers@ai.mit.edu
Message-Id: <Pine.3.89.9411191137.B5826-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
Subject: Re: Continuing saga of the emulated RX01
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9411021818.AA04473@pyrite.cs.uiowa.edu>
Message-Id: <Pine.3.89.9411031826.G11994-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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" <jones@pyrite.cs.uiowa.edu>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
Subject: Re: retry -- my RX01 now works
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9411091750.AA11377@pyrite.cs.uiowa.edu>
Message-Id: <Pine.3.89.9411251040.B28528-0100000@maestro.com>
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 <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id 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" <jones@pyrite.cs.uiowa.edu>
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<G@P,0``````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````````````````````````0!P```0"`!P`0
M"0#P"`"@&`%P$@(@+P*0-`406`70A0J0M0XA+A7AER$"C"]3ITG%@6G(0Z'<
%.$J@"`"@
`
end

The above diskette has the required header (rx01) and the required
deleted-data bits (all set to zero) followed by a byte giving the
geometry with which the disk was formatted (zero, indicating default
interleaving).  The bits after that don't matter -- the emulator
merely demands that the 256 byte header be present and begin with
the "magic number" rx01.

				Doug Jones
				jones@cs.uiowa.edu


From cjl@maestro.com Sat Nov 26 12:45:43 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA25142; Sat, 26 Nov 94 12:42:15 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA24388; Sat, 26 Nov 1994 12:43:12 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02246
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); 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 <lasner@cunixf.cc.columbia.edu>); 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: <cjl@maestro.com>
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 <cjl@maestro.com>
Sender: Charles Lasner <cjl@maestro.com>
Reply-To: Charles Lasner <cjl@maestro.com>
Subject: Re: Emulator supplies
To: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9411102128.AA12658@pyrite.cs.uiowa.edu>
Message-Id: <Pine.3.89.9411261111.A22621-0100000@maestro.com>
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


