Subject: RX50 interleave

From: [email-masked]
Date: Mon, 7 Nov 94 16:46:44 EST

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

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

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

> 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