Dave McGuire wrote:
On 04/14/2013
07:22 AM, Jerome H. Fine wrote:
I am not suggesting that (h) is better than (a)
-> (g), but it would
help if you could explain why. I will accept: "That is just the way
it is!" as the explanation.
It is a matter of what you *like*. I personally like both hardware and
software in the context of vintage computing, but for me, the engineering,
ingenuity, design, and construction found in the hardware is more
interesting. MUCH MUCH more interesting. That is MY view. It's different
from yours, AND THAT IS OK.
Then obviously, we agree!
You speak from the standpoint of someone who only
cares about software, and
for whom the hardware is completely irrelevant. And that's 100% fine...it's
what you like, and what you're interested in. However, please acknowledge
that other people like and are interested in DIFFERENT things than you....and
that needs to be ok too. The OP is clearly interested in hardware as well as
software...please do not try to dissuade him from following his interests.
Before the emulators were available, real DEC CPUs and other
hardware was vitally important. I even became somewhat capable
in regard to figuring our problems and putting systems together.
One time, I even managed to assemble from switches, diodes,
LEDs and resistors (along with a bit of wire and solder, of course)
a front panel that would support what a 6 button front panel on
a BA23 box has to support two MFM hard drives, including LEDs
to display the WRITE PROTECT status of any floppy media in
the RX50 drives.
So I am not completely immune to the "Light Side" of the hardware.
It is not the case that all the ingenuity, all the
engineering, all the
thought, all the effort that went into computing in the early years was all
directed toward and poured into software.
Since I have been writing programs for computers since 1960
(started with an IBM 650 using SOAP assembler), I am VERY
aware that hardware has advanced far more than software.
In fact, during the early years before operating systems with
files and disk drives became available, the ONLY thing was
hardware and the minimum software was only there to guide
the single batch job at a time through the queue.
The biggest single change was around 1966 when it became
possible to support a large number of terminals which were
able to EDIT online files which were then submitted as batch
jobs to be executed one at a time. This allowed the shift from
punched cards to online files to become possible. The system
I worked on in 1967 was a CDC 3500 with a file structure
that supported up to 6000 files residing on washing machine
sized disk drives.
But by 1980, DEC had developed and improved their operating
systems and that software has finally started to become just as
important as the hardware. Many others, including IBM had also
started along those lines. In particular, CDC had an operating
system for the 64 bit CPU, the STAR-100, which used virtual
memory based in the 256 TerraByte address space.
However, RT-11 finally became my focus, for many reasons,
around 1980 and I don't think there has been a year since then,
perhaps not even a month, that I have not run programs under
that operating system. When Ersatz-11 was first released around
1995, it was rather limited and I used both real DEC CPUs and
Ersatz-11 for a number of years. By 2002 when I upgraded to a
750 MHz Pentium III with 768 MB of memory and 40 GB hard
drives, I started to used the PDP-11/83 less and less.
What I still find so challenging is that even after 40 years, RT-11
still has a few bugs which crash the operating system and many
bugs that need fixing. The basic structure of RT-11 is extremely
solid and lends itself to many more enhancements that I ever would
have believed. I have managed to enhance more than half of the
SAV files and many of the device drivers along with the actual
monitors, as well as writing new monitors such as SN(X).SYS,
Symbolic Name List Pseudo Device Driver which does all of
what PATH does for DOS. Recently, I have also enhanced the
KED variants to support more than 24 lines and more than 132
columns.
Jerome Fine