14 Aug
2012
14 Aug
'12
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