> Date: Tue, 1 Feb 2011 12:22:11 +0100 (CET)
> From: Christian Corti <cc at informatik.uni-stuttgart.de>
> Subject: Re: OT: american vs european 220
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <alpine.DEB.2.00.1102011217160.10259 at linuxserv.home>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> On Mon, 31 Jan 2011, Tony Duell wrote:
>> Taht wouldn't work in Europe (since the 2 sides of the 230V mains are not
>> balanced about ground), and anyway AFAIK making the protecive ground wire
>> carry any current under normal conditions is totally forbidden.
> In new installations, maybe. But many older houses have just that, they
> use the neutral wire as protective ground (called "klassische Nullung" or
> TN-C system as opposed to a TN-C-S system, see
And in some places they still have the single wire distribution systems
where the 'real' earth/ground is the return:
Date: Mon, 24 Jan 2011 11:39:41 -0800
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: CDC/MPI Wren II HH (94205-51) drive manual
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4D3D64FD.13298.6DC0FC at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On 24 Jan 2011 at 10:09, Chuck Guzis wrote:
> I have a Wren II manual, but not sure about the interface. I'll check
> later today.
I'll be darned--I found it. 77738035, Rev. H, April 1986.
"This OEM Manual 77738035 provides the basic information and
instructions for installing and operating Control Data WREN II Disk
Drives; Models 94151, 94155 and 94156. It also provides information
to aid in servicing those parts of the drive external to the sealed
Do you want me to scan and forward the whole thing to you? It's not
terribly long, only about 40 pages. Or was there something specific
that you were interested in?
I've got the Product Specification Manual (77715909-C, May/85, 61pp) for
that CDC506 (ST506) 94155 series (and an opened drive as a piece of "art"
beside my desk), but those are FH drives so I don't know how relevant it'd
Had another ADM3a come in, again with severe screen rot.
Unlike the first time i now have successfully separated the faceplate from the CRT.
Question is of course how to get it back on again.
Anybody successfully done this ?
I know screenrot has come up often here, but I do not believe someone presented a working solution yet.
As the subject says: are there any EDC/ECC code experts hanging around
on the list?
I'm working on implementing the 4-byte (32-bit) ECC code Western Digital
used on the WD2010 Winchester HDD Controller IC. This appears to be an
implementation of the ECC scheme explained in section 7.6 of National
Semiconductor's "Disk Interface Design Guide and User's Manual" (appnote
It looks like the ECC scheme is based on running a CRC forwards over the
data to produce a 32-bit CRC, which is used to validate the data in the
same way the 16-bit CRC validates the IDAM. Error correction apparently
operates by running the CRC in reverse using an "inverse polynomial". I
can't see how this could work -- isn't a CRC by its very nature a
The application note calls this a "Glover 140A0443" code, but doesn't
bother to reference any papers, books or similar on the subject. There's
an example on how to program NSC's controller chips to use the code, but
nothing on the mathematical background behind it. For instance: how does
it work, and why is the maximum correctable error burst 5 bits long?
Does anyone recognise this polynomial?
x^32 + x^28 + x^26 + x^19 + x^17 + x^10 + x^6 + x^2 + 1
aka. x^32 + x^28 + x^26 + x^19 + x^17 + x^10 + x^6 + x^2 + x^0
It's not a standard CRC32 polynomial (according to Das Wiki), and I
don't *think* it's a Fire code... though I've been looking for the
original paper on those (P. Fire, "A class of multiple-error-correcting
binary codes for non-independent errors". Sylvania Reports RSL-E-2,
Sylvania Reconnaissance Systems, Mountain View, California, 1959) and
haven't had any success -- a few hits on Citeseer, but it appears all
copies of the paper have vanished into thin air.
What I'd really like to find out is more about how this algorithm
works... a model implementation (e.g. in C, Python or similar) would be
extremely useful, but at this point even a basic worked example ("here's
a chunk of data, now watch what happens if we flip some bits, and here's
how we fix it") would be extremely useful...
classiccmp at philpem.me.uk
"High-Speed Computing Devices" is a report on the state of computing
machines in the US that was published in 1950. I have first edition copy but
it is also available on the Internet Archive.
My favorite part is "Table 10-1, Large-Scale Digital Computing-Machine
Projects in the United States." It lists all nine operational machines with
eleven more under construction. (Pages 214 and 215, the DJVU file is offset
14 pages so this starts on page 228.) The description of the ENIAC starts on
The book describes the computing circuitry in detail. You can build your
own accumulator with a handful of vacuum tubes.
Anyone have a dead model M or some keycaps around.
I rescued this one from a recycle pile and it works fine.... a few key
caps were off it
and I found them, but missed the fact the num lock cap was missing, and
pile has been hauled off.... so no looking for it now.
Let me know if you have a Num Lock key cap.
I've just this second got my DiscFerret talking to an ST506 hard drive.
Specifically, a Control Data / Magnetic Peripherals 94205-51 "Wren
IIHH", apparently also known as the Seagate ST253. 989 cylinders, 5
heads, 17 sectors. It also seems to bear an uncanny shape-and-weight
resemblance to a breezeblock...
But anyway, I digress. First, the pretty pictures:
The log-histogram shows a very distinctive MFM timing pattern (three
peaks at 1T, 1.5T and 2T), and the scatter-graph shows that the timing
data is split into 17 distinctive segments: the sectors.
So what's the catch?
1) The DiscFerret PSU doesn't have enough grunt to run a Winchester
drive (or at least a 5.25 half-height like the Wren) and a 3.5in floppy
drive at the same time. This is an academic point, because you need an
adapter board to hook the 'Ferret up to the ST506 drive, and you can't
have both a floppy drive and the adapter plugged in at the same time.
2) I haven't got the software decoder working. Yet. I need to play
with the sync-word scanner -- the WD2010 controller chip does strange
things to the IDENT flag byte. Adding a few don't-care bits to the mask
and implementing a 16bit CRC should sort this out. The data looks good,
but I can't prove it until I make MagScan read it.
I've made a few modifications to the Microcode too:
- The acquisition and RAM Write clocks have been increased to 100MHz.
This provides a bit more timing resolution, and makes it a little easier
to convert from a timing count to an absolute time (especially if you're
reading a timing histogram and don't have a calculator).
- The data separator has been partly re-implemented. I've ditched the
shift-register counter in the DPLL and replaced it with a parameterised
binary counter. Now the sync-word detector can run from almost any
reasonable input clock rate. I've got it running at 40MHz at the moment
(it used to run at 32MHz).
- A FIFO has been added between the data sources (acquisition module
and parallel port) and the memory write controller. I did this because
there was a risk that a timing value could be lost if a transition
occurred within 5 or 6 clocks of a RAM write (the previous transition,
or a counter overflow).
Still to do:
- Make the current acquisition abort if the FIFO overflows
- Decouple the acquisition and memory-write clocks. The RAM has a
10ns access time (i.e. 100MHz), and I'd like to see if the acquisition
engine can be made to go faster. This should work as long as it doesn't
get hit with more than 256 fast transitions in a burst...
The DPLL change came about because the FPGA I'm using only allows the
on-chip PLLs to be driven from a global clock input, and only one PLL
can use the GCK. So for each PLL you want to use, you have to provide a
separate GCK... This is a fairly easy board tweak (you bridge two pins
on the FPGA with wire or solder), but it'll break backwards
So a good day was had by all, it seems :)
The new Microcode is in the usual place (the Mercurial repository). I'll
push a compiled version into the Firmware repository in the next couple
classiccmp at philpem.me.uk
On Sat, Jan 29, 2011 at 12:45 PM, Michael Thompson
<michael.99.thompson at gmail.com> wrote:
> I pulled two RA70 disks from a pair of VAX-3500s that I have. By some
> miracle both drives spin up and go ready when the Operator Control
> Panel is connected. I was thinking that one of these drives would work
> nicely with the UDA50 disk controller in the 11/44 until I can get the
> RA81s sorted out.
> These drives are supposed to work with the Operator Control Panel.
> There is a button on the back of the drive that says Unit Number
> Accept. I pushed the button both before and after power up, but the
> RA70 does not spin up.
> Anyone have a manual for this drive or know how to get it work without
> connecting an OCP?
I have used RA7x drives with a KDA50 (M7164 / M7165) without an OCP
attached to the drives. It has been a while now. I don't remember
there being anything tricky about getting it to work. I was probably
using either an RA72 or RA73. I'll have to look and see if I have an
RA70 to try.
I don't remember if I ever found any RA7x drive manuals other than
this one on the net, which doesn't have all that much useful
RA7x/SA7x Pocket Reference Guide, Order Number EK-RSA7X-PG-002