test-drb August 2006

test-drb@ccmp.vtda.org

216 participants
517 discussions

by cc＠corti-net.de

Hi, I have two Micom Micro800/2 DataConcentrators and can't get them to do anything useful. I think they are concentrators/multiplexors that multiplex 8 terminal lines over one high-speed serial line. The problem is I don't have any manuals for them nor any other information like pinouts or switch settings, does anyone have the manual in electronic form? I only have a manual for the Micro800/X.25 Concentrator PAD. Christian

17 years, 11 months

Batteries ( was Re: PDP-8 /e/f/m memory)

by aliensrcooluk＠yahoo.co.uk

--- Don <THX1138 at dakotacom.net> wrote: > O. Sharp wrote: >> snip << > > > > I have mini-Maglites in my toolkit - three of 'e m, > and they all get use; I > > work in the dark a great deal, but that's anothe r > story * - and recently > > had the unpleasant surprise of having one of the > "regular" batteries > > corrode and die (and the batteries had been > replaced less than a month > > earlier). This did an _astonishingly_ effective > job of destroying the > > interior of the Maglite as well, the acids eatin g > away the Maglite's > > shell in a way I literally didn't think was > possible. Defective battery? > > Some other problem? We may never know. > > What brand of battery? I haven't seen a battery > fail like this > in decades. Was the light stored in a harsh > environment? > > > Whatever the cause, I'd hate to even _contemplat e_ > the idea of that > > possibly happening right next to a DEC backplane . > Yeah, what brand? Have you heard (I read this today) that Dell has been forced to RECALL 4.1 MILLION batteries , made by Sony (haha!), from there notebook computer thingies made from... *checks dates* ...April 2004 to July 2006! Why? Because of a risk of "smoke and/or fire". On a similar note, a heard of mobile phones exploding (yes, exploding) in Japan a couple of years ago, because they weren't using the recommended rechargeable batteries. Apparently, IIRC, if the batteries short out they become VERY hot (700 degrees C?) and explode like a grenade. Many of the owners of said phones were hospitalised and/or had hands/ears blown off :( Also, after the recent hot spell (36 degrees C) here in the UK I discovered that one of the batteries in a remote had leaked. I put it down to the extreme heat (in 27 years I have only seen a battery that has leaked twice now), as in my experience it's a rare occerance (unless the battery is really old). Regards, Andrew B aliensrcooluk at yahoo.co.uk

17 years, 11 months

Scanning formats

by blstuart＠bellsouth.net

> But what if you use mutiple OCR programs? Say, three different OCR > programs and then process the results taking a majority vote on each > resulting character? Even if all three mangle 20%, it won't always be the > *same* 20% across all three, right? (and if I did my math right, using > three 80% accurate programs reduces the error rate to just 0.8% or a 99.2% > accuracy rate) In the text OCR world, it's a mixed bag. I've tried this some in my day job at FedEx. While you can get some improvement this way, I've found a little different approach to help even more. You start with a greyscale image and do the binarizing yourself. Then you run the OCR engine on the image with several different binarization algorithms and different parameters on each. One of the commercial vendors does something like this and gives it a fancy name, like virtual rescan or something like that. At least with the material and techniques I was using, I found diminishing returns started to set in at after about 3 passes. BLS

17 years, 11 months

For users of Telenex / AR Datascopes...

by William.Cooper＠sungard.com

Kevin, I have a an Interview 7200 Turbo that I need to have repaired. It powers up and the fan comes on but no screen. Do you think you can fix it ? I also have Interview datascopes that need repair in storage. My Philadelphia facility also has some lying around as we have not been able to find a place to repair them. Please give me a call. Regards, Bill Cooper Senior DCE SunGard Availability Services 777 Cental Blvd. Carlstadt, NJ 07072 Phone: 201 729 2484 william.cooper at sungard.com Hours: Mon-Weds 730am to 830pm M-T 730am to 930pm W

17 years, 11 months

The TIFF versus JPG debate

by Jason.Armistead＠otis.com

