ERSATZ-11 BETA VERSION 0.8
PDP-11 SYSTEM SIMULATOR
Release date: 29-Mar-1994
Copyright (C) 1994 by John Wilson
All rights reserved
E11.COM is a beta test version of a full system simulator for the
PDP-11. It runs on any AT-class machine with an 80186 or better CPU,
requires around 300KB of free memory, and emulates the following
configuration:
* PDP-11/34a CPU (no FP11)
* 248KB main memory
* RL11/RL01-02 disk drives (up to 4)
* DL11 console terminal (VT100, or uses COM port)
* KW11L 60 Hz line clock
The emulator has been tested with RT-11 V04 (FB, XM), RSTS/E
V7.0-07 and V9.7-08, and XXDP+ (passes some diags, fails others due to
use of maintenance modes which E11 doesn't support), but for some reason
fails to boot RSX-11M V4.0 ("SAV -- Cannot find home block"). It has
not been tested with any flavor of UNIX or anything else not listed
above.
The emulator speed depends on the application (changing MMU
registers is an expensive operation so multiuser OSes tend to run more
slowly than RT-11FB does, for example), but for simple tasks it runs
about half the speed of a real PDP-11/34a on a 386-DX/40. Your mileage
may vary. It has successfully booted and run RT-11FB on a 4.77 MHz IBM
PC with a V20 processor (80186-compatible) but I wouldn't recommend
this!
I consider this program to be a beta test release because there are
several known problems, many incomplete (or unbegun!) features, and the
documentation isn't even worth distributing as it stands now.
Known problems:
* Fails to boot RSX-11. Tracing shows that it reads blocks a
fixed distance apart in ascending order across most of the disk
before announcing that it can't find the home block, perhaps
some RSX whiz can shed some light on this. I have vague
suspicions about my RL11 emulation.
* Console DL11 output uses simulated interrupts (delay is based
on number of instructions executed after writing TTBUF) even
when the console is redirected to a COM port, which uses real
interrupts. The result is that the output runs needlessly
slowly. Incidentally, the instruction-based interrupt delay is
necessary in cases (like RSX) where the PDP-11 program assumes
that the interrupt will take at least a certain time to happen,
and blithely issues a WAIT instruction even if the transfer is
already finished. I may add commands to alter these delays so
that the system will run faster under software that contains no
such assumptions (such as RT-11).
* DL11 emulation is incomplete. The plan is to emulate up to 16
DL11s total (including the console), 12 of which are displayed
on the screen (selected by the Alt-function keys) and 4 of which
may be the four COM ports. For now only the console DL11 (TT0:)
works.
* The T bit (single step) doesn't work correctly. This will
screw up any debugger that uses it.
Planned additions:
* Separate I/D space and supervisor mode. The code for this
exists (under assembly conditionals) but is disabled so as not
to confuse CPU-detection code which (justifiably) assumes that
anything with I/D space also has a working MMR1 (MMR1 is not
supported, it would slow down the operand fetch/store routines).
I'm considering the possibility of upgrading the program to
11/44 (or 11/73 etc.) compatibility but this would require
converting it to run in protected mode (using EMS/XMS swapping
instead would kill performance) to take advantage of the 3.9MB
address space.
* Floating point hardware. This is not yet started. Emulating
all the various operations is no big deal, but the flags and
exceptions are really annoying, so I've procrastinated so far.
This will probably require a math coprocessor (you paid
thousands to get it for your PDP-11, dropping a $50 chip in your
PC doesn't seem like too much to ask).
* Network hardware. The idea I'm toying with is having an init
file which says which protocol numbers the 11 needs to receive
and then registering those with a packet driver, then simulating
a DELUA which only "hears" those packet types. That way it
wouldn't interfere with other network software on the PC. A
possible stopgap might be adding a small server for some
commercial TCP/IP package to connect incoming Telnet calls to
simulated DL11 ports.
* MSCP disks. Don't get me started on this one... (DEC is
still cagey about documentation even though all the competitors
they were trying to fool got their clones working years ago.)
It might be cute to simulate these using their own partitions on
the hard disk, then write real DSRs for a few popular
controllers (i.e. bypassing DOS) so that disk I/O would be
truly asynchronous (like real hardware), that would speed things
up considerably. But remember, this section is intentionally
omitted.
* Floppies. I have code in another program which simulates
RX01/02/03-like disk formats on 1.2MB floppies, and goddammit
*I* think it's cute! You won't have to use it if you don't want
to. RX50 emulation would be easy except the controllers use
MSCP, see above (right? I've never seen a RUX50, maybe it's
different). I may make some feeble attempt at emulating 1/2"
magtape using QIC-40/80 drives while I'm at it, but don't hold
your breath.
Using the program:
For a regular user, there are very few commands to
remember. All commands are entered at the command prompt, which
is displayed on TT0: (normally the screen) whenever the PDP-11
is halted, or may be brought up any time if you press the SysRq
key (which is Alt/Print Screen on Enhanced keyboards). The most
important commands are the MOUNT, BOOT, and QUIT commands.
MOUNT ddu: filename.ext [/switch]
This specifies a DOS file to attach to a simulated disk unit.
"ddu:" is the name of the PDP-11 disk drive to which the file
will be attached (currently the only valid names are DL0:
through DL3:). "filename.ext" is the DOS file which contains a
byte-by-byte image of the disk (at the moment this file must be
either 5MB or 10MB long, the program uses the length to decide
whether it's an RL01 or an RL02). The optional "/switch" is
either /RW or /RO (/WP is a synonym for /RO) and specifies
whether the disk should be set for read/write or read-only
access (the default is /RW).
BOOT ddu: [/switch]
Boots the system from the specified disk. There is a bug that
causes this command to not always work properly if the system
has already been running -- quit and restart for now. The disk
must have been mounted with the MOUNT command. The optional
switch is an OS name; for now the only meaningful one is /RT11,
although /RSTS and /RSX are defined too. This has to do with
the method used to pass time and date information to a newly
booted monitor. RT-11 ignores the time and date passed at
005000 unless the NOP in the first word of the bootstrap is
cleared to 0 (HALT) and the bootstrap is entered at 000002.
RSTS believes the time and date at 001000 (in a different format
from RT-11) regardless of whether its NOP was nuked, but later
versions of RSTS save the first word of the bootstrap and
execute it later, so they will halt if the system was booted the
RT-11 way. Hence the need for the switch. If you like typing
the time and date manually (or your PC has no RTC) then don't
worry about the switch. I don't know enough about RSX to set up
the time/date for it.
QUIT
Should be obvious.
The other commands are mostly useful for debugging so I won't go
into them, except to say that there's a mostly functional PDP-11
debugger/disassembler, most of the commands are modeled after
those from the RAID debugger, DECUS #11-772.
Initialization:
At startup, the program looks for an init file named E11.INI,
first in the current directory, and then in the directory where
the executable is stored (for DOS V3.0 and later) or in the
directories listed in the PATH environment variable (for DOS
V2.X). This is a regular ASCII file, which is fed to the E11
command interpreter one line at a time at each command prompt
until the end of file is reached, at which point command input
is redirected back to the keyboard. Keyboard input to the
PDP-11 DL11 port comes from the keyboard even if an init file is
in use.
Typical E11.INI file:
mount dl0: rt11.dsk
; uncomment the ASSIGN command to use a COM port for console I/O
; (must have been initialized from DOS using a MODE command)
;assign kb0: com3: irq5
boot/rt11 dl0:
; control returns to the next line when the user presses SysRq
quit
Notes:
Getting a snapshot of a bootable RL01 or RL02 disk for your OS
into a huge DOS file is your problem, I don't want to get
involved in DEC licensing infringements. BTW, my local (Albany,
NY) DEC office has no problem with the concept of selling a real
license for a PDP-11 that doesn't really exist. Anyway I used
Kermit to slurp the disk images out of a real PDP-11. I'm
working on a separate utility program to manipulate DEC file
systems, stay tuned if you care.
Source code is not being released at this time. The program
contains a lot of proprietary code (most notably the VT100
emulation) which I don't want floating around.
It's important that you quit out of the emulator before powering
the machine down. The disk image files aren't closed until the
simulated disks are dismounted, so just because your PDP-11 OS
thinks it has flushed all its data to disk doesn't mean that it
has actually been written to the PC's disk yet, especially if
you have a disk cache running. You've been warned. I may add a
timer-based periodic flush to the program to lessen the impact
of this problem.
"Why didn't you write a Mac version" etc., etc. etc. etc. The
program is written entirely in 80186 assembly language; porting
the devices, debugger, interrupt system etc. to another
architecture would be very straightforward but the instruction
set simulator depends heavily on similarities between the 80x86
and the PDP-11 (most notably byte order and the condition
flags). Also the VT100 emulator gets pretty intimate with the
video hardware.
That should cover most of the important stuff. Basically I'm
tired of sitting on this thing tearing my hair out over the bugs
and I think it works well enough to be useful to some people.
It took eight days to go from scratch to booting RT-11FB, and
I've accomplished almost nothing of value in the 5 months since
then. I would appreciate any and all feedback (good or bad)
about the program, particularly if it's specific enough to help
me improve it (i.e., "it crashes sometimes" is nice but "the
ASHC instruction sets the V bit wrong" is a lot better, yeah I
know I'm dreaming).
AS ALWAYS, MAKE A BACKUP OF ANYTHING YOU CARE ABOUT BEFORE
RUNNING THIS PROGRAM. Yeah I know you won't (I didn't) but
think about how mad you'll be if you lose something important...
John Wilson
46 Bank Street, Apt. 2
Troy, NY 12180
(518) 271-1982
wilsonj@rpi.edu
John_Wilson@MTS.RPI.EDU (if RPI.EDU is in AFS never-never land)
USERHA8G@RPITSMTS.BITNET (if *you're* in never-never land)