Did anyone ever try this:
I have a JVC VHS-C camcorder that has full-auto settings (leveler, focus,
lighting, etc.). It also has a snapshot feature, where it'll capture a
frame.
Use the video camera to take 'pictures', then connect the video output to a
good quality video capture card, and 'capture' the still shots.
Has anyone ever tried this? I was thinking this may be possible, since I
already have the camera, and I can get a vid cap card for about $50
///--->>>
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
> What is it? I've never heard of one before. It looks kind of like a Lisa
> but has an attched keyboard and two 8" floppy drives. See
> "http://205.217.140.132/pcmuseum/default_page2.htm". This is one of the
> things from the guy that wants to sell his entire $25K collection.
Looks like a Datamaster, but I don't think it is. Datamaster was 5322, FWIW.
I looked further down the page and he is talking a lot of nonsense. Like the
early Hayes modem, transmitting at 300k (k what? k millibaud?), as compared
with modern modems transmitting at 5,600k (k what? 56 kilobaud seems to be
fairly standard now...)
Philip.
>>> Of course, if you're using a camera better than a 35mm
>>> (say, a Medium Format or Large Format camera) you just put
>>> a polaroid back on your camera and you're there.
>
>>> At least here in the US, if you check out the swap meets and
>>> flea markets it's easy to find an older 4x5 Crown Graphic with
>>> good quality lens and 4x5 polaroid back for a few hundred $.
>>> I got mine with a 127mm Ektar, a truly excellent lens from the
>>> late 40's.
>
>>I've never seen that, but it's interesting -
>>so how is the picture quality ?
>
> Top-notch. I regularly make 16" x 20" enlargements from the 4x5 negatives.
If as is often said, a 35mm negative will blow up to around 12*8 inches without
visible loss of detail, expect a medium format negative to blow up to 19 inches
square (or 19 inches * whatever your other dimension is), and a large format
negative to blow up to 42*34 inches. The exact size you can achieve will depend
on your film and equipment, though.
One of my favourite photos (that I've taken - it was on my Yashica with a 2.25
inch square negative) I have had made into some 20 inch square prints and they
look stunning.
>>And most important, where to look ?
>>For this kind of stuff I'm a complete newbie.
>
> There's a web site just for folks like you: http://www.graflex.org/
> It includes the Speed/Crown Graphic FAQ, and pointers to where you
> can buy these cameras and parts.
>
> Again, I don't know about Europe, but here in North America *every*
> decent professional camera store will have large format stuff, including
> at least some selection of Crown and Speed Graphics.
The shop in London where I bought my Hasselblad is an excellent place, if you're
ever near there. It is called "Teamwork" and it is in Foley Street, about 1/4
mile due west of Goodge Street tube station. It is packed full of 5*4 inch and
larger format cameras - my Blad must have been the smallest in the place! (a
map of the area can be seen at
http://www.streetmap.co.uk/streetmap.dll?grid2map?X=529250&Y=181750 if you have
a graphical browser)
Also in London is a shop called "Nicholas", quite close to Mornington Crescent
tube station. I don't know how good it is - I gave up after waiting outside
half an hour when the sign in the window said "Back in 20 minutes". Eventually
I concluded that this was a typo for "Back 1h 20 minutes" ;-) The only good
thing to happen that day was the girl I met, also waiting for the shop to
re-open ;-) ;-)
Philip.
> Speaking of Compuserve, what is its history?
I think this goes back earlier than you wanted (to a time before
home micros), but here's an excerpt from a summary written by
Sandy Trevor [70000,130] I found at
http://www.inwap.com/pdp10/compuserve.txt
****
This may not be exactly what you had in mind, but it is a pretty accurate
summary of how 10's have been used at CompuServe over the past 17 years. I
hope you can use it... anyway, please do keep me updated on your project. (If
you want changes, or more material, just let me know). Also, if you do decide
you want to use this, I'd like a chance to edit it a bit before giving you a
"final" version. So please consider this a prelimary version...
--Sandy
We Call Them 10's
- A Brief History of 36-bit Computing at CompuServe -
Alexander B. Trevor
August 31, 1988
CompuServe has one of the world's most powerful remaining thirty-six bit
computing facilities, but got its first PDP-10 almost by accident. While I
was a graduate student at the University of Arizona's Analog Hybrid Computer
Lab (AHCL) in 1969, I discussed with two other students the idea of starting a
time-sharing company after completing our degrees. We had all gotten to know
a PDP-15 intimately at AHCL, so it was the obvious cpu of choice. But my
choices in late 1969 were the Army or Canada. I chose the former, which put
me behind a 360-40 in Saigon instead of a PDP-15 in Tucson. Meanwhile, my two
AHCL friends, Dr. John Goltz and Jeff Wilkins, went to Columbus, Ohio, where
they intended to computerize insurance processing for Golden United Life
Insurance with (of course) a PDP-15. Before the 15 was delivered, however,
DEC called up Dr. Goltz and told him that for only "a little more" he could
have a KA-10. The prospect of having all this power was irresistible. Though
he liked to distance himself from those of the sales persuasion, John
skillfully sold the board of directors on the idea of spending the extra money
to buy the PDP-10 and thereby gain the excess computer power to be able to
launch into timesharing.
Of course, it was a terrible time to get into this business. GE, Tymshare,
Cyphernetics, and First Data (to name just a few) were already well
established. The timesharing subsidiary of Golden United took the name
"CompuServ Network, Incorporated" and started developing its first
application, LIDIS (Life Insurance Data Information System). They had a KA-10
with all of 80K words of memory, two RP02 disk drives, and a few ASR-33
teletypes. The "C" series of TOPS-10 monitors that was available in 1970
supported disks, but as little more than circular DECtapes. Still, CompuServ
made LIDIS work, and began attracting other clients.
From the beginning, CompuServ tried to improve upon the standard DEC
offerings. A first step was to hire two of the engineers who installed the
machine: Bill Spellman and Tom Shelton. Tom would look at the the lights of an
ailing KA for a minute or two (KA's had MANY lights), then go in back and
change one or two boards. Usually, he fixed the machine on the first try this
way, notwithstanding having been hauled out of bed at 3 a.m.
A second step was to improve TOPS-10. At that time DEC included operating
system sources with every machine. You needed them too: the early releases of
TOPS-10 did not terminate a job if someone hung up without logging off. Thus,
the next person calling in on that line found himself in the previous user's
job, with access to all his files and privileges -- the infamous ghost port.
Needless to say, customers got pretty upset when this occurred, so we fixed it
quickly.
Some monitor hazards took longer to surface. One morning, when the
engineers looked at the KA, strange patterns were dancing across the console
lights. Spellman was about to shut down the machine, when Steve Wilhite
grabbed him and told him it was "just a little program I wrote." The next
day, the LIGHTS UUO (CALLI -1) was disabled.
Another motivation for modifying the operating system came with the first
release of the "D" series monitor -- the first one with a real file system,
including the beloved MFD, UFD's, RIB's, and SAT's. The first "D" monitor did
not work for more than a hour at a time. John Goltz stayed up for three days
patching the "D" monitor well enough so that calls from our customers no
longer included threats of bodily injury.
I seem to walk into things right after the fun. I went to Vietnam right
after the great Tet Offensive of 1968. I joined CompuServe in 1971, right
after the "D" monitor crisis. (It is still unclear to me which of these two
events will turn out to be the most significant.) In any case, when I joined
CompuServe in late 1971, they had two KA-10's, each with four RP02's.
My first task was to write UNSPOL (DEC's spooling software was not yet
available). Our machines were getting bogged down with jobs running "GLOM" -
a little routine that continually tried to assign the line printer. We wrote
most of our own utilities, either because we wanted features not yet available
then from DEC, or because the DEC equivalents were not compatible with our
monitor, which was rapidly diverging from standard TOPS-10. Or maybe we just
liked to be different. Early on John had written a new EXECUTE that used
sixbit command files instead of the DEC standard ASCII (to save disk space).
Of course, this required changing all CUSPS (Commonly Used System ProgramS)
and compilers. (Back then, programmers were cheaper than disks).
The monitor's command decoder was another area of great change. We
perceived GE as our prime competition, so many things were done to make former
GE clients feel at home -- including the "OK" prompt, an imbedded line
numbered editor in the monitor, and having Steve Wilhite write a Basic
compiler in Macro-10 from scratch. At that point we didn't know that a
compiler was too big a job for one programmer, and fortunately neither did
Steve. Emerging from the dark back room we called the "cave" only to grab a
line printer listing or an occasional sandwich, he got it done in ten months,
using an ASR-33 and our FILGE editor. Everyone loved his Basic, but I'm not
sure how many customers really switched from GE because of it.
During this period we learned to get the most out of the KA -- doing things
such as using MOVEI A,N(A) for addition because address arithmetic was faster
than the regular adder on the KA.
CompuServ's two KA-10's were each connected to 680i front-ends through
DA-10 interfaces. The 680i was a PDP-8 that had been lobotomized to handle
communications. UART chips were not yet in common use, so the 680i's had to
handle asynchronous characters one bit at a time. One disadvantage of this
configuration was that communications ports were tied to a single host KA. For
example, the remote lines from Dayton and Cleveland were connected to System
1, while Columbus and Detroit were on System 2. So what did you do with a
customer with offices in all four cities? My second major assignment at
CompuServ was to solve this problem.
Clearly, some kind of switch was needed so that a user coming in through
either 680i could access either host. And what was Dr. Goltz's choice for the
switching computer? Right, a PDP-15. It was an 18 bit machine (exactly half
the PDP-10 word length), fast (1 MIP), and fortuitously, compatible with the
DA-10. Now, this PDP-15 that I had to develop into an intelligent
communications switch came with 8K of memory and an KSR-35. That was it -- no
mass storage, not even a Dectape. Since I did not relish doing development on
paper tape, I decided I had to use the 10 for development. Since there was no
cross assembler for the PDP-15, I wrote macros for each of the PDP-15
instructions and used Macro-10 to generate PDP-15 object code... a use that
probably even exceeded the wildest fantasies of Macro-10's developers.
In 1973 CompuServ moved to a new custom building in Upper Arlington, Ohio,
and upgraded the KA's to KI's. By July, 1974, we had seven KI's and were using
them not only to support a thriving time sharing business, but also to heat
our office buildings. The RP02'S and RP03's were all retired in favor of
"huge" 200mb Ampex and Memorex 3330 disks connected through Systems Concepts
SA-10's. John Goltz continued to develop his operating system (now called the
"E" monitor), including a class scheduler.
But by 1976 a more pressing problem arose. DEC had released the KL-10,
but it seemed prone to overheating (ECL does generate a lot of heat). Dr.
Goltz felt we needed a faster processor, but the KL was unsuitable. We looked
at Foonly's F1, but were uneasy about their ability to actually produce
machines. So, with two of our best engineers, Doug Chinnock and Wilson
Mowbray, John Goltz set up an R&D center in Tucson, Arizona, to build a better
36-bit computer. In 18 months, they had several large boards, microcode that
avoided all the DEC patents, but were still a good year from having a
production machine. Jeff Wilkins was running short on enthusiasm (and cash)
for the project, and it looked like DEC had really solved the KL-10 heat
problem with the DEC-System 20 configuration. Not only that, but the price of
the 2050 was at least $100K lower than the 1090. Internal memory and devices
on RH-20's seemed not only more efficient, but saved us from having to add
cache sweeps to our monitor. If we could run our operating system on this
machine, it might make more sense than finishing the "JRG-1" processor.
After several trips to Marlborough, I got DEC to agree to sell us
DECSYSTEM-20's with TOPS-10 licenses and DX-20's. The licenses eliminated any
question about running any of the TOPS-10 utilities, and the DX-20's let us
connect the orange KL-10's to our STC tape pool. Our first 2050 worked
beautifully, so the JRG-1 project was terminated. Sadly, not long afterwards,
Dr. Goltz left CompuServe.
We had been buying Ampex's ARM-10 memory for the KI's for years, so we
asked them what they could do for the 20. Despite dire warnings from DEC
engineers that the S-bus could not possibly support a physically external
memory box, Jay Canel of Ampex came to CompuServe with the first ARM-20 box,
plugged it in to our 2050, made one timing adjustment, then we watched it run
for the next six months without a failure.
Our next 2050 enhancement was to design a channel interface. Since the
Massbus was patented, and DEC was not granting licenses, we built directly to
the C and E busses. Our "MBX-20" let us connect 300 mb SMD disks to the 2050
using a Telefile controller, instead of being limited to the 200 mb RP06 (all
that DEC offered then).
By 1978 we had two computer centers - the one in Arlington full of KI's,
and one in Dublin, Ohio, filling up with 2050's. We were not yet ready to
abandon the KI's, but wanted some more horsepower out of them. Wilson Mowbray
designed a hardware cache memory for the KI which yielded a 30% improvement in
KI speed. Later, Wilson designed a switching regulator power supply for the
KL, which halved it's power consumption. Roseann Giordano was so impressed
that she sent some DEC engineers to look at it. They liked it, but the KL was
too near the end of its product life cycle for DEC to make any changes, even
though we offered to give them the design.
By 1980 PC's were beginning to assume many of the tasks formerly done on
timesharing systems. Many of our old timesharing competitors (Cyperhnetics,
First Data, On-Line Systems) had been acquired or disappeared. CompuServe
(which had added the "e" by this time) was acquired itself in 1980 by H&R
Block. Block wisely let CompuServe continue with all its plans -- including
rolling out a service for PC users modelled loosely after the European
"videotex" services. Developed almost clandestinely shortly before the Block
acquisition, it was called "schlock timesharing" by the "professional"
commercial timesharing sales force. Initially released as "MicroNet" and
later as "the CompuServe Information Service," it grew to be 50% of CompuServe
revenues by 1987, while commercial timesharing evolved rapidly toward
databases, email, and commercial videotex.
With Block providing financial backing, ComuServe entered the acquisition
business itself. It's first acquisition was Software House (the authors of
1022 and 1032 DBMS systems.) While solidifying our position in the 10 world
with 1022, we also had taken a first step into the world of Vax with 1032.
There was some pressure from various quarters to "upgrade" our hardware to
something more modern -- like Vaxes, for instance. However, by 1986, KL's
were less than $20,000; we had our own monitor and most systems software
(except LINK-10 and BLISS-36); we were able to use current technology disk
drives; and we had 100+ manyears of applications software in XF4 (our own
ten-based extended Fortran) and Bliss-36 -- so how could we justify a change
unless 36-bit cpu's became unavailable? To be sure that didn't happen, we
ordered a Systems Concepts SC-30 from Mike Levitt. It arrived in late 1987 (a
bit behind schedule), but came up and ran our operating system with no more
than the expected number of microcode bugs. (We used Tops-10 paging, which
Systems Concepts had not fully tested before). It worked well enough that we
ordered a total of 10 SC-30's - four of which are up and running as of this
writing; the remainder to be delivered next year. The venerable KI's (the last
of the "lights mentality" machines) are being phased out to make room for the
SC-30's... (and yes, a few Vax 8550's have snuck in too, for some new
applications already written for Vax). New interfaces are being designed for
both the KL's and the SC-30's to support faster disks, optical storage, and
new archival storage devices. Applications development in Bliss-36 and XF4
continues unabated. At CompuServe, at least, 36-bit computing has a bright
future.
I've been seriously considering buying a digital camera for some time now.
I assume others on this list already have these in order to photograph
some of their computer items, so i thought I would ask which features
are most important. And which features you really wish you'd spent extra
money for.
It seems to me that a macro-focusing feature, which allows you to
manually focus at very close range would be very useful. Or can
you get by with a 3X optical zoom in order to get detailed shots
of computer boards, or the insides of a computer, etc?
How important is high resolution? Is a 640x480 camera with 10X
zoom much more useful than a 1280x960 with 3X zoom and
no macro focusing?
I'm really only interested in photographing computers and circuit boards,
I assume anything that can handle that to my satisfaction will be able
to handle the occasional photo of my niece and nephews, etc.
-Lawrence LeMay
lemay(a)cs.umn.edu
I just aquired a uVAXII with a RD54 and a TK50 drive and I'm trying to load
VMS. I don't remember the stand-alone backup command to issue. I'm hoping
that someone can help.
I have two TK50 tapes that came with it. They are labeled:
VMS V5.0 BIN TK50
BINARY
and
VMS V5.0 BIN TK50
MANDATORY UPDATE
I can probably handle the update after I install VMS (something like
@SYS$UPDATE:something-or-other).
The first tape boots and takes me into stand-alone backup. At that point I'm
lost. Any ideas?
Thanks,
Bill
Hi All:
For your info, I've just completed an update of
http://highgate.comm.sfu.ca/pdp8. The following documents were added:
PDP-8/i Hardware Maintenance Manual (July, 1969), Volumes I and II;
PDP-8/e/f/m Processor Maintenance Manual (January, 1974), Chapters 1
through 4.
Thanks to David Gesswein, as usual, for the scanning of this material!
Feedback and suggestions for the web site are always appreciated,
Kevin
---
Kevin McQuiggin VE7ZD
mcquiggi(a)sfu.ca
Yeah, the Voyager used three RCA 1802s (the CPU used in the Elf, SuperElf,
COSMAC computers), because they used a SOS process (Semiconductor On
Sapphire) which was extremely resistant to electromagnetics, radiation, etc.
I think about that every time I see the silly original Star Trek: The Motion
Picture (for those who haven't seen this masterpiece, the RCA 1802-powered
Voyager runs into an alien civilization who accelerates it to about the
level of HAL with a learning disorder, then gives it a big EMP gun and
points it back towards Earth - gee, thanks)
Kai
-----Original Message-----
From: Max Eskin [mailto:max82@surfree.com]
Sent: Saturday, July 03, 1999 2:25 PM
To: Discussion re-collecting of classic computers
Subject: Re: E-bay stupidity! was Re: height of folly
On Sat, 3 Jul 1999 jpero(a)cgocable.net wrote:
>Bogus! I knew Voyager doesn't use this '4004, I think cpu is 1801
>or something like that made for space applications.
So, where _did_ the story about the Voyager using a 4004 come from? I've
seen it in a variety of places, and never questioned it. As it happens, I
think that this is a fairly valuable item, though perhaps not worth $600.
Although it's not the _first_ microprocessor (as we learned a year ago),
it's definitely the first commercial one.
--Max Eskin (max82(a)surfree.com)
http://scivault.hypermart.net: Ignorance is Impotence - Knowledge is Power
>There is this minicomputer I was given by a process control
>engineering firm. It resembles a PDP-8/e, but it is blue like a
>PDP-15 or PDP-10, and it has the name DECset 8000
>printed on the upper right corner of the control panel.
I have a pdp-8/e with a blue/green color scheme -- it is a
lab-8/e. Your system may be a derivative system...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
