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