Im installing 2.11bsd on a pdp11/83 with a 2 gigabyte Scsi hard drive connected to a CMD CQD220TM.
Does anyone happen to know the maximum disk, partition, and file system sizes for 2.11?
Thanks.
Given that the last 2 DEC Storage Units I've sold have gone quite
quickly, and that every time I comment that I've not got much for
small SCSI disks, I get a flurry of emails from listmembers going
"noooooo, I missed it!", well, I'm a bit surprised there's no apparent
interest in the current listing - an RZ56 in a clean neat SEU.
http://www.ebay.co.uk/itm/271411499867
I also have a 6GB narrow SCSI Quantum, tested, working and
freshly-formatted, going for 1p. I realise that 6 gig isn't small by
retro standards, but I thought it might be of use to someone:
http://www.ebay.co.uk/itm/271412312175
--
Liam Proven * Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk * GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com * Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 * Cell: +44 7939-087884
Hello, everyone,
I am happy to report, at least so far, my RK8E/RK05 are working well
after applying the hardware patch to the RK8E that was suggested by
David Humphries, who had a similar issue some time back, and engineered
this fix.
I have successfully formatted a known good pack, ZEROed the directory
structure on RKA0: and RKB0:, and was able to do a DIRect on both
filesystems and they came back with no errors. I was then able to
successfully copy RXA0: (my boot RX01 floppy) to both RKA0: and RKB0:
with no problems. I then deleted everything on RKB0: and did a SQUISH
on it, and it was all good. I am able to create new files, I ran a PAL
assembly of the DHRKAE (Diskless RK8E Controller Diagnostic), with the
source, binary, and listing directed to RKB0:, and everything sailed
through with no problems. I have the oscilloscope hooked up to the CLK,
LOAD, and LSB of the Current Address Counter, and the transient that was
on the CLK line is GONE. Right now the system is running the RK8E
Confidence Test (which takes quite a while). So far, so good.
Before I document the hardware patch, a word of warning -- there are
quite a few different versions of the RK8E, as well as a lot of
different ECO's (Engineering Change Orders) that were made to the board
set over time. Some of the ECOs were related to trying to fix this
known timing issue in some PDP 8/e/f/m systems. The fix may not work in
all cases. Be aware of the revision level of your RK8E -- you may have
to adapt the fix if your RK8E is showing this issue. I strongly advise
scoping the Current Address Counter CLK and LOAD lines to verify that
your system is having the spike on the CLK line before trying the fix.
Also, I take no responsibility for anything that happens to you, your
RK8E, your PDP 8, or your RK05 drive, nor do I take any responsibility
for this fix working in your system. You are on your own.
My RK8E appears to be at revision level B for the board set, and it has
a number of ECO wiring on both the M7104 and M7105 boards. The M7106
board is virgin, with no ECO wiring.
The issue is caused by a timing relationship between the IOT decoder
that generates a strobe when the DLCA (Load Current Address Counter)
instruction is decoded, and the system TP3 timing signal generated by
the CPU. Depending on the timing of these two signals, a transient can
be generated on a clock line for the string of three 74161 synchronous
binary counters that make up the Current Address Counter. This
transient can cause the Current Address Counter to erroneously increment
after it is loaded with an address, resulting in a drive system that
flat doesn't work. Every disk transfer is "off by one" in terms of
where the data from the drive is transferred into or out of memory via
single-cycle data break (DMA) cycles.
The fix that David suggested is quite simple. It involves piggybacking
on a 7474 TTL Dual D Edge-Triggered flip flop to the M7105 board of the
RK8E, adding three patch wires, and cutting one trace.
I modified the patch a little to make the wiring easier for me. My
hands are kind of shaky, and it takes some real patience to do this kind
of stuff.
You will need to refer to the RK8E printset for your version of RK8E to
identify where the chips are and how this patch fits into the logic.
- First, you need to find a good TTL 7474 chip. Don't use LS or S, or
other types, just a plain 7474.
- Bend all of the leads EXCEPT pin 7 and pin 14 (GND and VCC) so that
they are 90 degrees away (outward) from the package.
- Piggy back the 7474 chip on top of the chip at E40. David's patch
involved doing this on E41 rather than E40, but I find the wiring easier
to do with the 7474 piggyback on E40.
- Solder pins 7(GND) and 14(VCC) so they connect to the pins on the E40
package. This provides power to the 7474 chip.
- Using appropriate wire, connect the D(pin 2) and CLR(pin 1) inputs of
the 7474 to E41 pin 10.
- Connect the CK(pin 3) input of the 7474 to E41 pin 9.
- Cut the trace that connects E41 pin 10 to E28 pin 12
- Connect the Q output(pin 5) of the 7474 to E28 pin 12.
Triple check all your work before trying it out in your system.
That's it. With this patch in place, the TP3 pulse is latched by the
7474, which prevents it from going low (thereby generating the false
clock signal) before the DLCA instruction is completed.
My sincere thanks to all that wrote to me or posted here regarding my
adventure in RK8E land, and special thanks to David Humphries for
noticing my original posting sounding familiar, and writing to me about
his adventure. This mailing list never ceases to amaze me with the
talents that are out there.
Best wishes to everyone,
Rick Bensene
Hi folks...
I have for auction on Ebay, a dual 8" floppy drive for a Xerox Model 820
desktop. The auction number is 111291934342. I don't have means of
testing this machine but it turns on and the drive motors spin. From
what I understand, this drive will only work with the 820? I do not have
the rest of the machine, sorry... Local pickups can also be arranged.
Thanks!
-Kurt
Here's a fun announcement ... on the second day of VCF East (Saturday,
April 5), VARx (www.varx.com) is giving 50% off all DEC items.
As if you didn't already have enough of a reason to attend the show. :)
MARCH now has a Bendix G-15, branded as a Control Data system (they
bought Bendix toward the end of the G-15's production run in the early
1960s, although as I understand it the computer was essentially
unchanged since its 1956 debut).
We began setting up an exhibit in our museum last night. It includes the
computer itself, tape drive, IBM teletypewriter, desk of the same period
and style as the Bendix original, and (not yet on display) a matching
Bendix desktop plotter.
Get some tissues ready so you don't drool on your screens. :)
http://www.snarc.net/bendix.jpg
Come see it at VCF East!
I'm hoping that someone here has some experience with PDP 8/e with the
RK8E disk controller for RK05 disk drives.
The 8/e passes all of the CPU diagnostics with flying colors. Memory
also checks out good. There are two fields of 4K core, and 4 fields of
solid state memory.
The core fields are field 0 & 1. Memory testing on both of the core
memory fields shows no faults. The system runs very cleanly...I've got
OS8 V3D on floppy and it can run for hours on end with no problems.
I have a known good RK05 drive and a number of 16-sector packs for it
that are good. RK8E and drive were tested in another 8/e system
recently, and worked fine.
Cable between RK8E and drive has been ohmed out, and it's good. Signals
going across the cable look good and clean on the scope.
The RK8E does not pass the Diskless Controller test in my system.
This is the test that uses the maintenance mode features of the RK8E to
test the controller without actually touching the RK05 drive (drive is
powered on, but in LOAD (offline) state). It goes though most of the
test, but fails in the data break tests. In these tests, the data break
is only active for one cycle, where one word is transferred to/from the
controller and main memory. All of the tests of the RK8E data buffer
test out fine. So, it appears that something is amiss in the
single-cycle data break handing...either in the RK8E, or the CPU's
handing of data break requests.
All data transfers between the RK8E and the PDP 8 are done via single
cycle data break (DMA) operations.
If I use RKLFMT to format a pack, it goes completely through the "write"
portion of the formatting without a hitch, and gets through a lot of
reads, but fails partway through the verification pass. The formatter
writes the block number of each sector as the first two words of each
sector, and fills the rest of the words with zeroes. The verification
pass just checks these two words to make sure they match. If fails when
the first word (high order disk address) changes from "0000" to "0001".
Through all of the tests, there are NO CRC errors. Seeking cylinders
and sectors work fine. It's just the "data" part of disk blocks that
gets messed up.
Using the FUTIL utility, I can successfully read and write blocks all
over the disk. I can use the "SCAN" function of FUTIL to scan the entire
disk, and it completes successfully. Thus, every sector on the disk can
be "found" by the controller without problem.
The problem symptom is that the first word of every block is duplicated
across all of the blocks. All of the rest of the words in the blocks
behave properly.
Using FUTIL, I can read in a block, change any but the first word in the
block, and write it out, then read it back, and it's fine. I can do
this with words 1 through 255 of any of the blocks on the disk.
However, if I read in a block, change the first word (word 0) of the
block, and write it out, then read it back, the first word is as I set
it to be -- but, if I read any other block, the first word is always the
same as what I wrote out.
For example, if I read in block 7, and change word 0 of the block to be
"4567", then write it out, then read any other disk block, word zero
will ALWAYS be "4567". If I then read in block 275, and modify word 0
to be "1234", and write it out, and then read back ANY (including block
7) disk block, the first word will always be "1234". I've tried this
with all different bit patterns for in word zero, and it's always
consistent.
To verify that this isn't an issue with FUTIL, I wrote some little
routines to read and write disk blocks, and the behavior is the same.
The other disk test that uses the drive goes through all of the seek
tests and writes out its test patterns, but fails on the read-back
tests.
I'm very stumped. The RK8E uses single-cycle data break (DMA) to take
data to/from the disk and transfer it directly to/from main memory
without processor intervention (other than initiating the conditions for
the DMA cycle). The RK8E signals the processor that it needs to do a
data transfer, the processor relinquishes control of the memory system,
and lets the RK8E place address and data on the memory address bus and
memory data bus to read/write the data from/to main memory. Each word
of the transfer of a 256 word disk block is done as a separate DMA
request.
One might thing that there is a problem with the RK8E, but that is not
likely, as this RK8E was recently tested in another system and worked
fine, passing all of the diags.
It's more likely that there is something amiss in the data break logic
in the CPU, however, it seems odd that it would affect only the first
word of a DMA transfer, as the CPU doesn't really know whether a DMA
transfer is the first word or the last word. It just responds to DMA
requests asserted by the peripheral.
Does anyone out there have any ideas what I could do to track this down
further? The RK8E is the only data break device I have in the system,
everything else uses programmed data transfers, so I can't try with
another data break device and see if the behavior is consistent.
Thanks in advance for any ideas as to what to do/try next,
Rick Bensene