My $0.02 worth on the abovementioned subject: TIFF has lots of ways data can be encoded within the basic TIFF file structure, including LZW, CCITT G3 and CCITT G4 formats. If anyone is interested, get a good look at the TIFF V6 specification, although the links on the www.libtiff.org site seem to be broken and Adobe has now put their copy of the TIFF specification behind a whole lot of "developer registration required" pages you need to get through first. See also http://www.awaresystems.be/imaging/tiff/tifftags/compression.html which describes the TIFF tags relating to compression of image data. >From where I sit, we've used TIFF with CCITT G42D (fax) compression on bitonal (black and white only) image documents for 150,000 engineering drawings with excellent results. This is a totally lossless compression format (what you get back is exactly what you put in) specifically designed to do a good job with what you'd find on pages of drawings or of text. If you don't need colour or greyscale, then CCITT G42D is hard to beat. Within the US military, the CALS (Computer-aided Acquisition and Logistics Support) Type 1 specification for bitonal images basically wraps the compressed CCITT G42D data inside a slightly different wrapper to TIFF - CALS is a fixed length text header, and TIFF is a lot of binary stuff. It's easy to convert between the two formats when you know how. What I like about TIFF coupled with CCITT G42D compression most is (a) it's lossless, (b) supports multi-page documents, (c) it's an open specification with (d) an open source library to manipulate the files (LIBTIFF) and (e) it is widely supported with hundreds of viewers available (on Windows, the free Imaging component works fine for most people). I can also easily transform my TIFF data into Postscript (btw Level 2 Postscript more or less supports CCITT G42D compression too), PCL or even into PDF with not too much drama. In comparison, PDF is locked in more or less to Adobe's Acrobat Reader (yes, I know there's always Ghostscript / GSView and friends ! ), and not as easy to manipulate - I call it more of a nearly "final form" document format than TIFF. JPEG is not suitable because it was a lossy format targeted at colour images more than black and white, and it wasn't multi-page. I believe the JPEG 2000 specification has improved on some of these such as providing a lossless compression option, and can handle multi pages. I don't know if software to support all these features is (a) cheap or (b) available. For my money, I'm sticking with TIFF Cheers Jason

17 years, 11 months

slick bits in computers (WAS: VAXen Rule!)

by compoobah＠valleyimplants.com

There were two unrelated bits: ignore the VAX thing for now, I was just illustrating that "things" can be found in almost any family of computer that are a disappointment, not just x86. Merely illustrative. The second part was the general question, which I guess was a bit too specific. What computers have you come across that are really neat and why. OK.- System/3{60,70,90,z} is neat for it's processor instruction set, PERQs for the user-microcode. SGI Origin 2000's are neat for their CRAYlink/NUMAlink interconnect system, AXPs for the PALcode idea (sort of a takeoff of the PERQ). If you saw a computer that has a serial port implementation that is so elegant that it struck you as a thing of beauty throw that in ... I'm just interested in getting a feel for what's out there that members feel is neat. I was kind of thinking hardware to start with, but it could be extended to software.

17 years, 11 months

PDP-8 /e/f/m memory

by ajp166＠bellatlantic.net

