Subject: Continuing saga, boot from RX01

From: "Douglas W. Jones" <[email-masked]>
Date: Tue, 8 Nov 94 10:02:19 CST

I've verified with CJL that the RX01 boot code I have loads a good
(albeit antique version of the) OS/8 system handler for the RX01.
This handler includes startup code to write 8 consecutive pages from
core location 00000 to disk record 33 (octal) and then read 8 pages
starting at disk record 7 to the same core location.  Then, the
final step is to jump to 00400 (start of second page).

This is promising, but I've done a bit of disassembly of the stuff
it pulled in, and it looks wierd:

00400: 5705      JMP I  0505

00505: 1005

In what follows, the code decides whether to do something depending
on uninitialized memory in field 1.

01005: 6211     CDF 10
       2477     ISZ I   0077	This increments an uninit'd location
       5212     JMP     L	  if uninit'd loc was 7777, go to L
01010: 1117     TAD     1117      (it gets the value 7420)
       3022     DCA     0022	  put it somewhere in page 0
01012: 6201 L,  CDF 00		Now go do move

What follows is a loop that tries to move 4K words of field 0, including
itself.

01013: 1413 BL, TAD I   0013	Location 13 is initially 1076
       3414     DCA I   0014	Location 14 is initially 7771
       2021     ISZ     0021	Location 21 is initially zero.
       5213     JMP     BL      End up moving a full 4K!  Why bother?

So how does this terminate?  Well, note that it tries to overwrite its
loop control variables!

   M[1077 .. 1104] goes to M[7772 .. 7777]
   M[1105 .. 1120  goes to M[0000 .. 0013]  changes the src addr to 5330
   M[5331]         goes to M[0014]          changes dst addr to an
					    uninitialized value!

So, this code goes wild, overwriting random chunks of memory with strange
stuff.  I think I've got my hands on a random chunk of code that's way
out of context.

Two possibilities remain.  Either my disk image is bad (it was once a
bootable disk, but the code pulled in by the boot sequence has been
clobbered), or something very obscure is wrong, allowing the boot
sequence to bring in the system handler but not allowing the system
handler to bring in good stuff.

					Doug Jones
					[email-masked]

---

From: Charles Lasner <[email-masked]>
Date: Fri, 11 Nov 1994 20:19:02 -0500 (EST)

> final step is to jump to 00400 (start of second page).

That's the standard OS/8 opening when you start at 07600.  Note that 
starting at 07605 avoids the writing out of 00000-01777 and just reads in 
the keyboard monitor code over 00000-01777 that resides on records 7 and 
following, etc.

BTW, the handler itself deserves a little historical notes:

The first generation of the 8K RX01 handler has the dubious distinction 
of being the first and only DEC-supported *non*-handler, i.e., it didn't 
work!  In point of fact, the handler couldn't be trusted to write!

The reason is this:  When the handler retried errors, it lacks the 
sophistication to even know what context it's in, so it blindly does the 
INIT operation (67x7) which among other things does a self-test.  The 
problem is that when writing, the buffer must already contain the user's 
buffer data about to be written out.  But the self-test instead 
substitutes track 1, sector 1, drive 0's contents (in 12-bit mode)!!  
Thus, if a write operation ever retried, then succeeded, the write causes 
the wrong data to be written out, and returns with no indicated error!!!

Of course, if the data were verified (virtually never done in OS/8 
programs!) it would reveal the problem.  During the heyday of this 
handler, I personally got zapped by the problem.  A file obtained at a 
DECUS symposium contained a sector whose contents were part of the OS/8 
handler, a likely contents of track 1, sector 1 :-(.

Reads deserve retries, else the soft error rate becomes the hard error 
rate.  On floppies, this is lame, since it's the nature of the beast for 
the soft and hard error rates to be quite different, etc.  Yet, the 
handler had a retry count of 3 for reads that was fine, but fatal for 
writes; they become untrustworthy!

Apparently, this early handler was dumped in favor of the one Doug is 
attempting.  This handler doesn't retry, thus soft error rate= hard error 
rate for reads, but writes have to succeed reliably, since the handler 
will always take an error return on any problem.  Perhaps quite lame, but 
at least it's a handler by definition!  (The call's result never lies; 
the only problem is the increased likelihood of reporting an error return 
on an error that had it been retried, perhaps would have abated, etc.)

Later versions of RX handlers all require 12K systems.  In return for 
this, various features are added, such as proper retry that is reliable, 
since the buffer gets reloaded before a write is retried.  (But there 
isn't enough room for selective error handling, thus all OS/8 handlers 
are lame in this department!  Only P?S/8 bothers to sort out the correct 
notion of error recovery consistent with the actual problem, and thus 
avoids the repeat-cycle parity error that won't clear syndrome, etc.)

> it pulled in, and it looks wierd:

I would suggest that since the handler is viable at that point, you can 
toggle in some test calls to 07607 to attempt to read in some stuff we 
can verify, etc.  For example, call the handler to read in logical 
records 0001-0006 to see if it resembles a directory.

cjl