>From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
---snip---
>
>Mind you, a CRT usually gets a little tired after a few years. I'm not
>sure how long its "good" lifetime compares to that of an LCD panel
>though, but my impression is that the CRT will likely outlive the LCD
>before replacement's necessary.
Hi
At the last company that I was at the same CRT was turned
on and of for each workday for 7 years. I'd call that reliable.
Current day monitors CRT's seem to be much more reliable
than the color screens used in the 60's. Maybe they use
better getter or something.
Dwight
I am not sure if this is 100% on topic since this stuff is from 1991 so
well, its a bit on the edge I suppose.
Anyway, I have several books I would like to get rid of with subjects like
Starbase, HP Visual User Environment, HP X Windows, HP 9000, OSF Motif.
If anyone is interested let me know and I will make a list. All these books
are almost unused and from +/- 1991.
Cheers,
Stefan.
-------------------------------------------------------
http://www.oldcomputercollection.com
>From: "Paul Koning" <pkoning at equallogic.com>
>
>>>>>> "John" == John Foust <jfoust at threedee.com> writes:
>
> John> At 07:21 PM 4/21/2005, you wrote:
> >> You could just remove the fiche viewer screen. You don't need the
> >> screen to form the image, you only need the (virtual) image from
> >> the viewer's lens system to be focussed in the same plane as the
> >> scanner's optics. Actually, since the image is usually focussed
> >> on the back surface of the viewer screen, you'd want to remove it
> >> anyway.
>
> John> Pointing the scanner at the plane in space that happens to be
> John> the viewing plane of the fiche viewer isn't going to result in
> John> an image. The scanner wants to see reflected light. Focusing
> John> the fiche projection at the scanner's sensor is a different
> John> sort of problem that would involve changing the scanner's
> John> optics, no?
>
>No. An image is an image. There's nothing magical about "reflected
>light", it's the same as any other light.
>
>The one issue you might run into is light loss due to mismatched
>apertures.
Hi Paul
That is what he is talking about. The scanner would
most likely have severe vignetting. As in a telescope,
you want two things to happen where the eye is. One
is that you want the image to focus at the back of the eye.
The other is that you want the image of the aperture
to focus at the iris of the eye. In this case you'd want
the image of the source to focus near the scanners
sensor to gather the most light. This most likely doesn't
even come to a focus as is typical in projection systems.
Dwight
>
> paul
>
>
It's a shame that many of the fiche-only docs once existed in magtape
form
and are now lost. It would've been easier and less error-prone to
emulate a viewer for old page layout RUNOFF-style markup. Has there
ever been an anecdote found about why all that data was tossed?
--
Why is any old media tossed?
The company considers it of no value.
Storage space (as many of us know) is not free. If there is no chance
that
the information is needed for future projects or support of existing
projects
it is discarded.
--
WRT the scanners that I have, the Mekel is a high resolution transport
that
can do step and repeat on all of the frames of the fiche. There is no
direct
display of the images on the unit, since the steping is done under
computer
control.
I have some older 3M film/fiche scanners that are manually positioned
for
fiche and do automatic scanning of microfilm.
The 3M units are of the type that project onto a screen
and have a camera on the rear of the unit. That is the most common
design
for scanners under $10k.
If folks in the Bay Area are interested in the 3M units, I have five
available.
They would probably be around $500 ea.
Patrick Finnegan <pat at computer-refuge.org> wrote:
> Well, X generally talks to the keyboard and mouse drivers of the kernel
> to do its stuff, and I don't see any reason to try and avoid that.
That behavior makes perfect sense when the keyboard hardware interface is
very special requiring a special kernel driver anyway (like those awful
PeeCee keyboards) or when the keyboard port is integrated with other hardware
that makes up the X display that needs a kernel driver (the case with DEC
QVSS and QDSS).
However, in the present case where the keyboard port is bog-standard serial
and is not in any way integrated with other display hardware (VGA chip),
but rather lives alongside with other serial ports on the machine doing
other things, it makes much more sense for the Linux kernel to treat it as
a regular serial port without any LK201 knowledge and concentrate the latter
in the X server.
Of course I may change my mind once I get down into the code, but this is
my current tentative plan.
> Sure, why not. Actually, I don't see anything that wrong with it, I
> just am not a huge fan of USB. :)
Me neither. But if I'm going to invest time and money into building my own
hardware, I may as well do my absolute best job while I'm at it: it'll cost
the same to make this thing with or without the additional port, and having
more options supported for the same cost means a greater return on the same
initial investment.
MS
Am I right in thinking that a home flatbed scanner has absolutely no
hope of providing the resolution needed to scan microfiche?
We've got a *lot* of DEC documentation arrived on fiche (208 pages per
fiche, estimated 25000 sheets) and scanning some of the more useful bits
would be nice. So far the cost from commercial companies has either been
too high or the quality has been far too low to actually be useful :-(
cheers
Jules
Patrick Finnegan <pat at computer-refuge.org> wrote:
> I'm suprised that you dont want to do this using a VS3100 (or 4000) and
> BSD of some sort. :)
As I already wrote, I obviously considered that, in fact that was the very
first thing I thought. The problem is that the best video I can hope to
get this way is VS3100 GPX (1024x864, 60 Hz refresh, 8 planes). I have
an SPX board (which is what VT1300 and VXT 2000 used), but it's completely
undocumented, so there is no way for me to write an X server for it.
(Even though SPX was specifically designed to run X!) The SPX board is
not only specifically designed for X and therefore faster, but it has
better video too: 1280x1024 at 66 Hz refresh. I feel extremely mad and
outraged at DEC for withholding the documentation for the SPX board,
I feel cheated that the board specifically optimised for X is out of reach
of Free X server developers, leaving them to run on the earlier GPX board
which is NOT optimised for X, and it feels counter-productive to me to
invest a lot of effort into writing a Quasijarus-based X server for the
GPX board which would do nothing but feed that anguish.
And while we are on this subject, the GPX board is not actually documented
either! But the IFCTF possesses a pirate copy of the Ultrix source which
contains a kernel driver for it which provides an ioctl interface that
emulates that of the QDSS driver to run the unchanged Xqdss server.
The VS3100 GPX board is NOT compatible with QDSS at the register level,
the emulation is in the Ultrix kernel sg driver.
And to add insult to injury the GPX board has another misfeature. Apparently
its video outputs are not just outputs, but also have some kind of reflection
detectors, and its ROM self-test that executes on power-up can detect whether
there is a monitor cable attached. However, the test is overzealous and
chokes with a fatal error when my monitor is connected. Apparently it
doesn't like something about it (Viewsonic P810), even though if I unplug
the monitor during the self-test and plug it in later, the picture on the
tube is beautiful. This problem does not happen with the SPX board. That
one also apparently has reflection detectors and also reports an error,
but it's nonfatal and does not stop autoboot.
And even if by some miracle I got programming documentation for the SPX
board and wrote a Quasijarus-based replacement for the EWS/VXT software,
I would still never be able to go past 256 color map entries. I suppose
the problem would be solved if I got full system programming documentation
for the SPXgt 24-place 3D graphics board and for the VS4000 it goes into,
but I won't hold my breath for that.
That's why I decided to design and build my own hardware. Reverse-engineering
undocumented hardware and closed source software feels like peeing against
the wind. I would feel better creating a beautiful new Open Source Hardware
design than digging in DEC's closed proprietary anti-freedom shit.
> Be aware that this shouldn't be all that difficult; Linux supports
> running an LK201/401 on a serial port via a device driver in late 2.4
> and 2.6 kerneles.
It doesn't matter. The only code that will know about and talk to the
LK201 will be the X server and StarMON ROM monitor. For the Linux kernel
(and for the hardware) the LK201 port will be just a bog-standard serial
port, Linux will have no idea what is connected to it. (Keyboard support
is not needed in the Linux kernel because it'll be completely hidden from
the user.)
> I'd skip USB all-together, and just use a serial or PS/2 interface mouse.
Why not offer it as an option if the extra design cost is negligible? It's
just a USB chip on the PCI bus. There is no extra software development
effort since USB mice are already supported by the Linux kernel and XFree86
server.
> There's no reason you can't run all that off a single ethernet
> controller; for example, on IBM RS/6000 SP's, they have a 10/100MBps
> RJ45 connector, as well as either a 10Base2 BNC or 10Base5 AUI connector
> run off the same interface.
Yeah, I realise it's possible, but separate Ethernets feel a little cleaner
to me and if I use the MPC8250 there is no extra cost for it since there
are enough resources in the chip for two Ethernet instances.
Thanks to everyone for the video chip suggestions!
MS
On Apr 21 2005, 10:49, Jules Richardson wrote:
>
> Am I right in thinking that a home flatbed scanner has absolutely no
> hope of providing the resolution needed to scan microfiche?
>
> We've got a *lot* of DEC documentation arrived on fiche (208 pages
per
> fiche, estimated 25000 sheets) and scanning some of the more useful
bits
> would be nice. So far the cost from commercial companies has either
been
> too high or the quality has been far too low to actually be useful
:-(
Sadly, you'll find normal scanners all have the "too low resolution"
problem to handle fiche. You'll also find a lot of variation in DEC
fiche quality.
Have you got much XXDP fiche?
--
Pete Peter Turnbull
Network Manager
University of York
>From: "Vintage Computer Festival" <vcf at siconic.com>
>
>On Thu, 21 Apr 2005, woodelf wrote:
>
>> PS. They plan someday to have human DNA recorded ... just how the heck
>> will you archive
>
>Make more humans?
>
Hi
It will most likely be recorded as the difference between
that person and a reference person. Most likely the
one used for the genome project. The differences are
a lot smaller than the parts that are the same.
Dwight
Dont know if this is common knowledge, but I have a VS3100/76 that I threw a
2gig IBM drive in, tried to put VMS on and - it worked. All the stuff I saw
seemed to indicate that 3100s didn't like sysdisks over 1 gig, but my /76
doesn't seem to mind.
There it is if it's useful
Scott Quinn
