Subject: Re: RX01 boot fun

From: [email-masked]
Date: Wed, 26 Oct 94 13:04:24 EDT

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: Charles Lasner <[email-masked]>
Date: Sat, 5 Nov 1994 10:03:42 -0500 (EST)

> 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.

> 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?

>  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