PDP-11 mockups?

Dave McGuire wrote:

We're talking about very different things. I will try to explain what I mean. SIMH doesn't "support" specific keys or specific terminal emulations at all, because that's outside its scope. It's very much like saying a PDP-11/23 (for example) "supports" a VT100, or a PDP-11/23 supports PF keys, or some other terminal function. It doesn't...it has serial ports, and the OS (as you know) squirts bytes in and out of those serial ports, and what the terminal or the OS (or the app software for that matter) has nothing to do with the fact that the computer is, in this example, a PDP-11/23. A PDP-11/23 "has support for" a VT100's PF keys if a VT100 terminal (or a clone) is plugged into it. In exactly this same way, SIMH "has support for" PF keys if a VT100 terminal is "plugged into" it. Say I start a terminal program like "gnome-terminal", which is a common terminal program on Linux and Solaris machines. In that terminal window, I get a shell prompt. I start SIMH, which creates a virtual PDP-11 whose default console port (777566) is logically "connected to" a terminal...not a hardware VT100, but the instance of the "gnome-terminal" program. It speaks ANSI codes and mostly implements a VT100, so <esc>[2J will clear the screen, <esc>[H homes the cursor, etc. All of these functions are completely outside the scope of SIMH. If, say, I boot RSTS/E on that virtual PDP-11, do SET TERM/DEV=VT100", and I fire up EDT, then tell EDT to "SET MODE CHANGE", the first thing that happens (more or less) is that EDT sends <esc>[2J to clear the screen. SIMH never sees this...or, more correctly, it sees those four bytes written to 777566, and squirts them through the emulated serial port untouched. At that point, they are no longer the responsibility of SIMH. It's up to the "terminal" that is "connected" to this virtual PDP-11 to understand what those bytes mean and what to do with them. If I had started SIMH under a terminal program that only understands the control codes of, say, an LSI ADM-3A, that EDT session would look like gibberish. In this way, I can start SIMH under any sort of terminal (iTerm under OS X has wonderful full-VT-keypad emulation) and have things work the way I want them to, for any desired configuration. I can even start it under a pseudo-terminal that has no display, but watches for patterns sent from SIMH and sends responses accordingly, as if they'd been typed by a human. (an "expect" script, for anyone into such things) What you are (or seem to be) talking about is starting a PDP-11 emulator that somehow opens its own window, thus creating a virtual terminal of sorts, and that terminal is responsible for interpreting the control codes, and handling key events and translating them to the appropriate bytes to send to the emulated PDP-11's emulated serial port. This is certainly a reasonable setup, but it locks you into one specific configuration that may or may not be what you want. A car and an oven may be a handy combination sometimes, but they perform different tasks, and only having a car with an oven, or only having an oven in the car, might sometimes be very limiting and inconvenient. SIMH, to my knowledge, has never done this on any of its native platforms. I've not spoken with Bob Supnik about this, but if it did in fact do this on its Windows port, and it doesn't any longer, it's likely because Bob realized the above and removed that functionality. I certainly would have. After all, if every PDP-11/23 came with a VT100 permanently and undetachably connected to its console port, what would a person do if they wanted an LA36 on the console?

from the VT52 series to the VT510 series would not be reasonable,