test-drb April 2002

test-drb@ccmp.vtda.org

280 participants
1162 discussions

by csmith＠amdocs.com

> -----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"); '

24 years, 1 month

cure equiepement that was in the rain... best practices???

by ajp166＠bellatlantic.net

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 >

24 years, 1 month

DELQA/DEQNA Cab Kits question

by cdl＠proxima.ucsd.edu

> 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

24 years, 1 month

PDP-11/93 Console Pinout and model rev.

by csmith＠amdocs.com

> -----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"); '

24 years, 1 month

TTL computing

by ajp166＠bellatlantic.net

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

24 years, 1 month

list server computer hardware will change

by DAW＠yalepress3.unipress.yale.edu

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 >

24 years, 1 month

Tinnerman nuts

by pete＠dunnington.u-net.com

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

24 years, 1 month

TTL computing

by ajp166＠bellatlantic.net

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. >> >> >> > >> > >> >> >

24 years, 1 month

list server computer hardware will change

by DAW＠yalepress3.unipress.yale.edu

> 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

24 years, 1 month

OS/2 running under VMWare, or other emulator for Windoze

by PasserM＠umkc.edu

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.

24 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb April 2002