> >Subject: Re: PDP-8 /e/f/m memory > From: "Chuck Guzis" <cclist at sydex.com> > Date: Mon, 14 Aug 2006 22:19:08 -0700 > To: cctalk at classiccmp.org > >On 8/14/2006 at 9:35 PM Don wrote: > >> >>Unless you can make a battery application last A VERY LONG TIME >>(not just a LONG time since those are the cases where you get >>screwed because you have forgotten about the battery that >>you replaced 1 or 2 years ago... *but*, if you replaced it >>*10* years ago you don't mind -- as much -- when it dies >>after that long of a service life) it will frustrate users. > >Well, consider the Dallas battery-inside-the-chip clock-calendar circuits. >7 years sounded like forever--and it may well have been to the original >owners of the equipment. But now, they're starting to fade and finding >replacements can be a bit of a hassle. In 20 years, it'll probably be >nearly impossible. I shave off the top of the DS1287s and replace the cell. It's easy to find the battery on those as it's magnetic! >For this particular application, any keep-alive power source needs only to >last as long the longest power-off interval. If, as Don, says a supercap >will last several months, that should be good enough--and it's a permanent >solution. Heck, I wonder if you could trickle-charge the battery with >ambient light via a solar cell. That should extend the keep-alive period >some. > >I just don't like chemical reactions in my equipment--it's sort of like >bird's nest soup. It might taste good, but I don't like the idea of eating >bird spit.. > Then place the battery at the ends of two wires remote from where their failure can do harm. Experience is a good adaquately sized Li cell is by far the easiest solution when used with the Dallas ram controller chips. Allison

17 years, 11 months

Scanning Formats

by Watzman＠neo.rr.com

RE: > But doesn't JPEG use lossy compression? Yes. You can adjust the "quality factor" but I think this would be A Bad Choice. Especially given my original comment that the documents are D-size reduced to B-size before printing (i.e., the text/lines are VERY fine and apt to disappear in the DCT application within the JPEG encoder.)" Yes, it's lossy compression, but if you use a high-quality setting (which was my point of 5K to 10K file size per square inch for color, or about 1/3 that for monochrome), you will never notice ANY difference. The size of the document is irrelevant, since as I said, "5K to 10K ***PER SQUARE INCH***". Larger documents produce larger files, but the quality loss for larger documents is no greater than for smaller documents ... which is to say, imperceptible. TRY IT, and compare the results. I suggest that you will not notice ANY difference between JPEG and TIFF, no matter what you do, no matter how you examine them. I have scanned nearly 40,000 pages now, plus almost 10,000 color photographs, since 2001. There is no good reason to use TIFF instead of JPEG, as long as you don't try to achieve excessive compression levels with JPEG (and at 5K to 10K per square inch for color, you won't be doing that -- that equates to 500K to 1 megabyte for an 8.5" x 11" color page). In fact, I often find that I can go down to less than 100k bytes per page (that's down towards and below 1K per square inch), but this is too much compression for some documents.

17 years, 11 months

PDP-8 /e/f/m memory

by ajp166＠bellatlantic.net

> >Subject: Re: PDP-8 /e/f/m memory > From: Don <THX1138 at dakotacom.net> > Date: Mon, 14 Aug 2006 21:45:57 -0700 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Ethan Dicks wrote: >> On 8/15/06, Don <THX1138 at dakotacom.net> wrote: >>> Outrageous overkill. What's that, 10ns memory? What's the 8's >>> memory cycle time?? ;-) >> >> The machine cycle time for an -8/e is 1.2uS. ISTR that a core read >> cycle on an MM8E (Omnibus core stack), including replacing the old >> value after the read destroys it, is on the order of 950ns, but that's >> from memory, not from looking it up. In any case, *any* SRAM, even >> stuff from the mid-1970s is fast enough. As for overkill, it's not >> about memory access time, it's about modern availability and package >> count - if you want to use a 32Kx8 SRAM, your choices are, >> essentially, uber-fast cache RAM in a skinny DIP or still-too-fast >> CMOS SRAM (62256) in a wide DIP form factor. > >But cache RAM is power hungry and has little practical chance >of being converted to BBSRAM Most are not, few if any of mine are not. NOTE: many of those rams are CMOS and at high cycle rates the power needed is impressive but in standby and low cycle rates the power drops significantly! Often they are spec'd at they fastest cycle time for power use as thats how PCs used them. Allison >> One could even wire up a socket with 3 rows of pins so the user could >> choose skinny or wide - the RAMs have, essentially, the same pinout.

17 years, 11 months

PDP-8 /e/f/m memory

by ajp166＠bellatlantic.net

> >Subject: Re: PDP-8 /e/f/m memory > From: Don <THX1138 at dakotacom.net> > Date: Mon, 14 Aug 2006 20:50:25 -0700 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Chuck Guzis wrote: >> On 8/14/2006 at 7:25 PM Bob Rosenbloom wrote: >> >>> How about two Ramtron FM18L08's? Nonvolatile like core with no battery >>> to die or leak. Would need level shifters to 3.3 volts >>> and slightly different timing. Low power, and in DIP or SMT. I'm just >>> tired of cleaning boards that had batteries that leaked all over them. >> >> How long will a supercap keep that much SRAM alive? > >Why not use a *big* battery/cell... aren't we talking >about a design that would end up WAY undersized? Even >scaled would leave lots of real estate that you could >install a conventional AA, 9V, etc. battery and forget >about it "forever" Because most batteries have shelf life! The average battery dies in a few years from just sitting. The LI cells are designed for very long life. I have a few sub-C sized LI cells that are over 15 years old and going strong. FYI: for how I care to use the semiconductor ram I could care less about volitility. Allison

17 years, 11 months

← Newer
1
...
26
27
28
29
30
31
32
...
52
Older →

Jump to page:

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 August 2006