> -----Original Message-----
> From: Fred Cisin (XenoSoft) [mailto:cisin@xenosoft.com]
> Before we get into arguing about "better" configurations, ..
> Does anybody know what the f he's asking about?
> Is his machine broken?
> Is it working perfectly, but he doesn't know how to "access" it?
I assumed he was asking for free system software to use with it
since he for some reason couldn't get the original installation of
windows to work. Hence my original answer, but you're right, it's
incredibly ambiguous. :)
> Is it the machine that he's writing with?
> Perhaps fixing the shift key on his active machine should be a higher
> priority.
Indeed. I suppose it could be worse -- his message could have read:
PLZ SEND ALL CODES!!!!
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
One assumes all the producs of corrosion are salts .
Some however will be oxides and van be very conductive.
I've also seen new boards contaiminated with fungal materal
{assembled and washed in old mehieco} that had all manner
of seemingly intermittent problems until rewashed in clean
water and dried.
Allison
-----Original Message-----
From: Sridhar the POWERful <vance(a)ikickass.org>
To: Doc Shipley <doc(a)mdrconsult.com>
Cc: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Tuesday, April 16, 2002 12:38 AM
Subject: Re: cure equiepement that was in the rain... best practices???
>On Mon, 15 Apr 2002, Doc Shipley wrote:
>
>> > The salts that are the endproduct of corrosion usually aren't
conductors,
>> > but that wouldn't prevent them from interfering with the operation of
the
>> > board.
>>
>> Well, something's interfering. I get a persistent B_CACHE failure on
>> startup.
>
>It might be something like corrosion int the middle of a contact, if you
>have any socketed chips. Or omsething like that.
>
>Peace... Sridhar
>
> Date: Sat, 13 Apr 2002 19:32:05 -0700
> To: classiccmp(a)classiccmp.org
> From: "Zane H. Healy" <healyzh(a)aracnet.com>
> Subject: DELQA/DEQNA Cab Kits question
> Sender: owner-classiccmp(a)classiccmp.org
> Reply-To: classiccmp(a)classiccmp.org
>
> I should know this, but can't remember, are the Cab Kits for the DEQNA and
> DELQA interchangable?
In one word, yes. Of course the little label on the panel won't change
to reflect the card change on the other side.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
> -----Original Message-----
> From: pat(a)cart-server.purdueriots.com
> Amazingly enough, you can do this with the *nix mkisofs program by
> specifying the files to burn on its command line. The order that you
> type them is the order that they get put into the ISO image IIRC.
> Amazing how easy stuff becomes when you drop Windoze :)
I _suppose_ you could port mkisofs to NT if you like... ;)
Honestly, I wouldn't trust even the most stable version of windows
(that would be NT 3.51...) to burn CDs for me.
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
RE: 2114s
Over the years i'd seen A higher than normal {2102 as comparison}
failure rate. So I had the opportunity to do some checking on why.
NOTE: the 2114 never had as good a failure rate as say 2102 or
other 1k designs and the next generation of 16k static parts were
substantially different with better failure rates.
2114s common failures:
Delayed stress damage due to ESD. Common failures are address
inputs.
Missing bit, usually a failed output due to either ESD or excessive
IO loading.
bond failures (works when hot or cold) most of those are plastic cases
and likely due to cleaners causing internal plastics to expand and lift
a bond {usually during board production}. Other likely causes, heat!
Ceramic devices seems and generally were more reliable.
The CMOS versions 6114 (nec D444) were more relaible, though ESD
induced stress failures were a major factor.
In the early 80s it was not uncommon to visit a site and NOT see proper
ESD protocal used when handeling MOS or CMOS devices. In most
cases getting the production people using would often see a substantial
drop in early failures{infant mortality}.
Allison
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Monday, April 15, 2002 10:24 PM
Subject: Re: TTL computing
>>
>> That doesn't seem to me as a failure of the 2114, but, more likely, a
failure
>> in the update logic in the refresh memory circuit, possibly in a buffer
enable
>
>I was about to point out that the 2114 is an SRAM and doesn't need
>refeshing, but then I realised you were talking about the video refresh
>circuitry.
>
>> or a shortage of hold timing on the data with respect to the write line.
>> What, exactly, do you mean by "dud" character? If it appears exactly in
the
>> middle of a 2Kx8 memory array, it could, indeed be a stuck bit, and if it
runs
>> from the middle to the top/bottom that would be a candidate for a failed
>> memory bit also. If, however, it moves horizontally, or moves outside
the
>> range residing in a single device, it's clearly something else. Have you
>> tried moving the device around in the video memory array? It seems to me
that
>
>Last time I had a problem with a 2114 in a video RAM array, it appeared
>that the RAM had lost an address input. Writing a character to a location
>in RAM would affect the top 4 bits (IIRC) of a character 2 locations
>away (or something like that). It was clearly the RAM because swapping it
>over with the one next to it caused the fault to move to the bottom 4
>bits. And a new RAM cured the problem.
>
>> there have to be at least two of them, and the "dud" character, whatever
that
>> is, should follow the device.
>>
>> 2114's are just about as plentiful as any device of the era could be.
You
>> should not have a problem replacing it. I don't know what the problems
of
>> sending hardware from the U.S. to the U.K. are, but I'm willing to send
you a
>
>Very few AFAIK. I don't think I've ever had a parcel declared as
>'obsolete computer parts' even inspected by customs. Of course this might
>have changed now with the increased risk of terrorism (although we've had
>terrorist activity for years over here :-().
>
>One tip I was once told. Pack chips in transparent anti-static bags (and
>put an anti-static warning label on them. Customs officers are not
>totally clueless and won't open such a bag if they can clearly see what's
>inside (and provided the contents are what they're supposed to be, like
>'computer parts' (chips)). But if you pack the chips in an opaque bag,
>they might open it (to ensure it doesn't contain drugs, say), and might
>not know how to handle the chips without damaging them.
>
>-tony
Would this improve the ~1 hour time it takes for me to see the
messages that I post to this list?
--- David A Woyciesjes
--- C & IS Support Specialist
--- Yale University Press
--- mailto:david.woyciesjes@yale.edu
--- (203) 432-0953
--- ICQ # - 905818
Mac OS X 10.1.2 - Darwin Kernel Version 5.2: Fri Dec 7 21:39:35 PST 2001
Running since 01/22/2002 without a crash
> ----------
> From: John Boffemmyer IV
>
> Jay, I've worked with Endymion's MailMan 3 - great setup and very
> flexible.
> You will really like it once you have it in place. Plus, you can even
> customize all of the buttons/images, etc. This way, if you don't like that
>
> default layout, in a few minutes, you can have it look any way you want.
> It
> also allows for integration of images into posts, etc. for realistically
> handling the common need to include an image or two of whatever is being
> discussed (IE: RS6000 board specs/traces, C64 diagram, etc.).
> - John Boffemmyer IV
>
> At 12:42 PM 4/12/02, you wrote:
> >Greetings;
> >......
> >In order to address the previously discussed issues of [offlist] tags and
> >html rejection, as well as because of a lot of other nifty features, I'm
> >also considering using mailman. It gives a wonderfull web interface for
> >those that want to do their subscribes/unsubscribes & the like on their
> own.
> >Yes, it still supports email subscribtion requestions. Basically, it
> gives
> >me a lot of flexibility and options that majordomo doesn't. Not sure
> about
> >this all yet.
> >
> >Thanks!
> >
> >Jay West
>
On Apr 15, 14:24, David Woyciesjes wrote:
> That's close, but what I'm looking for clips around the rails, not
> into the hole, which is round. This looks almost exactly like it, at the
> bottom of the page...
> "Palnut Multi-Thread U-Nut"
> http://www.tt-ec.com/showcase/retaining/palunut.html
DEC (and Sun, etc) used something like that but with a real nut welded (?)
onto the clip, like the diagrams at the top of
http://www.tt-ec.com/showcase/nutbolt/utypenrcat.html
I've always known the ones DEC used simply as Tinnerman nuts. The other
type used by DEC is like a strip of spring steel wrapped round the nut and
then formed into a springy clip that clips round the rails (sorry, can't
find a picture). The correct size for rack screws is 10-32 UNF, rather
smaller than any of the ones on the PalNut page.
> > From: Carl Lowenstein
> >
> > You would be happier with the type of fastener that uses real machine
> > screws rather than the sheet-metal type screws that some racks have.
> > There is a nice picture of them on the Tinnerman Web site at
> >
> > < http://www.tt-ec.com/showcase/nutbolt/nutretcat.html >
The picture of a retainer nut (which happens to be made by Tinnerman in
this case, but isn't what I'd call a "Tinnerman nut") at the top of that
page is of what everyone over here calls a "caged nut". They're used on
european racks, which have square holes not round ones; the normal size
takes an M6 screw (DEC screwss are 10-32 UNF, which is very similar to M5).
--
Pete Peter Turnbull
Network Manager
University of York
Entirely likely, I did get a lot of stuff from MMI over the years
and some of the other related companies. I still have and use
PALASM and PALASM90.
Allison
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Monday, April 15, 2002 3:10 PM
Subject: Re: TTL computing
>It may, in fact be about the same as my old version. I got mine from
MMI back
>when THEY were the ones pushing FPGA technology.
>
>Dick
>
>----- Original Message -----
>From: "ajp166" <ajp166(a)bellatlantic.net>
>To: <classiccmp(a)classiccmp.org>
>Sent: Monday, April 15, 2002 8:13 AM
>Subject: Re: TTL computing
>
>
>> Xact, and older, much older version. I'd get the version number
>> but the termcap file is OTL and I'm working on something else
>> right now. That and a few bits provided by Tim olmstead to help
>> with simulation. He was the one that got me into using them.
>>
>>
>> Allison
>>
>> -----Original Message-----
>> From: Richard Erlacher <edick(a)idcomm.com>
>> To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
>> Date: Sunday, April 14, 2002 11:46 PM
>> Subject: Re: TTL computing
>>
>>
>> >Do these tools have names, Allison? My old DOS-based tool for FPGA
>> >development, from MMI, was called XACT, and that's what was intended
for
>> the
>> >2000-series devices. A later version supported the 3000 series.
>> >
>> >Which tools do you use for developing both 2000 and 3000-series
>> bitstreams?
>> >
>> >Dick
>> >
>> >----- Original Message -----
>> >From: "ajp166" <ajp166(a)bellatlantic.net>
>> >To: <classiccmp(a)classiccmp.org>
>> >Sent: Sunday, April 14, 2002 8:28 PM
>> >Subject: Re: TTL computing
>> >
>> >
>> >> From: Richard Erlacher <edick(a)idcomm.com>
>> >>
>> >>
>> >> >Which tools are you referring to, Allison?
>> >>
>> >>
>> >> OLD tools, as in dos based.
>> >>
>> >> >I've found that the tools I once used with the old (pre-1990)
2064's,
>> >> don't
>> >> >work with the 3000-series, and, though I have some 3000-series
parts
>> >> (which,
>> >> >back when I bought them, cost about $200 each) I've not figured
out a
>> >> way to
>> >> >program them using the old XACT or the more recent "Foundation"
>> >> software.
>> >> >They clearly are no longer supported with current software.
>> >>
>> >>
>> >> Neither have I. I also have the Synario package too. They phased
out
>> >> the tools for the 2064s a long time ago.
>> >>
>> >I have Synario for the Atmel devices. It's a Windows-based tool
based,
>> I
>> >think, on a tool set originally cooked up by Data I/O.
>> >>
>> >
>> >
>>
>>
>
> From: Hans Franke
>
> > Would this improve the ~1 hour time it takes for me to see the
> > messages that I post to this list?
>
> I'm not shure if this is originated in the Mailinglist server.
> Over here I have some 20 seconds to 3 minutes (a few times up
> to 10 minutes). Looks more like your providers infrastructure.
>
> Gruss
> H.
>
> --
> VCF Europa 3.0 am 27./28. April 2002 in Muenchen
> http://www.vcfe.org/
>
It probably is Yale's fault, but what makes that hard to believe is
the fact the this list is the _only_ e-mail (list or person-to-person) that
has such a delay... Oh well, such is technology... :)
--- David A Woyciesjes
--- C & IS Support Specialist
--- Yale University Press
--- mailto:david.woyciesjes@yale.edu
--- (203) 432-0953
--- ICQ # - 905818
Mac OS X 10.1.2 - Darwin Kernel Version 5.2: Fri Dec 7 21:39:35 PST 2001
Running since 01/22/2002 without a crash
VMware stopped supporting OS/2 (it was supported in a 2.x beta) around
the time they started selling VMWare bundled with Windows. They claim
there's no connection and that support was removed because of lack of
demand. Insert conspiracy theory about a deal with Microsoft to get a
sweet OEM license deal in return for killing OS/2 support here.
