Subject: RX01 boot fun

From: "Douglas W. Jones" <[email-masked]>
Date: Tue, 25 Oct 94 17:12:27 CDT

I'm trying to debug the RX01 support on my PDP-8 emulator, but I'm working
from a pretty poor foundation.  At this point, the emulator supports a
fairly large body of code that I've written to test the RX01 -- I can
read and write any sector on my emulated disks, and so on.

I have a disk image complements of John Wilson at RPI that claims to be
an OS/8 system disk (or at least, the name of the uuencoded file he
shipped to me was os8sys.flp.gz).  The disk image is 256256 bytes long,
which is just right for a full dump of an RX01 disk, and he said he
dumped it using a PDP-11.

I have two RX8, RX01 bootstraps, one from the RX01/RX02 Pocket Service
Guide, second edition, 1981, and one that was originally posted to this
group that came from the manual for an 8/e disk subsystem built by DSD.

I wrote a little bit of PDP-8 code to read a 256256 byte file in from my
(emulated) paper tape reader and dump it to disk.  Octal dumps of the
resulting emulated disk image show that my program put sector 1 of
track 1 in the right place, and sector 1 of track 1 looks at least
somewhat reasonable.  I have yet to get a straight answer about how
to deal with interleaving, so I've shotgunned it, getting different
results with different answers, but none useful.

The problem:  Both bootstraps do something with all attempts at
interleaving or not interleaving the data from (emulated) paper tape, but
I don't get a running system from any of the attempts.  Either my emulator
is bad in some obscure way or my code to copy John Wilson's diskette
image to an emulated diskette is bad or the disk I have isn't a bootable
system.  All of the above seem equally likely.

The solution:  Work, inspiration and similar annoying stuff.

Things I wish I had:

 --  An RX01 disk exerciser not written by me.  The one I wrote works
      fine, but perhaps there's something I'm not testing.

 --  An octal dump (8 bit or 12 bit mode) of the expected contents of
      track 1 sector 1 and track 1 sector 2 of a bootable OS/8 disk.
      This would let me see if I've dealt with interleaving properly,
      and it would let me verify that John Wilson's diskette is indeed
      good.

 --  Clear documentation of the interleaving scheme used by OS/8.  Given
      a logical sector number (as seen by the software), what
      transformation does the software perform before handing it to the
      RX8 controller?  Did RT11 use the same scheme or something else?
      Knowing all of this would help me undo what was done to Wilson's
      disk.

				Doug Jones
				[email-masked]

---

From: Charles Lasner <[email-masked]>
Date: Wed, 26 Oct 1994 10:38:55 -0400 (EDT)

> read and write any sector on my emulated disks, and so on.

A good start.  Passing the diagnostics would be even better.

> dumped it using a PDP-11.

Having read further down, this is the source of at least part of your 
problems.

> group that came from the manual for an 8/e disk subsystem built by DSD.

The DSD is a superset of DEC.  In the DEC version, there is an unused 
command bit conveniently placed to the left of the unit select bit.  DSD 
implemented it as an extension to the register which is quite nice.  
Thus, DSD drives care about that bit while DEC systems ignore it.  P?S/8 
RX01 non-system handler supports the unit extension, as well as a 
supplied OS/8 non-system handler from DSD for three drives.  (They never 
packaged more than three drives in a box, but the disk buss supports 4 
drives which is the norm for industry-standard diskette drives, etc.  I 
have a two-drive DSD-210, and by extending the command cable, two 
additional drives are readily supportable.  Using a cable adapter, RX01 
format can be written on 5.25" drives!)

In any case, DSD support is totally compatible for the first drive pair.

Additionally, DSD drives support actual low-level physical formatting.  
To format a drive, attempt a normal write, except ask for sector 152 on 
the track.  If accepted, then send 26 sector values in the desired order 
starting past index.  The net result is a format track operation.  I have 
a functioning formatting program I wrote years ago, etc.  The DSD board 
supports a format lock switch as well as a write-protect switch.  
(Actually, each drive supports write-protect separately; this is 
documented in the DEC pocket service guide in terms of the associated 
error.  DEC computer special systems supported the feature for interested 
customers, but not in stock production.)  There are two new error codes, 
one for attempt to format with format-protect set, and attempt to format 
with write-protect set.

It would be useful to support at least the write-protect bit, which is 
set when either the drive or media is write-protected.  (Note: 8" notch 
hole cover convention is the *opposite* of 5.25"!  You need to fill the 
hole to write on the drive, similar to the notion of a magtape write 
ring.)  Additionally, the bit sets when the drive is not ready.  
Apparently, the logic is rather bare, thus a drive without media allows 
the photocell to be illuminated while a closed notch diskette prevents 
this if present, etc.  Code that checks for a not-ready condition must 
not be fooled into believing that the media is write-protected (rather 
it's non-existent!) and additionally, not believe the drive is an RX02 
(which also, rather uselessly, sets this bit!).

In any case, sticking to just the first two drives, the DSD boot is much 
shorter than the DEC one, and takes advantage of a trick: When power 
clear is issued, the drives do a self-test that involves reading track 1, 
sector 1 into the buffer.  Thus, instead of performing the explicit read, 
it expects the self-test to have performed it, etc., thus the code is 
much shorter, etc.  Additionally, DEC's longer version infinitely 
retries, and additionally supports a hack of alternating attempts on both 
drives.  The even longer RX02 version additionally alternates media 
density trying all four combinations of drive select and media density.

> results with different answers, but none useful.

Track 1, sector 1 is the only one that they will agree on.  The rest are 
hopelessly wrong.

> system.  All of the above seem equally likely.

The -11's use a mapped format not used on the -8.  You have to remap the 
data before writing it.

OS/8 bootable RX01 uses the data in 12-bit mode while -11's use 8-bit 
mode.  Thus, you have to write the data in the -11's order in 8-bit 
mode.  The -11's order is in turn both interleaved and staggered while 
the -8 format is interleaved only.

Thus, both systems ignore track 0, and start at track 1, sector 1, and 
that's why you have good results that far.  However, PDP-8 convention is 
to then interleave the sectors in the order of all odds, then all evens: 
1,3,5,7,9,11,13,15,17,19,21,23,25,2,4,6,8,10,12,14,16,18,20,22,24,26. The 
-11's do this also, except that the starting point in the 26-sector 
sequence is staggered by 6 for the next track.  Thus, track 1 logically 
starts on sector 7!  All of the odd sectors are done first, then all of 
the even ones.  The even ones will start with 8.  

Thus, you have to write the data from the -11 in a manner both 
interleaved and staggered to reproduce the original data in the original 
order.  The running (albeit simulated) -8 code will pick out the data in 
the intended way - 12-bit transfers and interleave of two without 
stagger, etc.

>       fine, but perhaps there's something I'm not testing.

There are standard RX dignostics.

>       and it would let me verify that John Wilson's diskette is indeed

It's clear you've done it inadvertently wrong.  Try again.

>       Knowing all of this would help me undo what was done to Wilson's

Read the above.

BTW, I have a question:  What is the RT-11 interleave and stagger scheme 
for RX02 and RX50?  (I guess that's two questions!)

> 				[email-masked]

cjl