I'm curious about how cable management was typically done on the H960
cabinets when stuffed with peripherals... by DEC field engineers. As I've
racked up several peripherals for my 11/34 and tonight I was racking the
last bits I want to go with my 11/45 - the problem becomes rather obvious.
Put two RL0x's in a cab right together and you quickly realize it's a pain
cause the cables from the top one drag on the bottom drive (making it come
out too) when when pulling it out to mount platters, etc.
If you leave enough slack for the cable to go out with the drive, it'll get
caught when pushing the drive back and such. In some of the later white
"corporate cabs" I have seen (and have) spring loaded bars to ziptie the
cables to. However, I suspect this particular arrangement wasn't done on the
older H960 cabs generally - when they first came out and all.
I haven't come across much in any of the installation manuals I've seen that
really talk about routing the power and data cables in an H960 for
peripherals that slide out the front and lock on chassi-trak rails. What was
usually done historically in the field?
I can jerry rig something that will work... but I'd rather find out what was
done as installed by DEC installers at the time. I'd appreciate any advice,
pointers to manuals I must not be finding, etc.
And yes, this means I'm getting ready to revisit my 11/45 restoration. Where
I left it off, the thing was basically running (booting xxdp and running
some diags) but it had a problem with interrupts. No matter what device
interrupted, it always got a constant vector (3 or 4 or 0, I forget what).
I'm hoping Tony can direct me on how to troubleshoot that when I get back to
it. Before I start troubleshooting I need to go back and refamiliarize
myself with the box (check where I had jumpers for NPR removed, recheck all
the power supplies, move all the cards back to a sane test setup). After
that I'll be asking the wise ones here for direction :)
Jay West
> On Wed, 7 Mar 2007, Chuck Guzis wrote:
>> I never *could* figure out where the card hopper was on the
>> Advantage.
>
> No hopper.
> You have to load the cards one at a time into the card drives on the
> front. It uses special 5.25" round cards (in a square jacket), and
> permits some magnetic data storage in the spaces between the punch
> holes.
Those early 5.25" punched cards don't have the best data density, but
on the upside they beat the Apple cards (1-bit per card).
As an added feature, they come pre-punched so you don't need to mess
with them.
All "ones", though.
>Subject: Re: tools / test gear / components in the US?
>>
>> Out of interest, whereabout in the US is good (mail order) for getting hold of
>> tools / test gear and components? There's only a Rat Shack in town here, which
>> as everyone knows is utterly useless for absolutely anything :(
Digikey is one,
Mouser,
JDRmicrodevices
Jameco
I've used all of them and some others at one time or another. Ratshack
used to have Allied electonics (big supplier) but, that may have gone away.
Allison
One poster mentioned the plasma drivers keeping the array below the threshold where they would glow.
TI used to make a pair of drivers to control a plasma display. SN55500 and SN55501. Those were the military numbers, the commercial, I beleive, were 75500 and 75501.
Does anyone know if multiplexing Nixies will significantly reduce their
lifespan? Or does it in fact help versus "permanently on as needed"?
I'm not sure if it's rapid hot-cold switching that'll kill them or if it's
simply down to "on time"... (or even neither :-)
I'm reviving the Nixie-based Sudoku idea mentioned on here in the past as I
think I've found a good source of tubes in the Ukraine. Latching every digit
isn't an option (due to sheer number of ICs required), but likely failure
causes dictates how many tubes will participate in each multiplex...
cheers
Jules
> Does anyone know if multiplexing Nixies will significantly reduce their
> lifespan? Or does it in fact help versus "permanently on as needed"?
Looking at the datasheet for the non multiplexed GN4 nixie the different
cathode currents are given as ..
Cathode current 2mA
Maximum continuous current 3mA
Maximum pulse current 4mA
.. So from that I'd guess multiplexed nixies are a special breed.
Lee.
>
>Subject: Re: Copying DEC VAX set up disks rx50, help
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Mon, 05 Mar 2007 16:19:46 -0800
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>At sometime today, Allison wrote:
>
>> It's not 300 data rate it's 250!
Thats out of context. When I say 250 data rate I refer to the nominal
speed drive it was intended for (300 RPM) not the 1.2mb aberation.
I helps to know what the source media is for and in the case of DEC
the formats are limited in number used are easy to get data about
and recognize. Of course the file organization on that media can be
far more varied in the DEC cases A partial list includes (on floppy):
POS, RSX-11, DOS, RT-11, RSTS, Files-11, ultirx-11
VMS, VMS saveset, ultrix/VAX,
formats used for MIPS based systems,
OS8/78/278
DECmate WPS systems.
VT180 Robin (CP/M on RX180)
I likely missed something. However, the media if floppy based is
only RX01/2 (8"), RX50, RX33, and late in the game RX25(3.5" 720k) and
(RX26 3.5" 1.44m).
I understand reading a DD 5.25" disk on a 360rpm fixed speed 1.2mb drive
will give 300 as data rate. I tend to treat and sequester all 1.2/1.6mb
5.25 disks away from all other rates as they are usually PC application
with an exception outside the PC application space (RX33 for example).
So the PC I have for reading disks is a older 486/66 with three drives
on two controllers. The drives are standard 3.5" that does both 720 and
1.44m, 360k (48tpi FD55BV), FD55F for 96tpi DD (formats like RX50). I
do not bother with PC 1.2MB format and the only place it appears here
is DEC RX33 disks that my PDP11[Qbus 11/73 with an RQDX3/RX33) handles
as native. Even that PDP-11 is an unusual nonDEC configuration as it has
RX02, RL02, RX50/33 and RD52(2 of them) in a rack mount format.
I have Imagedisk, Fcopy, and teledisk and it runs dos/win95 for networking.
this makes for a predictable PC based system that is well behaved reading
formats like RX50. It was easier to put an old 486/66 minioard in a small
tower with all the disks as I had it and the ISA floppy controllers, NIC and
all needed. It has a small 420mb disk for local storage and programs
as that all that is needed sice with networking I can mount the selected
drive and copy from there usless it's an nonPC format.
For those times when it's not PC based there is a NS* crate with NS*
controller for hardsector two of my intelligent controllers for
8"/5.25"/3.5" formats that occur in the CP/M and NS*dos worlds.
>Well, let's see what the numbers say.
>
>360 RPM is 6 revolutions per second or 0.167 second/revolution
>300 RPM is 5 revolutions/sec or 0.200 seconds/rev.
>
>Thus, the raw capacity of a 300 RPM drive at 250Kbps is 50,000 bits
>or 6250 bytes. The raw capacity of a 360 RPM drive at 250kpbs is
>41667 bits or 5208 bytes.
>
>On the RX50, since there are 10 sectors of 5120 bytes, we have
>
>6250-5120 = 1130 bytes for gaps and ID marks, CRCs, etc. on a 300 RPM
>drive. On a 360 RPM drive, one has 5208-5120 = 88 bytes for all that
>overhead. Not considering gaps yet:
>
>There are 10 bytes for a IDAM: A1 A1 A1 FE cc hh rr nn cr cr, where
>cc is the cylinder number, hh is the head number, rr is the sector
>number, nn is the sector length code and cr cr is the CRC for the
>IDAM. To that, add the data preamble of 4 bytes A1 A1 A1 FB and a 2
>byte CRC and you have (without gaps) 15 bytes per sector or 150 bytes
>for a 10-sector track--and we're out of space already at 360 RPM
>before we can add the barest of gaps (e.g. 12 bytes of 00 preamble
>for the IDAM, 12 bytes of 00 preamble before the DAM...
>
>You just can't do it at 250Kpbs and 360 RPM. Heck, 10x512 is a
>fairly tight fit at 300 RPM.
>
>Cheers,
>Chuck
I agree! The trouble maker is the interrecord gaps when added to the data
fields and other "position" fields like IDAM space becomes very tight.
DEC solved this partially by truncating the end of track gap and the
Index gaps making it harder to read with a FDC that was designed
to expect them.
Allison
>
>Subject: Re: Copying DEC VAX set up disks rx50, help
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Mon, 05 Mar 2007 14:22:39 -0800
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 4 Mar 2007 at 18:00, Allison wrote:
>
>> Wrong. The RX50 format and RX33 formats are very differnt...
>
>Ah. So an easy accommodation is to declare a 360RPM 1.2MB drive as a
>1.44MB 3.5". That keeps the 250Kbps data rate for low density while
>the drive keeps spinning happily at 360 RPM. There's still the issue
>of the missing IAM gap, but some National chips (8473 IIRC) seem to
>be a bit more tolerant.
>
>Cheers,
>Chuck
DEC did do 3.5" formats those wer RX25(720k) and RX26(1.44m) and they did
appear on later uVAX3100s.
Allison
While repairing our VT11 that hangs the Unibus as soon as you point the
light pen to the high frequency fluorescent room illumination (which makes
playing lunar lander a pain) I've discovered that the schematics of the
M7014 board (bus control & bootstrap) as found in the GT40 engineering
drawings (from bitsavers) do not correspond to our board (a M7014-YA).
The document number for the M7014 board is D-CS-M7014-0-1.
Does anyone have the document numbered D-CS-M7014-YA-1 in electronic form
(or even the complete VT11 engineering drawings)?
Christian
> Personally I find I sometimes get lost in the archive (via the web interface)
> though as a filename often doesn't obviously correspond to a document title.
The file naming has evolved over the 7+ years. In general, anything new is being
added with <manual part number> <title> <date>
This started on a system with 32 character file names, so <title> was ruthlessly
truncated, and as you noticed, <title> wasn't always the document title.
The worst problem with the current arrangement is file renaming and rearrangement
of the heirarchy. I'm not sure if the mirrors reflect these rearrangements.
In general though, it seems to serve it's purpose, so I'm not inclined to spend
a lot of time adding database functionality to it.
I've been working on a MUCH harder problem on how to organize the CHM digital holdings,
of which the bitsavers archive is a fairly tiny part.
Richard wrote:
> "Some day in the future" features
> - extract first page of the PDF as an image and link with a
> thumbnail
I have done things like this in the past and it is very straightforward
with e.g. PDF::API2 (one of my favorite Perl modules) or even just
ghostscript.
Somebody else mentioned databases... properly done this could be quite
handy. But the existing directory hierarchy (multi-level) really is more
amenable to the actual needs than any database system (which
unfortunately tend to "flatten" the structure).
Flattening the structure is useful for some things, but only if you
then "blow it back up" into a hierarchy. For example I could imagine a
directory of 3rd-party-DEC-compatible stuff that softlinks back into the
manufacturer's directories. This is NOT a flat structure... "A maze of
twisty passages all alike" is a better analogy!
Tim.
Hello,
I have two Meiko Computing Surface nodes I'm hoping to soon finally get
round to restoring. Removal of dust, cobwebs and rust is one thing, but I
sadly don't have any software for them, e.g. 'MeikOS', CS Tools, link
adapter drivers etc.
One is a 1st generation CS with boards filled with transputers, a
host/monitor board, RAM card and gfx card. Also have a PC ISA link adapter
and a connecting cable made from something akin to miniature flat twinax
(well the links did run at 10Mb/s).
The 2nd node is a later CS/i860 (aka Concerto), which again has
transputers but also as the name suggests i860 CPUs, and a module which is
a Sparc 1+ front end processor. Sadly the HDD had died and so I couldn't
recover the SunOS 4 install along with the kernel bits for the link
adapters and any other platform software. Pretty sure the NVRAM has had it
too but that is the least of my worries...
If anyone could help locating any Meiko software else just point me in
the right direction it would be very much appreciated.
Regards,
Andrew
----------------
Andrew Back
a at smokebelch.org
Jules wrote:
> I suspect the main problem with any of this is that
> bitsavers need mirror sites - and any introduction
> of a database on the primary site means that the
> mirror sites need to use the same database and
> the db contents need to be kept
> in sync :(
Don't make it any more complicated than it has to
be - a .CSV file would be perfect and anyone could
use it with "grep" or just the find function in their
browser or do cgi-bin stuff with Perl on it.
Tim.
Could somebody remind me of a source for proper replacement bulbs for the
RL01/2 and RA8x drives? Sorry if this is a repeat question - I was pretty
sure it had been discussed before, but I couldn't find an answer.
BTW, the RL0x and RA8x bulbs are mechanically similar, but they're
definitely not the same bulb.
Thanks,
Bob Armstrong
Try here http://bitsavers.vt100.net/roytron/
Tell me if you want to sell one it does not need to be working
My father was the inventor for this unit (see US Pat. 3201570 - Filed Dec
27, 1961)
Jeff Perez
Date: Mon, 05 Mar 2007 21:34:19 -0800
From: "dwight elvey" <dkelvey at hotmail.com>
Subject: RE: Multiplexing Nixies
>>From: Jules Richardson <julesrichardsonuk at yahoo.co.uk>
>>
>>Does anyone know if multiplexing Nixies will significantly reduce their
>>lifespan? Or does it in fact help versus "permanently on as needed"?
>>
---snip---
>Hi
>It is not a good idea to multiplex Nixies.
<snip>
---------------------
Well, good idea or not it was certainly common practice. Some info at:
http://wps.com/archives/Burroughs/index.html
(N101 & N102)
mike
--- dwight elvey <dkelvey at hotmail.com> wrote:
> (...) I've seen it a lot on older radios. It is easy to spot, the metal
> is all expanded and crumbles.
That condition (called "Zinkpest" in German) is also well known (and loathed!) for attacking the rotor disks in some types of old pinwheel calculating machines, especially those made in GDR and Russia.
So long,
--
Arno Kletzander
Stud. Hilfskraft Informatik Sammlung Erlangen
www.iser.uni-erlangen.de
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
> Does anyone know what PROM/EPROM types this machine will
> program? Is it able to do 1702A's ?
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=190088001102
It is totally dependent upon the programming module plugged in.
Prior to the Unipak, every prom family had its own adapter
socket adapter 715-1318-1 doesn't jump out at me as a known type
you can try contacting the seller to see if there is an adapter
table in the manual, though it has been my experience that sellers
will rarely respond to such questions.
I've hacked together an RSS feed for the 50 most recently added PDF
files to bitsavers based on pdf/Whatsnew.txt.
<http://www.xmission.com/~legalize/vintage/bitsavers.xml>
I'd appreciate it if some other people would subscribe to this RSS
feed in their web browsers/RSS readers and let me know how well it
works.
Features:
- parses out the file path from pdf/name/name/name.pdf to
'name :: name :: name', hopefully trying to make it more legible.
- Takes anything after the first space on the line to be a
description of the file. These haven't been added to the .txt
file for some time, but if they're there, I'll pick them up.
- adds categories based on the first name in the path, i.e. the
company name folder on bitsavers
- includes the PDF itself as a linked attachment (through the
vt100.net mirror)
- is updated once an hour
- is generated from a one page perl script
"Some day in the future" features
- extract first page of the PDF as an image and link with a
thumbnail
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Cathode poisoning in nixies is caused by them being left on the same
digit for a long time, usually days or months. Consistently running them
on the same digit (first digit in a 12-hour clock, first digits on a
frequency counter that doesn't blank unused digits) will also cause
relative darkening of the adjacent cathodes, and occasionally some
sputter will actually cause an internal short circuit which may or may
not ultimately destroy the tube. Multiplexing should extend the life of
the tubes. Running nixies at less than their rated current will increase
their lifespan, and running them over-current for shorter periods will
often rejuvenate them.
Regards,
Micah Mabelitini
Your OS depends on the keyboard. HP 400s were the "hybrid" models made
after HP acquired Apollo, so from the factory they were set up to run
either HP-UX (9 or earlier) with a HP-HIL keyboard or mouse, or
DOMAIN/os (Aegis) with a Domain keyboard. Switching between the two
requires keyboard/mouse swap and setting one value in the NVRAM.
I've only used DOMAIN on my 425, since HP-UX of the early '90s has been
described as not spectacular. SR10.4 works well, and with the y1k997
patches it seems to tick along just fine in the 21st century. DOMAIN is
neat since it's so network-transparent and very unusual, but with the
BSD or SysV environments the learning curve is not nearly as big as
with the Aegis environment.
Of course, NetBSD can be run on them with a HP-HIL keyboard setup as
well, but I think it's pretty evident which camp I'm in. Bear has some
manuals on his site (www.typewritten.org)
Scott
thanks Richard!
> Takes anything after the first space on the line to be a
> description of the file. These haven't been added to the .txt
> file for some time, but if they're there, I'll pick them up.
If someone wants to add the descriptions, that would be great. I should
do it when I add the entries, but..
