On 10/4/07, der Mouse <mouse at rodents.montreal.qc.ca> wrote:
> I am puzzled by people who want to run old
hardware, but who don't
> want to learn to repair it to component level.
It doesn't puzzle me so much... I personally started off with a
self-assembled Elf and a factory-assembled PET to which I added a
number of hardware hacks (including a "Simon" addon from a late 1970s
issue of Byte), so I've always approached computing, let along
"classic" computing, as a tandem hardware-software experience. Many
others I see and work with, though, are 100% software. I see a lot of
self-induced problems from not understanding the underlying hardware,
but the fact that it happens hasn't changed over my 30-year time in
the field (I started young).
> I can understand why
> people want to run the software under emulation (even if that's not
> what I want to do), but I am seriously wondering what extra you get
> from running the old machien _other_ than being able to fully
> understnad and repair the hardware.
Even back in the day, there were lots of folks who bought PETs and
Apples and more, that didn't know a single thing about hardware
troubleshooting and repair - 30 years ago, when it broke, they took it
to their dealer, or if it was too expensive to fix, they junked it (or
gave it to me ;-) I don't find it surprising that people are around
today with interest in the platform, but no interest or aptitude for
repairing it when it breaks. Look at how many folks work on their own
cars now, compared with 1977 - same issue, different hardware
platform.
Well, speaking personally....
I'm not hardware-antipathic; I know which end of a soldering iron to
hold [the cool one :)], and I've hacked together assorted electronics
on occasion (a few of which I've even mentioned here). However, most
of my on-topic hardware, I have no particular interest in repairing
below the board-swap level.
So, while I can't speak for anyone else in this regard, I can perhaps
address your puzzlement as it applies to me.
Most of the hardware in question is SBus-era Suns. I don't run it
under emulation because an emulator, plus the hardware to run it on,
would cost me a lot more than the Suns cost me (which latter figure is
usually $0 + shipping, and often the shipping is $0 because they're
local).
Certainly for now, and for the past few years, Sun S-bus-era hardware
is plentiful and cost more to ship than to buy (thus the importance of
local acquisition). 10 years from now, though, it might not be as
easy to find on the ground - like mid-1970s micros are already.
Suns, being a rather hardware-closed, high-speed (for their time),
highly-integrated platform, were never routinely hacked-on or repaired
by the folks running them (NVRAM replacements aside). OTOH, lots of
Apples, S-100 boxes, PETs, TRS-80s, etc., were. I do component-level
repair on lots of things, and I do have a lot of S-bus Suns, I really
haven't done much in the way of Sun repair.
One of the more important considerations is where I'd get spare parts.
I _could_ component-level-troubleshoot a SPARC 2 or a SPARC 5, but so
many of the components are not generic TTL parts, I wouldn't approach
the fault with the expectation that I'd be able to locate a
replacement part except on another similar board. I don't mind
replacing SMT parts, but in the case of most of the SMT ICs on a SPARC
board, I don't know where I'd locate new parts. Removing DIP parts is
difficult from boards as complex as these; not impossible, but
certainly lots more difficult than from a 2-sided 1970s micro.
Then, consider some additional points:
- Speed - emulators are usually slower than the real thing. An
emulated setup capable of matching the real thing's speed will be
substantially more expensive.
When I first started emulating classic platforms, I'd agree with you -
about 10 years ago, since I couldn't manage a large enough PDP-11
disk, I built an emulated PDP-11 w/RP03 under SIMH on a SPARC 1...
talk about *slooooow*. It worked, but was a small fraction of the
speed of the real thing. A little later, when I had a SPARC 5 on my
desktop at work, the PDP-11 was still slow, but acceptable. The 6502,
via VICE, was really nice; especially being able to load files from a
local directory on the workstation - I was able to *scream* through
software development by editing on a 1152x900 screen, cross-compiling
under Solaris, then running the binary on the emulated target.
These days, with even semi-modern hardware, x86 emulation of a
1995-era machine (386-DX25 through 486 DX2/66) at original machine
speeds is trivial. Emulating a VAX at original, or even faster,
speeds isn't difficult. If your target is 10 years older than your
emulation platform, I don't see why it has to be slow.
- Hardware compat - I have some oddball SBus cards. I
daresay
PCI-to-SBus, ISA-to-SBus, etc, bridges exist, but they will be
expensive, probably difficult to find, and may not even play nice
with the emulator.
That's an important point for a number of platforms - I used to make
Unibus, Qbus, and VAXBI 68000-based smart serial boards. I still need
a real VAX or PDP-11 to fiddle with my old boards. I know that there
were some bus interfaces for older PCs, but I've never handled one
personally. Certainly, I wouldn't expect those to work with modern
PCs.
- Reliability - as I think I've mentioned before,
peecee-class machines
account for a rather disproportionate fraction of the hardware
failures I've experienced. "Modern" machines as reliable as the old
Suns are doubtless available, but, again, that will mean a
substantial additional cost.
Consumer-grade PCs are notorious, naturally. Server-class x86
hardware can be as reliable as Suns, etc., but not as cheap as Packard
Bells, and the like, and certainly not as abundant. If you intend to
do production-quality emulation, you _should_ be using production
quality hosts for it. If it's just for fun, I don't see it as such an
issue.
So, really, it's a total no-brainer for me whether
to run the real
thing or an emulation, quite aside from whether I'm prepared to do
low-level repair work.
In the case of Sbus Suns, I agree with you that it's reasonable to run
the real hardware without being able to do more than depot-level
service.
Now, some of my stuff isn't SBus-era Suns. Much
of *that* stuff I *do*
want to be able to repair down to the chip level - for example, I have
some hp300 hardware with, I suspect, a blown HP-IB driver (last time I
tried to use it I was seeing what looked like a stuck-at fault). When
I get the round tuits together, I'm going to see if I can confirm/deny
my suspicion, and (if confirmed) pull a compatible driver chip from
something else and do a swap. Perhaps someday I'll be applying the
same philosophy to (say) the SPARCstation 20, and, if that happens,
I'll probably then be glad I'm not chucking "dead" hardware....
I can agree with that as well - for something more obscure, like
non-consumer HP products - it's much more reasonable to expect to have
to delve into component-level repairs to keep them running.
I think it comes down to relative abundance coupled with intrinsic
complexity. If I ever had a VAX 9000, I'd want to run it, even though
I don't think I have much hope of being able to find spare components,
but at least I would expect to be able to track down engineering
prints, unlike with SPARCstations.
-ethan