12 Aug
2012
12 Aug
'12
2:15 p.m.
Every time I'be both seem an emulator of a chassic machine (runinng on a
friend's machine, obvious) and also run the rela hardware myself, I feel
the emultor doens't come close to the experinece of actually running the
classic computer.
Before I came across Hercules, I tended to dismiss emulators in the same terms.
However, I find the experience of using Hercules or Simh remarkably close to
the experience of using the actual machine in question. Many users of certain
classic computers never saw or heard the actual machine they used and only
interacted with it through a terminal (or even a terminal emulator).
There are also other factors which prevent both emulators and real preserved
hardware from recreating the original experience. Factors such as not having a
real world workload to process and not having a realistic number of users
working the machine hard (as opposed to a few museum visitors at a time trying
to figure out valid commands).
(I don't know why I am adding to this thread which looks destined to go
on and on and achieve little except to demonstrate that different people
have different ideas on how things should be preserved and that most are
not going to change their minds.)
Regards,
Peter Coghlan.
13 Aug
13 Aug
9:38 a.m.
In article <01OIZAUIJ21U001P8J at beyondthepale.ie>,
Peter Coghlan <cctech at beyondthepale.ie> writes:
However, I find the experience of using Hercules or
Simh remarkably close to
the experience of using the actual machine in question. Many users of certain
classic computers never saw or heard the actual machine they used and only
interacted with it through a terminal (or even a terminal emulator).
Almost noone at the University of Delaware ever saw or heard the
actual machines that they used. We all connected through terminals
across a port selector. The only machine that had a different
experience was the CDC cyber because it ran PLATO and you had to use a
PLATO terminal. Well, there was also the RJE stations for the
Burroughs machine, but honestly, by the time I was starting out there
in the summer of 1978, noone really used that anymore. Our private
terminal room was located next to an RJE station in Willard Hall
(education departemtn) and I can't recall ever hearing a person use
the card punch or submitting card decks there. Occasionally someone
would send their job output to the printer and it would make noise
printing up their SPSS output or something. That was pretty much it.
Once we got a tour of the machine room and I saw the PDP-11/70 that we
used all the time. I can barely remember what it looked like since we
only saw it once.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
11:28 a.m.
(I don't know why I am adding to this thread which
looks destined to go
on and on and achieve little except to demonstrate that different people
have different ideas on how things should be preserved and that most are
not going to change their minds.)
I think that most people here regard a computer as something that runs
particualr software, how it runs it is irrelevant. It's the software that
htey care about, how the OS wa used, ans so on.
I take (as you might expect) a different view. A computer is a complex
digital [1] circuit. The fact that it runs softare is aan interesting
property, but not the main reason I am interested in it. The cirucitry is
what fascinates me. For that reason a simulator is not going to 'do it'
for me.
[1] Yes, I know there are analogue computers. They are interesting too.
But lets not have another tangent... However the analogue parts of a
digital computer -- the power supplies, CRT driver circuits, disk drive
servos, etc are also certainly of great interest to me.
-tony
14 Aug
14 Aug
1:08 p.m.
Tony Duell wrote:
That is why
simulators are so important. You can get most of the feel
of the machine from the comfort of your own home.
No you can't. You can't learn how to load a card reader, disk pack or even
line printer paper on any simulator I know of.
Every time I'be both seem an emulator of a chassic
machine [...] and
also run the real hardware myself, I feel the emultor doens't come
close to the experinece of actually running the classic computer.
In some respects, of course, it can't. In other respects, it can't
until VR technology gets a lot better.
However, they serve useful purposes nevertheless.
In particular, they
I do not dispute that. THey are however a pale initation of the real
thing. Useful, but by no means the whole stroy.
can give more of a taste of the experience than
most people are likely
to get any other way. And to someone who's got the interest potential
but nothing to spark it, it can be that spark.
Sure. But given that most peole can run the simualtors at home if they
want to, there is little reason for museums to show them (in the same
way that sicne anyone can buy a book of reproductions of Old Master
paintings, there is litle point in having an art gallery that just
displays such books ]1]). The museum should show more -- like the real
machine in operation
[1] Note that I have said nothign about such books (or indeed simulators)
being sold in the appropriate museum shop. That is clearly a Good Thing.
And, for a hands-on museum, a replica panel backed
by an emulator will
be close enough for a lot of people, better in that it's a lot easier
to fix and/or replace if it gets heavy and/or careless use (I'm
thinking schoolkids).
Wby not replcia controls (the bit that is going to get the heavy-handed
interaction) backed by the real machine? Having seen an R-pi at the
weekend, I know hwich out of that and a PDP11 (saY) I'd rather have to
keep running.
(I don't
know why I am adding to this thread which looks destined to go
on and on and achieve little except to demonstrate that different people
have different ideas on how things should be preserved and that most are
not going to change their minds.)
I think that most people here regard a computer as something that runs
particualr software, how it runs it is irrelevant. It's the software that
htey care about, how the OS wa used, ans so on.
I take (as you might expect) a different view. A computer is a complex
digital [1] circuit. The fact that it runs softare is aan interesting
property, but not the main reason I am interested in it. The cirucitry is
what fascinates me. For that reason a simulator is not going to 'do it'
for me.
[1] Yes, I know there are analogue computers. They are interesting too.
But lets not have another tangent... However the analogue parts of a
digital computer -- the power supplies, CRT driver circuits, disk drive
servos, etc are also certainly of great interest to me.
2:37 p.m.
In article <502AB05A.1030302 at compsys.to>,
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
Since almost all emulators or simulators have as their
primary focus
[...] the accurate execution of any given hardware instruction,
With a few small excpetions, there are no emulators or simulators for
most of the hardware that I have.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
5:03 p.m.
Richard wrote:
Jerome H. Fine writes:
I agree that only the hardware systems that are used most
frequently have emulators or simulators. Which translates
to the fact that the hardware systems which are used by
just a small percentage of the community will not have an
emulator written. Since there are so many of these hardware
systems, only a small percentage of all of the hardware
systems, specifically the hardware that is used by most
users will ever be emulated.
Rarely, projects like SIMH appear which attempt to handle
a large number of different hardware systems. But even SIMH
looks at only a very small percentage of all the different hardware
possibilities.
In that case, how do you manage to retain the hardware which
you use in a running state? For many years, I collected PDP-11
hardware until about 2002 in order to have sufficient spares. After
Ersatz-11 became so enhanced, that was not longer necessary.
What do you do for your hardware?
Jerome Fine
Since almost all emulators or simulators have as
their primary focus
[...] the accurate execution of any given hardware instruction,
With a few small excpetions, there are no emulators or simulators for
most of the hardware that I have.
15 Aug
15 Aug
8:07 a.m.
On Tue, Aug 14, 2012 at 8:03 PM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote:
In that case, how do you manage to retain the hardware
which
you use in a running state? For many years, I collected PDP-11
hardware until about 2002 in order to have sufficient spares. After
Ersatz-11 became so enhanced, that was not longer necessary.
What do you do for your hardware?
While I don't have to room to store minicomputers and mainframes, I DO
keep an Amiga 500 around. I mainly keep it going by keeping it stored
in the main part of my home rather than the basement, garage or a
storage locker. This is important because it means that I can fire
things up for testing every now and then and also because it's not
subject to the poor environmental conditions that it would have in a
more conventional storage location.
Mike
11:46 a.m.
In that case, how do you manage to retain the hardware
which
you use in a running state? For many years, I collected PDP-11
hardware until about 2002 in order to have sufficient spares. After
Ersatz-11 became so enhanced, that was not longer necessary.
What do you do for your hardware?
It depends -- a lot -- on the machine (or peripehral), and I must admit I
tend to actively colelct machines i know I can keep going.
The first point (and this will probably start another flamewar) is that I
do component-level repair. You might well find it impossible to find,
say, a memory address PCB for an HP9820 calculator. But the ICs on that
board are all pretty noraml TTL parts, only 1 or 2 types are even
moderately obscure. You can get parts taht will work quite easily. And if
not, well, you know what the chip should do so you can make some circuit
to replace it.
Of course some chips are goign to be hard to find. ASCIs are amongst them
(fortunately the machines I like don't have ASICs :-)), as are some older
RAM chips, microprocessors, etc. I nthis case you grab al lthe related
bards you can find and raid chips fromthem. Why not just swap the board?
well, firstly it might not be the right board (something like an old RAM
-- Intel 1103 anyone -- can turn up in various machines), the 'spare'
board might be defective due to a fault other than in the chip you want,
and in any case if you reduce a board to its compoents you can use them
to repari sevearl machines.
Of course discete components are gernally still avialable new, or at
least something is avaialbel that wil lreplace the failed part.
Transformers, motors, etc cna be rewound. It takes time, but it's doable.
Flyback transformers are the exception, theare vacuum inmpregnated. I am
still lookin for ways to make replacements, I must talk to the model IC
engine guys who make ignition coils this way...
In a lot of cases swithces (a common problem) can be taken apart and
cleaned and will then work again.
Mechancial may be standard 9like ball races) or can be made/modified i na
reasoanble workshop.
Of coruse not everything can still be easily made or obtained but I am
often pleasantly suprised by how many parts for my classic computers are
still listed.
-tony
14 Aug
14 Aug
3:07 p.m.
On Tue, Aug 14, 2012 at 4:08 PM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote:
(much snippage...)
To make the point in a different manner, a software
addict is interested in
the manner in which the combined software of the operating system, device
drives, utility and application programs interact to produce a useful result.
.
.
.
So while I wish the hardware addicts well, viva the
software addicts!!!!
Personally, I like the real hardware and enjoy constructing new hacks and
keeping the original gear working both. I also write code, but far more
system-level code than application code. To me, at the level I write at,
I need a 100% faithful hardware emulation from my simulators. It's not
good enough that a FORTRAN or BASIC program will run, pull in text
from a disk or tape file and smash together the data
and spit out the
right characters for output. I care if bits in I/O registers flip
and clear
in the right combination (though I care less if it takes 1us or 0.001us
as long as it's perceived by my code to be in the right sequence with
no atomic operations broken).
In general, most emulators do a fine job of this or the OS would never
load in the first place, but there are edge cases, which is why, for
example, in VICE, you can select logical emulation of the model
1541 floppy drive or exact emulation. Logical emulation presents
far less load on the host and if all you do is load and save files
and send non-exotic commands to read and write data, it all works
fine. If your program needs to manipulate data structures and buffers
behind the scenes (CBM DOS allows the main CPU to read and write
arbitrary bytes in the disk drive CPU's memory space using simple
textual commands that are syntactically the same as the commands
to load and save and review the directory, so it's not out of the question
to emulate it all).
I had one experience where I found what I thought was
an obvious case of "this should work" that turned out to
be a bug in the emulation of the hardware... On an early
version of the SimH PDP-11 emulator (c. 1998), there
were no known obvious problems under RT-11 or RSX-11
or even 2BSD with various types of DEC disk _except_
when I tried to create an environment with an RP03 and
load 2.9BSD on it (since I already had real 2.9BSD tapes
that I'd previously used to install the OS on real
hardware - an 11/24 with RL02 and RK07), the install
worked perfectly, but the OS hung on startup when it
came time to probe the bus for what controllers were
installed.
It took three of us, Bob Supnik included, to figure out
the issue was that when probe code writes to a read-only
register on the RP-11 controller, the controller should
generate an interrupt. That behavior is documented,
but even in hindsight, it's not documented in such an
obvious place that someone attempting to build an
RP-11 work-alike would know or expect that something
important should happen when you write to a read-only
register. The code fix was trivial and after that, 2.9BSD
came up and ran perfectly well.
If I hadn't decided that I wanted about 60MB of space (vs
10MB per "disk" w/RL02 or 28MB per disk with RK07), I
never would have known that there was an implementation
bug with the RP11 code. Also, if I'd only ever stuck to
DEC operating systems, I'd probably never have known
then either. It's an edge case, since I doubt there were
ever very many real PDP-11s with real RP-11s running
2.9BSD (for larger disk, an Emulex controller using the
xp driver would have been far cheaper and far more
common), but since with an emulator, I'm freer to configure
a virtual machine in somewhat more interesting (but
supposedly legal) combinations.
So this is not a condemnation of emulation, but it is a
cautionary tale that sometimes, it's not as easy as it
appears to "get it right", and that's where having real
working hardware can help. You say, "almost all
emulators or simulators have as their primary focus...
the accurate execution of any given hardware
instruction", but do keep in mind that it goes beyond
the instruction set when you start fiddling with
emulated hardware. MOV might move a byte
just fine as far as the ALU is concerned, but when
it's not merely storing a byte in an array to be fetched
later, when it needs to *do* something behind the
scenes because in the real box, you've just triggered
a cascade of flip-flops and gates, there's a whole lot
of emulator code that has to work that might or
might not have been sufficiently tested for
"accurate execution".
-ethan
P.S. - yes, I've written plenty of MACRO-11 code under
RT-11 that directly fiddles registers - I worked on this
one project that had a hardware DMA engine and a
framebuffer, so my application code did lots of writes
to the I/O page, not just make I/O requests via the
usual RT-11 mechanisms.
3:54 p.m.
So this is not a condemnation of emulation, but it is
a
cautionary tale that sometimes, it's not as easy as it
appears to "get it right", and that's where having real
working hardware can help.
Real world example:
I was looking at the PCRE library, which now uses a JIT for compilation of
regular expressions (much like YARR for those who are familiar with
JavaScriptCore), since it advertised PowerPC compatibility. It had been
tested extensively in QEMU, but on real Power Macs it crashed because the
cache didn't behave the way it did in QEMU. Fortunately it was easy to
fix.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Homestar has a web site? -- Strong Bad -------------------------------------
15 Aug
15 Aug
1:16 a.m.
On 15 August 2012 00:54, Cameron Kaiser <spectre at floodgap.com> wrote:
Another real world example - the vax MSCP device attachment code in
NetBSD was updated to better use kernel threads after NetBSD-5, but
while the first version code ran fine under simh it failed to attach
on real hardware - due to a timing related bug.
So this is not
a condemnation of emulation, but it is a
cautionary tale that sometimes, it's not as easy as it
appears to "get it right", and that's where having real
working hardware can help.
Real world example:
I was looking at the PCRE library, which now uses a JIT for compilation of
regular expressions (much like YARR for those who are familiar with
JavaScriptCore), since it advertised PowerPC compatibility. It had been
tested extensively in QEMU, but on real Power Macs it crashed because the
cache didn't behave the way it did in QEMU. Fortunately it was easy to
fix.
14 Aug
14 Aug
6:05 p.m.
Ethan Dicks wrote:
On Tue, Aug 14,
2012 at 4:08 PM, Jerome H. Fine wrote:
(much snippage...)
To make the point in a different manner, a
software addict is interested in
the manner in which the combined software of the operating system, device
drives, utility and application programs interact to produce a useful result.
.
.
.
So while I wish the hardware addicts well, viva
the software addicts!!!!
Personally, I like the real hardware and enjoy constructing new hacks and
keeping the original gear working both. I also write code, but far more
system-level code than application code. To me, at the level I write at,
I need a 100% faithful hardware emulation from my simulators. It's not
good enough that a FORTRAN or BASIC program will run, pull in text
from a disk or tape file and smash together the data and spit out the
right characters for output. I care if bits in I/O registers flip and clear
in the right combination (though I care less if it takes 1us or 0.001us
as long as it's perceived by my code to be in the right sequence with
no atomic operations broken).
In general, most emulators do a fine job of this or the
OS would never
load in the first place, but there are edge cases, which is why, for
example, in VICE, you can select logical emulation of the model
1541 floppy drive or exact emulation. Logical emulation presents
far less load on the host and if all you do is load and save files
and send non-exotic commands to read and write data, it all works
fine. If your program needs to manipulate data structures and buffers
behind the scenes (CBM DOS allows the main CPU to read and write
arbitrary bytes in the disk drive CPU's memory space using simple
textual commands that are syntactically the same as the commands
to load and save and review the directory, so it's not out of the question
to emulate it all).
Under Ersatz-11 and SIMH, it is possible to write code which determines
which emulator is running - or if a real DEC CPU is being used. I plan to
revisit RESORC.SAV to add that code to the description of the hardware
that is being used.
YES!! I agree that even emulators can be a bit different from the real
hardware in situations when the results don't cause a problem with what
the operating system will normally do when a specific answer to a specific
requirement is needed which determines certain error handling code as
just one example. Somehow, it was found that SIMH, Ersatz-11 and
real DEC CPUs behave slightly differently and that allows the code to
know which actual hardware or emulator is being used. I can't be more
specific at the moment since I can't quite remember the details. But in
a few months after I complete some changes with KED to add a few
enhancements, I plan on going back to RESORC.SAV and adding the
code to:
(a) Determine if SIMH or Ersatz-11 is being used
(b) The approximate relative speed of the emulator vs a PDP-11/93
(c) For a Mapped Monitor the method used by the XALLOC subroutine
in selecting extended memory - LOW or HIGH first.
Does anyone have any suggestions for RESORC or KED enhancements
while I am adding some of my own enhancements?
I had one experience where I found what I thought was
an obvious case of "this should work" that turned out to
be a bug in the emulation of the hardware... On an early
version of the SimH PDP-11 emulator (c. 1998), there
were no known obvious problems under RT-11 or RSX-11
or even 2BSD with various types of DEC disk _except_
when I tried to create an environment with an RP03 and
load 2.9BSD on it (since I already had real 2.9BSD tapes
that I'd previously used to install the OS on real
hardware - an 11/24 with RL02 and RK07), the install
worked perfectly, but the OS hung on startup when it
came time to probe the bus for what controllers were
installed.
It took three of us, Bob Supnik included, to figure out
the issue was that when probe code writes to a read-only
register on the RP-11 controller, the controller should
generate an interrupt. That behavior is documented,
but even in hindsight, it's not documented in such an
obvious place that someone attempting to build an
RP-11 work-alike would know or expect that something
important should happen when you write to a read-only
register. The code fix was trivial and after that, 2.9BSD
came up and ran perfectly well.
If I hadn't decided that I wanted about 60MB of space (vs
10MB per "disk" w/RL02 or 28MB per disk with RK07), I
never would have known that there was an implementation
bug with the RP11 code. Also, if I'd only ever stuck to
DEC operating systems, I'd probably never have known
then either. It's an edge case, since I doubt there were
ever very many real PDP-11s with real RP-11s running
2.9BSD (for larger disk, an Emulex controller using the
xp driver would have been far cheaper and far more
common), but since with an emulator, I'm freer to configure
a virtual machine in somewhat more interesting (but
supposedly legal) combinations.
Ersatz-11 also has the same sort of opportunities. There is even a
Hypothetical Disk device driver, HD(X).SYS which supports variable
size drives. It is possible to mix and match hardware in a manner not
available on a real DEC system.
One very interesting possibility is the ability to LOAD a DLL which
supports direct access to the PC memory - I have manages to access
1.2 GB of memory on a system running Windows XP which has 3 GB
of physical memory. The instructions to access the memory of the PC
uses 4 IOPAGE registers (for the original simple version) so that the
user can directly read or write up to 4 GB of PC memory. This is not
very useful for RSX-11 or RSTS/E when direct access to IOPAGE
registers is not possible (or at least is totally unreasonable). But for
RT-11, even with a virtual job, it is at least possible to access the
IOPAGE registers from PREVIOUS KERNEL SPACE via the
MFPS and MTPS instructions. Obviously a real DEC PDP-11
can also have such a hardware device and with PC memory being
so inexpensive, a 4 GB stick could fit right on a Qbus controller
board.
So this is not a condemnation of emulation, but it is
a
cautionary tale that sometimes, it's not as easy as it
appears to "get it right", and that's where having real
working hardware can help. You say, "almost all
emulators or simulators have as their primary focus...
the accurate execution of any given hardware
instruction", but do keep in mind that it goes beyond
the instruction set when you start fiddling with
emulated hardware. MOV might move a byte
just fine as far as the ALU is concerned, but when
it's not merely storing a byte in an array to be fetched
later, when it needs to *do* something behind the
scenes because in the real box, you've just triggered
a cascade of flip-flops and gates, there's a whole lot
of emulator code that has to work that might or
might not have been sufficiently tested for
"accurate execution".
I actually have the same problem at the moment with a DY(X).SYS
device driver that works on a real DEC PDP-11/83 for the DEC
RX02 floppy drive, but does not seem to work on Ersatz-11 at the
moment. One of these years, I will attempt to figure out the problem.
This DYX.SYS has a bounce buffer to support 22 bit backplanes
while the RXV21 controller (M8029) only supports 18 bit memory
addresses. So I agree that there are always going to be infrequent,
but real edge cases.
-ethan
P.S. - yes, I've written plenty of MACRO-11 code under
RT-11 that directly fiddles registers - I worked on this
one project that had a hardware DMA engine and a
framebuffer, so my application code did lots of writes
to the I/O page, not just make I/O requests via the
usual RT-11 mechanisms.
The HD(X).SYS device driver has been enhanced to support using both
RAM: disks and disk files. When RAM: is used, the "disk I/O" is always
immediately complete before the CPU is returned back to the device driver.
With a disk file, some variants of Ersatz-11 support asynchronous disk I/O
so that an interrupt should always be taken in that case to wait for the
completion of the disk I/O.
YES!! There are always examples of interactions!!!!!!!!!!!!!!!!!!!!!!
Jerome Fine
15 Aug
15 Aug
11:35 a.m.
So while I
wish the hardware addicts well, viva the software addicts!!!!
Personally, I like the real hardware and enjoy constructing new hacks and
keeping the original gear working both. I also write code, but far more
system-level code than application code. To me, at the level I write at,
I need a 100% faithful hardware emulation from my simulators. It's not
good enough that a FORTRAN or BASIC program will run, pull in text from a disk or tape file and smash together the data
and spit out the
right characters for output. I care if bits in I/O registers flip and clear
in the right combination (though I care less if it takes 1us or 0.001us
as long as it's perceived by my code to be in the right sequence with
no atomic operations broken).
In general, most emulators do a fine job of this or the OS would never
load in the first place, but there are edge cases, which is why, for
example, in VICE, you can select logical emulation of the model
1541 floppy drive or exact emulation. Logical emulation presents
far less load on the host and if all you do is load and save files
and send non-exotic commands to read and write data, it all works
fine. If your program needs to manipulate data structures and buffers
behind the scenes (CBM DOS allows the main CPU to read and write
arbitrary bytes in the disk drive CPU's memory space using simple
textual commands that are syntactically the same as the commands
to load and save and review the directory, so it's not out of the question
to emulate it all).
There is a similar issue in writing a PERQ emulator. The PERQ 2 family
have a Z80 processor for low speed I/O (seiral prots, keyboard, mouse,
HPIB, floppy disk IIRC). The ROM hung off said Z80 contains just enough
code ot boot the machine (handle keyboard and floppy), the main program
is ethen loaded into the Z80's RAM by the main PERQ processor. Most the
time you run the Z80 code that came with the OS and never bother about
it. But in theory, although it's almost entriely undocuemtned, it's
possible to run your own code there. DO you emulate that or not?
Incidentally,m the Z80 code, at least the ROM, is a rather nice
cooperative multitasking system.
So this is not a condemnation of emulation, but it is
a
cautionary tale that sometimes, it's not as easy as it
appears to "get it right", and that's where having real
working hardware can help. You say, "almost all
The real test for an emulator is 'does the real machien do exactly the
same thing?'
-tony
11:23 a.m.
[...]
Also, Tony, I suspect that most of the members of the
classiccmp list share
your opinion about simulators or emulators - both programs performing
essentially the same function.
I am not sure... I suspect that many people here do like to run the
physical hardware, but that I am one of the msot 'extreme' people when it
comes to this split. I am very much an 'electronics' person and find
beauty in the circutiry (if there's any to find :-)). I can find, say, an
intersting motoro control system to be just as interesting as a processor
(and in fact more interesting than a standard microprocessor + memory
type of design).
Consequently, as a software addict, I can appreciate
why Tony and other
hardware addicts find that an emulator or simulator will never be suffice in
a manner that is satisfactory to run the software of any given computer.
Which doens't mean that _I_ think simulators have no use. They may have
no use _for me_, but that;'s not the same thing at all :-)
And since I have encountered no one else to share RT-11 enhancements
and bug fixes, it is assumed that no one else is an RT-11 software addict.
(If I am incorrect, please let me know!!!)
I suspect that's the a slight problem of licensing. The license status of
old DEC OSes is not clear, and buying licenses (even if we could afford
them) is non-triival. FOr taat reason people running real PDP11s either
don't mention publically what they run, or run things that they can get
the license for, like unix.
On the other hand, as a software addict, when I use the Ersatz-11 emulator,
the ONLY result which is important is that the screen displays results which
have the identical information content. The screen may look a bit different
and the keyboard may have a slightly different configuration. However, that
is not at all important to a software addict like myself. INDEED, sometimes
an emulator may even provide resources that the real (in this case a
PDP-11/83)
computer hardware is unable to provide. Executing the code 100 times as
fast is not a minor advantage. Having disk storage with 1,000,000 times the
capacity and 200 times the throughput is also not a minor advantage. Having
access to RAM which is 1000 times the capacity of the 4 MB available on
the real computer hardware is also not a minor advantage. And last in the
list at this time (but certainly not the only other advantage) and
certainly not
least is the support that Ersatz-11 provides to access the screens of up to
TWELVE ANSI (or VT420 compatible) type terminals by the simple use
of the <ALT/Fn> key combination for which Ersatz-11 currently supports
screens of up to 255 columns by 60 lines. (For those interested, one of
the KED variants which I modified called K42.SAV now supports screens
of that size - if anyone had read this far!!)
Howewver, while those are certainly advantages when developing new
software, fixing bugs and the like, in the end the final version o fhte
softare should eb able to run o nthe real hardare, with the stnadard
amount of memory and disk space, and at a reeasonalbe speed. If not, then
I would argue you've not really written a piece of PDP11 software.
[...]
So while I wish the hardware addicts well, viva the
software addicts!!!!
And on that point I totally agree with you. Let me relate a little
anecdote...
I have interests otehr than old computers (!). One of them is telephones,
and I am a memeory of a relevant club. This club recently held a meeting
near London, at the works of a company that restores telephone kiosks.
Now, you also know that I am not exactly tactful, I tend to say what I mean.
I went to said event, since it was pretty near. Now, telehpone kiosks are
not really 'my thing;, I am interested (as you would guess) in the
electrical/electronic side of telephony. But I said to the people form
the company : 'Although I will be frank and say that this is not my main
interest, I think it's graat that you are restoring and preserving the
kiosks. They are certainly part of the history of telephones in the UK,
and if everybody had the same intersts as me then that part of the
history would be lost. We need people with interests in all aspects of
telephony'.
And I feel exactly the same way about classic computers. The software
_is_ important. The marketting materials are important. And so on. They
are not waht I am intersted in, but that's my loss. Classic computing
(like the history of telephoens) is a very big area, and nobody can cover
al lof it. So I'll do my bit, you do yours. And I will happily
acknowledge that emulators have a place in many areas of the hobby.
_However_. we started this discussion by what museums should and should
nto do. And I still feel that museums, wherever possible, should run the
real hardare, at least from time to time (perhaps of special 'running
days' like some musems of stational steam engines, etc do). Her's another
analogyy...
Most people, I think, feel that a live musical consert (pick whatever
sort of music you like) is somehow 'better' than a recording. That's not
to say that recordings don't provide a lot of enjpyment, of course they
do. But I think people would be very annoyued if they paid to attend a
concerta and rather than hearing the band/group/orchestra/singers/,,,
live they simply got to hear the output from audiop CDs (I am assumign
the necessary copyright clearances, etc have been obtained). You can, in
general, listen to recordings at home, you go to the concert for
something 'extra'. Of coruse selling recordings of said music at rhe
concert is probably a good idea, most people would buy the CD to listen
to later.
Now, goign back to classic computing, most people can run the emulators
at home if they so wish. And the emulators do, undoubtedly, provide
soemthign for hte 'feel' of the real machine. But if you go to the museum
you should get soemthign rather more, something you can't get at home.
And that probably means the msueum should run the real hardware.
-tony
4295
days inactive
4298
days old
13 comments
8 participants
participants (8)
-
abs＠absd.org -
ard＠p850ug1.demon.co.uk -
cctech＠beyondthepale.ie -
ethan.dicks＠gmail.com -
jhfinedp3k＠compsys.to -
legalize＠xmission.com -
madcrow.maxwell＠gmail.com -
spectre＠floodgap.com