NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/alt/sys/pdp8/91

Text File | 1992-11-18 | 6.4 KB | 119 lines

Newsgroups: alt.sys.pdp8
Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!news.columbia.edu!watsun.cc.columbia.edu!lasner
From: [e-mail] (Charles Lasner)
Subject: Re: What I've got and what I'd like to have
Message-ID: <[e-mail]>
Sender: [e-mail] (The Network News)
Nntp-Posting-Host: watsun.cc.columbia.edu
Reply-To: [e-mail] (Charles Lasner)
Organization: Columbia University
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 19 Nov 1992 06:51:28 GMT
Lines: 105

In article <[e-mail]> [e-mail] (Jonathan E. Quist) writes:
>In article <[e-mail]> [e-mail] (
>
>My nomination for PDP-8.godhood:  Mr. Rich Karhuse.  Formerly head of
>the Northwestern CS Research Lab; last I heard, working for Bell Labs.
>I heard stories from several reliable sources that, upon discovering
>a bug in the network central systems, he would halt the machines from
>the front panel, toggle in the changes in memory and AC/L, then continue.
>(And then, of course, document the fix... :')  From talking with him
>on numerous occaisions, I have no reason to doubt the stories.
>Rich, if you're out there, many thanks.  The environment you provided
>was one of the single greatest influences on my professional skills.
>
>These kids today just don't know what they're missing.

Richard Karhuse was well known years ago to the PDP-8 world.  In all fairness,
I don't think he would put himself in the category you do, but was well known
for some really good stuff on the -8 and related peripherals.  Rich took a
bunch of us for a "tour" during one of the Chicago DECUS Symposiums around 1980
so I know all about that configuration.  It's partially based on stuff done
by others (me too), the largest being done in Atlanta by the people responsible
for documenting the early changes to Focal, 1969 emanating from Georgia Tech.
DEC actually published some of their stuff, although nothing about the
Local Area Networks of the day.  (Let's just say that at least 4 or 5 of us
simultaneously reinvented this wheel :-).  Some of us even had enough access
to carry it out in various institutions.)

Rich is best known in the "greater" -8 world for two related items:

A viable RX01 system and non-system handler that uses a kludge so that a
system can be built using the standard RX01 bootstrap in spite of the
fact that the handler format (8-bit) is incompatible with the proscribed
boot, which eventually was put into hardware.  There were other 8-bit
handlers, some produced merely to be compatible with other systems (WPS,
COS, etc.), but only Rich's was bootable.  (Part of this problem is caused
by limitations in the OS/8 system build process; in P?S/8 I had to invent
a special-purpose routine concept for initializing a system at system
generation time to overcome a parallel situation in P?S/8.)

The other thing has to do with the crux of a problem with virtually all
RX01/02 code:

Rich forced DEC to document the existence of the write-protect hardware of
the RX01, and made DEC write up the instructions to implement it in the
drive.  The RX01/RX02 pocket Reference Card page two now clearly shows
that bit[8] of the Error and Status Register means Write-Protect Error.
On drives Rich modified, etc., if you place a diskette in with the notch
area uncovered (this is backwards to newer floppies, but the identical
concept), the disk can't be written on.  These modified DEC drives do
implement this form of protection; reading the status register on the RX01
confirms the diskette is protected.

The problem is that before Rich's efforts to get the bit documented occurred,
DEC published a work of misinformation: the RX02 programmer's manual.  This
defective book claims that bit[8] of the register means "drive is RX02 type"
and is a 1 on all RX02, as if this was supposed to mean something useful.

The problem is that when you program an RX01 in 8-bit mode, you don't do
anything "special" to deal with it, yet if you want to read/write the
same single-density diskette on an RX02, you are obliged to slightly change
the interface protocol.  Instead of just sending the command with the 8-bit
mode bit set, you are obliged to wait for the transfer flag to raise, then
to send an additional byte via the XDR instruction (0000 value, but it must
be sent, and on the RX01 it must be *not* sent).  Note that in 12-bit mode,
none of this applies, so generally it only comes up in special handlers,
conversion programs such as RTFLOP and WPFLOP, etc., while most standard
DEC handlers are devoid of esoteric error handling, thus have no concern
over these matters; their code runs equally (poorly) on RX01 or RX02.

So, guided by the misinformation in the manual, virtually all programmers
who wanted to support the RX02 inserted a test for RX02, consisting of
checking for this bit[8] being a one.  But this is *not* useful information
because:

1)    An RX02 operating as an RX02 is not the only case where this bit
sets.  An RX02 emulating an RX01 still sets this bit!

2)    An RX01 with the write-protect feature implemented shows this bit
if either the drive is not ready and has no diskette mounted, or has a
ready diskette with the notch hold uncovered, and thus protected from
writing.

3)    The DSD-210 RX01 superset supports all of the above, and also has
individual drive write-protect switches that supersede the write protects
of the media on a temporary basis.

So, software intending to "trust" this bit, generally fails to function
when the hardware turns out to be other than an RX02 in native mode.

There has been tremendous resistance to these simple facts over the years,
because people keep pointing to the info in the RX02 reference manaul as
"sacred" rather than a naive mistake.  Rich Karhuse helped to dispell this
set of mistakes, and thus allowed fixes to take place in other software.

The current P?S/8 system and non-system handlers partially consist of code
defensive to this issue.  IF a drive is suspected of being a write-protect
problem, the handler tests if the drive is actually an RX02, rather than a
lessor model where the RX01-type code is possibly usual, albeit in a more
inefficient manner.

Rich's work in getting to the truth of the situation has contributed to
the overall "quality" of the RX line, including RX50's on DECmates, etc.

cjl