3 Apr
2008
3 Apr
'08
8:30 a.m.
On Apr 3, 2008, at 1:32 AM, tiggerlasv at aim.com wrote:
I guess my first question would be -
If you're running on an 11/83 under RSTS/E,
why WOULDN'T you want to use 22-bit addressing?
Well that was my thought...I've never used a 9-track drive on a 22-
bit system running RSTS/E, so I was guessing a bit. I thought
perhaps the driver might implement bounce buffers if the board was
operating in 18-bit mode.
Later last night (in total screaming frustration trying to get at
least ONE of my five 9-track drives working) I discovered that the
driver identifies the board correctly and says "extended features
disabled" in the HA LI output, then init disables the device.
Surely you're not "wasting" a perfectly
good 11/83 on V6C or
V7.0 ? ;-)
No way. RSTS/E is, by far, my favorite PDP-11 OS...but only v9+.
I'm definitely not a fan of the pre-v9 RSTS/E releases. Most of my
early computer knowledge was gained on a v9.4 system.
You'll note that if you do a HAR LIST under RSTS/E
V8.0 or above,
it will flag this drive as "extended features enabled", indicating
that
it can use the full 22-bit address range.
Yup, I found that out later last night. Of course the drive
doesn't actually *work*, but that's a different (extremely
irritating) matter.
Set 18-bit addressing, in which case RSTS/E (V7.0)
will see the controller as a TS11, which will ONLY be able to access
256K of memory without modification to the device driver.
(V8.0 and above might (properly) recognize it as a TSV05 either way,
however, the "extended features" will be disabled, and it will only be
able to access 256K of memory.)
I've got 4MB of RAM in the system; init disabled the device when
it was set for 18-bit addressing. (it's running v9.5)
It seems that all of my 9-track drives are nonfunctional now. At
least two of them worked when put into storage; I'm very displeased.
I've given up on them for the moment and am going to try to get a
TK50 or TK70 working in the system.
-Dave
--
Dave McGuire
Port Charlotte, FL