Subject: Re: RX50 and Pro's - two questions

From: [email-masked] (Charles Lasner)
Date: 8 Apr 1994 04:22:09 GMT

In article <[email-masked]>,
Ken Wellsch <[email-masked]> wrote:
>>> You also need the added magic header numbers at the start of
>>> the boot block to be recognised as a boot block.
>>
>> Can you give specifics about the magic numbers required for bootability,
>> and/or a DEC spec for what it's called?
>
>Here is where I first encountered these magic numbers
>(from the 2.9BSD port to the Pro):
>
> / eight dummy words to keep DEC firmware happy
> / must be prepended onto any boot block
>	0
>	405
>	0
>	67
>	0
>	42020
>	105041
>	400
>
>Which using the document "CTI Bus: Technical Manual" (alas which also says,
>"confidential information" so hopefully I'm not going to catch heck on this)
>translates to (in octal still):
>
>  byte  0	0	Type 2 or 4 boot block
>  byte  1	0	Type 1, 2 or 3 boot block
>  byte  2	5	Offset from 0 to identification area, in words
>  byte  3	1	System volume
>  byte  4	0	not used here
>  byte  5	0	not used here
>
>  byte  6	0	I don't know what these four are about
>  byte  7	67	since the offset above jumps over them.
>  byte  8	0
>  byte  9	0
>
>  byte 10	20	CPU type, 020 = PDP-11
>  byte 11	104	Controller type, 104 = non-MSCP CTI bus controller
>
>  byte 12	41	File structure, 041 = Files-11 Level 1
>  byte 13	212	Checksum
>
>  byte 14	0	just says 0
>  byte 15	1	Version number of standard,
>			001 = initial version, one-sided.
>
>So I guess someone just took the header of some stock DEC diskette
>and used that if I've not been mistaken in my translation.

Thanks for piecing together *exactly* what I'm referring to!

In the DECmate II/III/III+ world, we are obliged to conform to this same
nonsense.  In order for either a hard disk volume or a diskette to be
considered bootable, the following tests are made in the DECmate ROM:

1)	Byte[0]-Byte[1] .EQU. 000  {This seems consistent with your
description although I have no idea what the variations would be, etc.}

2)	Byte[2] is an index into the record as to where to find the rest
of the stuff.  Multiply by 2 to get the byte number to start looking at.
In the case of hard disk volumes, this value is 3; in the case of
diskettes, it's 2.  So, for a typical diskette, this means look in byte
4.  The actual ROM code starts looking in byte 6-9.  If the test fails,
it then starts over in byte 4-7.  If both variants flunk, the machine has
no boot device.

3)	Assuming the hard disk case, look at byte[6] and byte[7].  Both
values have to have a certain bit on (in octal):

	byte[6] .AND. byte[7] .AND. 010 .EQU. 010  has to be true.  I'm
not quite sure why, but this is a DECmate, not an -11 family member!

	byte[6] + byte[7] + byte[8] + byte[9] .EQU. 377 in 8-bit
arithmetic has to be true.

	If any part of test 3) flunks, go back to byte[4] and try again.
If 4-7 can't hack it either, the boot flunks, and you get a big blinking
floppy on the screen until you change to a bootable one, etc.

Other bytes are set to other values, but they aren't checked for in the
DECmate ROM.

All of this would be a minor nuisance on the DECmates, but in fact it's a
major hassle!

PDP-8 convention is that the boot is performed by reading in track 1,
sector 1 into location 00002 and following until the boot code gets
overlayed by what came in, which in turn determines what happens next,
etc.  This all derives from the fact that all PDP-8 RX hardware
(01/02/03/50) programs the same exact way other than a few minor quirks
and the overall disk geometry (77 tracks, 80 tracks; 10 sectors, 26
sectors, etc.)

So, what this *should* have meant is that the 6120 code is merely
hampered by the fact that logical record 0000 has an 8-word "hole" in it
at the beginning, so that the code that loads is a bit smaller than
usual.  Thus, the system startup code has to be a bit tighter, etc.
Annoying, but not fatal, etc.

However, what *does* happen *is* fatal!

OS/8 family convention is that it's totally normal to expect to be able
to call a device handler and have any logical record written or read with
no restriction.  Indeed, certain standard utilities set out to read,
modify, write back record 0000 as a normal mundane system operation, etc.

But on the DECmates, this *DESTROYS* the system!!!

