> Nice article up on the BBC news website about the Cipher Challenge that's
> going on today: http://news.bbc.co.uk/1/hi/technology/7094881.stm
> ... I've not been involved in that side of things, but it's been
> interesting
> watching Tony and his crew running around the last few weeks trying to get
> everything put together (there was a huge amount to do on the
> reception/intercept side of things in particular)
>
Saw that on BBC 1 news last night, would have liked a bit more info but at
least they actually covered it on national news.
Do we know how the test went and who gor there first, BBC quoting them at
finishing about the same time.
Mike.
Do not contact me, contact Patrick below:
-------------------------
I have a heathkit I think H89, not sure how to tell. Should I dump it or is it worth something to someone? If so feel free to contact me.
Patrick
Seattle WA
p_miceli at hotmail.com
---------------------------------
Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.
> Date: Thu, 15 Nov 2007 19:14:48 -0500
> From: wdonzelli at gmail.com
> To: cctalk at classiccmp.org
> Subject: Re: BBC coverage: Colossus vs. Modern hardware
>
> > AFAIK there's no transmission equipment as part of the SZ42 itself though, so
> > something would still need to be hooked between that and a giant aerial in
> > order to do the transmission; I think it was this bit that Will was interested in.
>
> No, I am interested in the thing that modulates the bitstream, before
> the transmitter. The modem, basically, not the transmitter.
>
> --
> Will
Will,
I did some fairly bizarre modem design for a downhole well logging camera, transmitting power and digital video over 5 miles of coax. I can probably answer any modulation questions you may have, or point you to the literature I used in my research and design.
Randy
_________________________________________________________________
Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmail…
On Nov 15, 2007, at 2:28 PM, Chuck wrote:
> How about ATAoAL? ATA over Aldis Lamp? Should be doable...
>
The standard should include a bridge to either Bongo drums or smoke
signals.
The smoke could be produced by old tantalums to bring it back on-topic.
On Nov 15, 2007, at 2:28 PM, Roy wrote:
> I mentioned it in here because it came up in conversation with
> somebody in the
> list a while back and they said something about the 1-2G range of
> sizes being
> particularly useful for some things, though I can't recall at the
> moment
> just what those things were offhand.
>
IRIX 4D1-3.3 seems to not like drives much over 1GB, many VAXstations
don't like drives over 1.05GB for VMS, SCSI Apollo/DOMAIN systems don't
like drives much over 2GB. I know there's more but can't recall right
now.
There should probably be a "disk size limits FAQ" somewhere to hold all
of this
Just wanted to update everyone on the status of the Montpelier, Idaho
VAX 11/750 that was rescued last month without much in the way of
included modules, except for the Systems Industries 9700
controller...and, to ask for some help.
After a little effort, I think I now have the minimum boardset required
to fire this baby up. But just to make sure that yours truly, a
complete Unibus and big-iron VAX noob, has it figured correctly, I
wanted to run my configuration by you guys before I shoot off my right
foot (which would, of course, leave me with only a wrong foot).
I've now got the following installed in the backplane:
<nothing> in CMI slot 1 (still looking for the optional L0001 FPU)
L0002 (DPM) in CMI slot 2
L0003 (MIC) in CMI slot 3
L0004 (UBI) in CMI slot 4
L0008 (PCS) in CMI slot 5
L0006 (RDM) in CMI slot 6 (optional, I guess, but came with other boards)
<nothing> in CMI slot 7 (I pulled the SI9700 from this slot)
<nothing> in CMI slot 8
<nothing> in CMI slot 9
L0016 (CMC2) in CMI slot 10
M8750 (1MB RAM) in 'extended' slots 11-18 (8MB total)
M9202 (Unibus 'joiner') in slots 19 and 20
M7485 (DZ11) in Unibus slot 21
<nothing> in Unibus slot 22
<nothing> in Unibus slot 23
<nothing> in Unibus slot 24
<nothing> in Unibus slot 25
<nothing> in Unibus slot 26
<nothing> in Unibus slot 27
M9313 (Unibus Term) in Unibus slot 28
I still don't have any mass storage interfaces (to support my RA81
and/or x2 Fujitsu SuperEagles...still looking for UDA50, Dilog DU256,
and/or Emulex UD33), but I was hoping that I have enough modules to
start testing the CPU, anyway.
I do need to review Ethan's earlier comments about properly jumpering
the now empty CMI slot 7, but I'll do that before I power up.
Does this look like a reasonable config for now, at least to start
testing the CPU?
Also...
I have successfully cobbled a cable between the onboard TU58 drive
(using external power) and a PDP-11/23+. (Yes, I could have used a PC
with John Wilson's PUTR, but the PDP was handy...the cable works either
way.) I have managed to image the four carts that were part of the
rescue. So at least I know that the TU58 is operational. They're
probably already 'out there', but for what it's worth, if anyone wants a
copy of these images, let me know...
BE-J844Q-BE VAX FORTRAN V4.4 BIN TU58 1/2
BE-M873G-BE VAX FORTRAN V4.4 BIN TU58 2/2
BE-CJ51E-BE VAX FORTRAN V4.4 BIN TU58 1/1 [help files, I think]
Systems Industries 9900 VAX/VMS Installation Package v4.0
After reading through the various docs found on bitsavers.org and
vt100.net/manx it appears that a standard set of TU58 DECtape II carts
were included with each system. Several of these carts contained CPU
and system diagnostics. I'm hoping someone has a set of these tapes
imaged somewhere that I could download and give a try.
According to the VAX 11/750 HW Installation and Acceptance manual, the
tapes with diagnostics are:
Tape 5:
- ECKAL - Cache/TB
- ECKAX - Cluster Exerciser
- ECKAM - Memory Diagnostic
Tape 6:
- ECSAA - Diagnostic Supervisor
- ECCBA - UBI/DW 750 Diagnostic
Tape 7:
- EVKAA - Hardcore Instructions
Tape 8:
- EVKAB - Architectural Instructions
- EVKAC - Floating-Point Instructions
- EVKAD - Compatibility Mode Instructions
- EVKAE - Privileged Architectural Instructions
Can anyone help me out?
Thanks.
- Jared
On Nov 15, 2007, at 3:22 AM, Chuck Guizis wrote:
>> Which reminds me of a comment I saw somewhere about the possibility
>> of having
>> a SCSI bus with more than one host adapter on it. Is that even
>> possible?
Supported on (some? all?) Alphas for clustering.
Can anyone tell me anything about the Epson BM5 floppy drive unit?
Perhaps a little description will help.
Physcially it's about the size of an Epson TF20 and has one
vertically-mounted half-height floppy drive on the front, along with a
power LED. On the back are the usual mains connector and switch and a
DB25 socket.
The unit splits into 3 main sections, PUS, controller and drive
The PSU consists of a mains transformer and a PCB cotnaining an STK7561
hybrid chip. It claims to give out 5V at 2A and 12V at 3A. I guess
there's nothing to add about that.
The controller claims to be a 'Rabbit Board'. The main chips are a Z80A,
24K of SRAM, 8K of EPROM, an 8237 DMA chip and a 7261, which seems to be
a _hard_ drive controller. And of course a lot of TTL glue. The DB25
socket is fixed to this board, it's clearly a TTL level parallel
intefave, possibly SCSI-like.
The drive links to the cotnroller by a pair of ribbon cables, 1 20 way
and 1 34 way. I'm seriously suspecting an ST506/ST412 interface -- yes,
on a floppy drive.
The drive is Hitachi FDD541. The mechancial side looks conventional, a
stepper motor postiioned (it desont _seem_ to be servo-trackedm, although
I guess it could micro-step). Spindle motor, etc seem normal to, there is
a head-load solenoid. The disks are clearly of the normal 5.25" form
factor, but I suspect of a much higher coercivity.
There's a logic board fixed to the drive, full of ICs I've never heard
off, including a 637B01X0P (Microcontroller?), and an ASIC in a PGA
opackage). The contorller interface really does look like ST506/412.
Anyone got any ideas? What was it used with, what is the host interface?
-tony
> Tony Duell wrote:
>
>> However, I am saddened by a classic computer that will never be turned on
>> again. Computers are not fine art, they are machines that should be run
>> (and for that matter, I feel that fine art should be viewed, not stored
>> in a vault).
>
> As much as Tony is a hardware guy, I'm a software guy on the other end
> of the spectrum. And yet I wholeheartedly agree with this, to the point
> where pretty much all of my hobbyist programming is done on old iron.
> It's not enough that I use my old machines; I have to make them jump
> through new hoops :-)
I agree, in principle, but there are exceptions. I *prefer* a machine to work, but some machines are of such beauty that I wouldn't part with them for the world even if they didn't work. My SGI Crimson Jurassic Classic is one such example. Even if it were just an empty shell, I'd still stick it in my living room as a side table. That monster is just too beautiful not to have on display, and my particular machine has enough of a history attached to it that it makes a historic artefact and a prime conversation piece.
,xtG
tsooJ
I was reading your thread about DDC head-per-track drives.
I had a friend around 1980 that had one of these drives which he had
obtained as surplus from the US Air Force.
It used helium atmosphere around the disks to reduce friction. The disk was
12" in diameter and spun at 33,000 RPM (not a typo), and so it would produce
considerable heat from friction if ordinary air were used, at least that's
what I heard at the time. It was intended as a substitute for magnetic core
(RAM) for mainframes. The disk latency was around 30 microseconds. Because
the driving electronics were a lot slower then, the rated random access
speed was (as I recall) 50 microseconds.
Lee