Subject: the RX01 saga, continued

From: "Douglas W. Jones" <[email-masked]>
Date: Mon, 31 Oct 94 14:33:35 CST

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
					[email-masked]

---

From: Charles Lasner <[email-masked]>
Date: Thu, 3 Nov 1994 17:45:33 -0500 (EST)

>    00002-00047  -- more bootstrap code, from sector 1 track 1

Absolutely the correct thing.

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

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

> 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

Unless it sets done and not error and does so quickly, it's the wrong thing!

> 					[email-masked]

cjl