Some band-aids have been applied to partially inhibit these otherwise
normal operations, but they aren't completely effective, not to mention
the loss of the underlying utility of the operations, etc.  (The system
BUILD utility can't be run for example!)

I have traced the problem down to the basics:

On the PDP-8, the norm is to use the RX01/02 12-bit mode.  (-11
controllers never set this bit on the RX buss, but it's always there.)
From the PDP-8 perspective, the RX01 is a device with 8-bit and 12-bit,
and the RX02 is a device with 16-bit and 12-bit.  If you are using
single-density diskettes, the 12-bit mode is totally compatible.  If you
are using byte mode, the RX02 must include 16-bit command transfer by
sending an extra byte after the TR flag raises.  This must NOT be
performed on the RX01 in byte mode.  (Note: there are RT-11 handlers for
an RX02 on an RX01's controller that do the same thing.)

So, it comes as no surprise that the DECmates boot up in 12-bit mode,
i.e., the contents of track 1, sector 1 are read into 00002 and following
in 12-bit mode.  The system that comes in contains 12-bit mode data that
overlays the 12-bit words in 12-bit memory  The 12-bit-oriented contents
(ignoring the 25% additional data that's actually on the diskette)
represent part of the normal read/write addressable data space the
handlers see, etc.

But on the DECmate, the organization of the data is different from
RX01/02 where this would be no problem.  On the RX01/02, the 12-bit data
is in the form of 12-bit bytes, i.e., the same stream of bits that all
others see as 8-bit bytes laid end to end in order.  Since this is a
12-bit mode transfer, the sector data ceases when the first 3/4 of the
data is transferred to/from the -8.  (So, on the RX01, the -8 transfers
64 12-bit words that are the same exact data as the first 96 bytes of the
sector.  The last 32 bytes of data aren't involved with the -8.  In point
of fact, I believe that what's written is a replication of the last 8
bits the -8 did transfer, etc.  For an RX02, double all the numbers, but
the same factors apply, etc.)

On the DECmate RX50 and also identically on the hard disk controller, the
data is instead organized as 16-bit data.  Thus, relative to byte mode
transfer, the even bytes are taken from the low-order PDP-8 12-bit word's
8 bits and are all present.  But the odd byte is taken from the
high-order PDP-8 12-bit word's 4 bits.  The "unused" bits are filled in
with 0000!

Thus, unlike the RX01/02 where the unused data happens all together at
the end of the record, the RX50 (and RD51) "shred" the data every 16 bits.

Unluckily, this means that the checksum byte's low-order bits get zeroed
every time the record is written in 12-bit mode!

Thus, we have a ludicrous problem:  we have a convention where we have to
read in the record in 12-bit mode, reckon it in 12-bit mode, but we
aren't allowed to write it in 12-bit mode!  To even create this record,
you have to write a kludge where you pre-translate the data into 8-bit
bytes as they look in byte mode but yet are actually 12-bit words to be
later read in when the boot read is performed in 12-bit mode!  (Note: I
have found those very utilities; they kludged OS/278 PIP to do a
special-case check for RX50.  However, there is no equivalent for the
hard disk.  To attempt to change a system head there is fatal!)

Actually, I have defined a way out of this mess: By re-arranging the four
bytes involved in the checksum, I can make the even byte before the
checksum contain the proper checksum that gets preserved (because it's an
even byte).  The odd byte (formerly the checksum) now contains a value
whose 4 bits are meant to be 0000 whether written that way in byte mode
or become that way in 12-bit "shred" mode.  This involves a one-word
(12-bits) patch to the handler that *can* be performed in 12-bit mode
using any number of utilities (doing it the way it was meant to be!).
Once done, both the hard disk and diskette volumes work fine!

My question is: does my non-standard value actually "matter"?  Will the
avenging god of DEC boot standards visit me in the night for having
modified their sacred magic numbers?  (So ill-ly conceived for the
DECmate, but "standard"!)

If such a disk is used on any utility anyone here can think of on any
machine, does any program actually care?

IF the answer is "yea, verily" then I can write an "export" utility that
puts the disk back to the original value.  (And should any of the
standard utilities operate on it, it becomes non-bootable!  However,
using the corresponding "import" utility would restore it to
boot-worthiness, etc.)

Perhaps someone can find a more "master" reference to where all of this
nonsense started, etc.

The answer to the question will allow further work to happen on fixing
the O/S; the released version is broken as I stated above, etc.

cjl (watching the skies for boot-block warlords)